Working with Aconex

Aconex is a document management system commonly used in the construction industry – it is used primarily by large developers and clients to manage construction documents (for example drawings, calculation packs, risk assessment method statements, material approval forms and so on).

Each of these documents passes through a series of checks before becoming ‘approved’ in some way. These checks usually culminate in approval from one or more engineers, managers, or, for more specialised and technical documents, ‘Appointed persons’ (some nominated person with a particular level of responsibility or skill set – e.g. someone responsible for electrical safety on a project). Once the document has been fully approved by that person it may be used, enabling the activity it describes to proceed, this might be the construction of the structure described by the approved drawing, or the activity described in the approved method statement.

Aconex allows these approval processes to be described using its workflow processes, which help to automate approvals and feedback in the case of non-approval, but the approvals process can be completed manually if needed (although this is very labour intensive and pretty soul destroying – computers should be allowed to do what they do best!).

However, the key disadvantage of using a more manual approvals process is that the exact status of a document can be hard to discern without several minutes of effort. Even the best trackers, known to be complete and regularly updated, cannot give you an up to the minute document status. Every time a status is needed – you consult the tracker to find its status at the time of last update, then check for any correspondence issued since then that updates this understanding. In my experience, developing and maintaining a fully up to date tracker for a significant set of documents (say 100-200 documents) can be a full time job. If you have no technical input on the documents you are using in the tracker, then you could probably manage about 5-10 times as many.

Fortunately, Aconex has a well developed API that allows querying of the database of documents, as well as each document and its history, including where necessary the ability to download the document itself. This allows each document to be tracked, using some simple questions, so that either the tracker can be updated automatically or the user alerted to activity involving a document, indicating the tracker is now out of date and action needs to be taken. Other uses of the API include creating an up to date folder of every document of a particular type that is very easily accessible by the team, and helping to discern the status of a whole project (for example – how many documents have been sent to this person for approval but have not been returned by them?). Whilst implementing this ‘flow chart’ of decisions to find the status of a document cannot be completely accurate, it can help the engineer significantly by making sure all the simple questions about a document’s status have been asked – in particular, increasing confidence about whether a document has changed since the tracker was last updated.

As part of my work, I created a few small programs to explore these possibilities:

  • One creates a query and sends it to Aconex (This is a small c# program, compiled to create an .exe)
  • One downloads documents given certain search parameters (creating an up to date folder of documents for team use) – in Python 2.7
  • One downloads all Aconex Mail items
  • One searches fairly exhaustively for indications a document has been updated, allowing an engineer to see whether a tracker is out of date – in Python 2.7

C# code (compiled to .exe) to call Aconex API and receive .xml file of search results or document metadata:

C# code (compiled to .exe) to call Aconex API and receive other files:

Python script to download all documents returned by a search with wildcards:

Python code to classify document statuses:

Leave a Reply