Web service supported actions

A linked object is partly maintained from the external system. Changes made to the linked-object in the external system will be reflected in Asset Strategy Optimization. The Service log overview screen shows what action was performed on the object, its old and new value, the Web service user used to make the change, and the date the change was performed. The External service identifier is the object-id used in the external system to link the object to Asset Strategy Optimization.

The Service log overview screen shows what changing were made to an object, by whom, and when; also the old and new values are shown

The Web service offers various services, which are all based on two actions: an Insert and an Update action. From the Service log overview screen, the user can analyze what service was performed, by studying the Action, Fieldname and Old/New Value fields.

Create a new object

A new object will be created below the 'parent' object. Prerequisite is that this 'parent' object already exists in Asset Strategy Optimization. After synchronization the new object will also be found in Asset Strategy Optimization under the existing 'parent' object. Any new child-objects that were also created in the external system will be treated the same way: as a 'create a new object' action. The Web service is 'intelligent' in the way that it can find out what the total new object hierarchy looks like, and can recreate that structure in Asset Strategy Optimization. If no parent object is given, Asset Strategy Optimization will assume a new system was created (at the highest level) and will try to create such a system object in Asset Strategy Optimization.

The fact that a new object was created can be found in the Service log overview screen as follows:

Move an object

Objects that are moved within the external system, will be similarly moved in Asset Strategy Optimization, provided the new 'parent' object to which the object as moved also exists in Asset Strategy Optimization. If not, then the change will be rejected, and the administrator of the external system will receive a message with the rejected change, and should act on this. Note that correcting the error should be always initiated from the external system. Creating new objects in Asset Strategy Optimization directly will result in non-linked objects, for which no synchronization will be possible.

The fact that an object was moved can be found in the Service log overview screen as follows:

Tip: Since the Object codes are just numbers, you may use the Pass through button to see the new location of the object in the FMECA tree.

Copy an object

The Web service of Asset Strategy Optimization does not support copying of an object as such. External systems that perform an object copy should translate that action into an equivalent 'create a new object' Web service message.

The fact that a new object was copied can be found in the Service log overview screen as the creation of a new object, as follows:

Rename an object

Renaming an object (or some of its fields) is supported by Asset Strategy Optimization. Important is to realize that different systems may use different restrictions to field types and formats for field names. You can think of the use of spaces, certain diacritics, name length etc. The new name of the object will be checked against these restrictions by Asset Strategy Optimization before the change is actually applied. If this check fails, then the change will not be processed and the change message will be rejected. It is up to the administrator of the external system to act on this situation.

The fields that can be renamed are: Name, Tag, Function and the Free fields 1 to 10. The fact that an object was renamed, re-tagged, or another field was changed can be found in the Service log overview screen as follows:

Process large change

This type of message accepts a large compound message containing a 'delta' hierarchy. It is up to the Web service interface to figure out how this change is to be reflected in Asset Strategy Optimization. This is the most powerful message with one drawback: in case of any error in the message, the whole message will be rejected and none of the changes will be reflected in Asset Strategy Optimization. While the error is analyzed the user should be aware that during that time, there will be a difference between the data in the external system and Asset Strategy Optimization.

The large change message is automatically divided in one or more messages of the type described above.

Note: Changes made in the external system will only be applied in Asset Strategy Optimization after the external system actually sends the changes to the Web service of Asset Strategy Optimization (which obviously should be active at that time). Each external system may use a different timing schedule for this. In some cases the change message will be sent almost immediately, in other cases changes are collected during the day and sent as one compound message to the Web service at night.

Things to consider:

Removing an object:

The Asset Strategy Optimization Web service offers no support for deletion of objects. Objects that are deleted (or made in-active) in the external system, will require a suitable equivalent action in Asset Strategy Optimization to reflect the change. A possible action could be to move the deleted object to a special subsystem called 'trash-can', within the same system in Asset Strategy Optimization. The delete action is thus translated into a move action, that 'understands' that deletion of a (sub) hierarchy in the external system should be translated in a move action of that (sub) hierarchy to a defined 'trash-can' folder in Asset Strategy Optimization.

Scope:

The Web service demands that all actions take place within the scope of the main object, i.e. the system defined at the highest level, that is linked to the external service identifier.

Pass through:

To be able to view changes in detail, it may be necessary to use the Pass through button and study the various detailed object fields from there.