Web service synchronization process

The process diagram below indicates how the Web service interface is enabled between an external system and Asset Strategy Optimization, and how synchronisation will subsequently be performed. The diagram uses the term EAM to indicate the external system. However, any external system could be used here, as long as it supports the Web service.

The following steps will be followed:

1. The Web service connection is activated: this is an activity usually performed by an administrator in the organization

2. As of this moment there will be a difference between objects in Asset Strategy Optimization that are linked to identical objects in the EAM system, and those that are not linked. Objects are linked by filling in the object-id used in the EAM system in a special field of the object in Asset Strategy Optimization called External service identifier

3. Linked objects will from now on be maintained and changed from the EAM system

4. Not every change in the EAM system will need to be processed and sent to the Web service immediately; often changes are collected and later sent as a compound change (here called 'delta' hierarchy)

5. Changes from the EAM system will be sent as a ´delta´ message to Asset Strategy Optimization by means of the Web service interface. Once received by Asset Strategy Optimization, they will be analyzed, resulting in two options: the message will be approved and processed, or it will be rejected as a whole

6. If the 'delta' message is approved, then Asset Strategy Optimization will analyze the changes that need to be made to the object hierarchy in Asset Strategy Optimization to reflect the changes in the EAM system. Note, that if a user had changed a linked object in Asset Strategy Optimization, this change may be overwritten by the Web service, since the EAM system is leading. This only applies to the linked-object fields which are maintained in the EAM system, not the ones which are unique to Asset Strategy Optimization

7. A 'delta' message may, in rare situations, contain errors or contradictions with the data stored in Asset Strategy Optimization. In that case, the message will be rejected as a whole, and none of the changes in the message will be applied. The message will be sent back to the EAM system, where it should be analyzed and manual intervention may be needed to correct the errors

8. An administrator of the EAM system can analyze the 'log'-file and find out what was the cause of the error. Note that, in this situation, the state of the EAM system will be different from that of Asset Strategy Optimization

9. An authorized user who logs in to Asset Strategy Optimization after a 'delta' message has been processed will see a Service log overview screen (if this option is enabled in Asset Strategy Optimization) showing the changes that have been processed. The user can tag each change message as 'reviewed'. Tagged messages disappear immediately, but are only saved when the user closes the screen

10. Also, the user may add a comment with each change message in the Service log overview screen, which will be saved in the Audit Trail data, and will be visible for each user who also gets the change overview screen. This situation lasts as long a change message has not been marked as 'reviewed'

11. The user may close the change overview screen and continue working in Asset Strategy Optimization. If new changes are processed by the Web service, then the user will notice those changes when:

    • the next time when the user logs in to Asset Strategy Optimization

    • when the user manually reopens the change overview screen

12. This mechanism will stop when

    • the Web service is no longer active

    • the objects in Asset Strategy Optimization are no longer linked to those in the EAM system through an object-id (see step 2).