Operations in OData machine steps
List of different operations selectable in machine step; what do they mean and how they are identified. Refer to terminology section to what they mean.
Last updated
List of different operations selectable in machine step; what do they mean and how they are identified. Refer to terminology section to what they mean.
Last updated
Reading entityset is done using Read operation which is located directly under each entityset folder, example is how to read Active Work Orders (entityset ActiveSeparateSet).
Get by key operation if operation which requires entity key as only parameter. This operation does not return any reference entities, only attributes belonging to entity.
If the operation requires an ETag value in request header, for example when updating single Entity, the Get by key operation is the only Get operation that returns an ETag.
Generic operations for Create, Insert and Delete operations are located directly under each entity set folder.
Prior creating new entity user might benefit from getting default parameters to be used in Create operation.
The operation do not require any input parameters and returns a single record.
Some entities may contain Batch Create <EntitySet> and add owned collections operation for creating single entity and reference entities in one call in flow. The example operation creates one Functional Equipment object and several reference entities in one call. These kind of operations are provided by the OData Connector and thus cannot be found from API Explorer.
In the machine step, provide required parameters for the new equipment and optional amount of reference entities.
Bound actions are actions that are linked to a certain entity and are located under the Entities folder. Bound actions can be generally be thought of as RMB operations executed in Aurena against an entity. For example changing status on a Work Order.
Operation ActiveSeparate_Cancel (from entity) is called.
Reference entity sets can be created, deleted or updated in the context of a certain entity. In the example; Add to Notes to Work Order.
Parameters require to identify the entity (Work Order no) to which the notes are added.
Batch Add operation reduces the need to create a single entities loop in flow -> reduces execution time. These kind of operations are provided by OData Connector and thus cannot be found in the API Explorer.
Each projection may or may not have operations prefixed with Lookup.
For example when you create new customer, the new Customer page in Aurena is initiated with a LOV of static list countries using Lookup_IsoCountry_EntitySet Read operation.
Projection may or may not include separate operations to fetch LOVs for references linked to entityset.
Reference operations are designed for Aurena pages to produce searchable LOVs.
Reference LOV entity sets may contain default filtering compared to standard projections. For example the Reference LOV entity set may not contain entities that have a certain status (blocked); not allowed to use. When reading the same entities from a standard projection all records ,despite of status, are returned. Using Reference LOV entity sets can be beneficial since no additional LOV filtering in Flow is needed.
Static reference means that the IFS component is mandatory related to the entityset.
Dynamic reference means that the IFS component is not mandatory related to the entityset.
Static Reference LOVs
Static reference LOVs refers to entities that originate from IFS components that are mandatory for the projection (EquipmentAllObjectsHandling). Depending on the reference entity business rule; filtering may be applied in Reference calls (company, site, organization..).
Dynamic Reference LOVs
Dynamic reference LOVs can be used if the IFS component, where reference entity originates from, is installed. Example DynReference_BankIdentifierCodeHrLov refers to entity BankIdentifierCode in component PAYLED. If PAYLED component is not installed, these LOVs cannot be used.
Static actions and functions are various types of operations not linked to entity, e.g. the are no necessarily mandatory parameters to identity certain entity.
Functions are read only operations.
Action is an operation that change data in IFS.
Code section allow developer to create C# code to call IFS APIs. See more from Missing operation and C# usage in the OData connector.
Custom request functionality allows developer to configure API call (in case of missing operation) instead of writing C# in Code section. Read more from here.
