As the screenshot shows, an Open view (Action) event action is executed in the context of a specific order item (selectedLineItem).

The event action opens an overview for Orders, in which all orders appear, which have at least one order item, whose value for the text attribute 'Goods description' (GOODS_DESCRIPTION) matches the 'Goods description' for the current order item (selectedLineItem).

This condition can be formulated and tested quite easily in a Search in the Search builder for a specific 'product description'. Instead of a specific 'product description', a unique text marker (in the example "@1:s") can be used in the search created and tested in this way, which is interpreted dynamically as a parameter at runtime – i.e. replaced by a specific text value.

From the Search builder, the XML definition for the search (incl. parameters) can be copied to the clipboard in order to paste it – as shown in the screenshot – as static text (see Static values) in order to be able to process it further:

• Specifically, the (text marker "@1:s") parameter is first replaced by the searched 'product description' using a chained Replace text event action. In this way the string describes the search object for the view to be opened in the server XML format.

• The chained Server xml to object value resolver converts this XML text into a search object that can be passed as an input value (in the Entity parameter) to the opened view, so that an overview appears with the individual 'restriction' that can be elegantly represented in this way.

►NOTE◄ The example for Open view (Action) describes further details that must be observed for a successful implementation according to this schema.

The event handling, whose event actions are shown on the right, is triggered in the context of an order via a Custom action event (per ribbon button). A Check type in the 'Validating rule' (not shown in the image) ensures that an order is present as an input value.

The conversion from purchase order to shipment takes place in the header of an Execute with event action, in the context of which the shipment created is considered a different reference object. A concatenation of value resolvers performs the following steps:

• The Object to server xml value resolver returns the server XML text of the order as a starting point for 'text processing'.

• A series of four Replace text value resolvers manipulate the server XML in the following steps (see below for details):

  • Customize namespace

  • Customize prefix for specific elements

  • remove id attribute (where necessary, see note)

  • remove lastModified attribute (where necessary, see note)

• The Server xml to object value resolver creates a data object from the modified server XML that defines a new shipment with the characteristics of the order. In this step, the characteristics that are not compatible with the schema for Shipments (e.g. 'Order type') are lost.

• The Input object (type safe) value resolver is only used here so that the context 'Send' is declared for the configurations in the Execute with event action block.

The action block defines the following actions in the context of the new program:

• The reference for the 'Current working state' taken over from the order is deleted via the Set value action.

• The Save changes later event action marks the shipment for saving when the transaction is completed. Since no further actions follow, the shipment is therefore created, provided that this does not involve any error messages.

►NOTE◄ Removing the id and lastModified entity attributes is required for all entities to be recreated in the context of the shipment. This affects attributes, line items and the entity's head (the root element in the XML).

The namespace attribute xmlns:ord should only occur in the root element (ord:Order) of the order XML. It can therefore be identified by simple Replace text and replaced by the corresponding entry for shipments (xmlns:shp="SCM.SHIPMENT").

At all places where the XML of the order refers to the namespace ord , the namespace shp must be specified for the shipment. In all relevant cases, the namespace name is also followed by a class name for the element in question, starting with Order for orders and Shipment for shipments.

The regular expression for the replacement applies to opening and closing tags in the XML:

• In the head: <ord:Order>...</ord:Order> → <shp:Shipment>...</shp:Shipment>

• For attributes (e.g.): <ord:OrderText>...<ord:OrderText> → <shp:ShipmentText>...</shp:ShipmentText>

The Search text (<[/]?)ord:Order identifies all relevant positions in our example. When being replaced, the introduction of the tag ($1) is kept, but the combination of namespace and class prefix is replaced.

Removing the entity attributes (id and lastModified) from relevant elements is done in two separate steps to ensure that the replacement works regardless of the order of the attributes.

The regular expression is structured according to the same diagram:

• The first group (the initial line in the screenshots) identifies the opening tag for a relevant element – here the name of an element that starts with the string shp:Shipment (corresponding text sections have already been 'converted' in the previous step) or lineItem – and then allows further characters until the tag is closed (>).

• The second group (the second line in each of the screenshots) identifies the entity attribute to be removed and its value.

Only the first group ($1) is specified as the value for Replace with, ranging from the beginning of the tag to the space before the attribute to be removed. The unwanted attribute is therefore removed. The following text remains unchanged.

►NOTE◄ The entity attributes (id and lastModified) must not be flatly removed from all tags, since the structure of the shipment may contain embedded entities that should be included in the shipment including their entity attributes. In our example, this concerns the addresses contained in company and address attributes.