Server xml to object

See also: Object to server xml

Value resolver – Abstract
Purpose: Attempts to parse a string passed as input value as XML and interpret it as server XML format to return an object.
Tooltip
Usage:The value resolver returns the generated object if successful.
Note: If no value ($null) is present as input value, no value ($null) is returned..

images/download/attachments/102602396/EN_title_0-version-1-modificationdate-1655301888968-api-v2.PNG

The Server xml to object resolver parses a string passed as input value as XML and interprets it as server XML format (see Server data encoder) to return an object.

The following cases are differentiated:

Input value (abstract)	Input value (specific examples)	Return value	Error
No value (`$null`)	No value ($null)	No value (`$null`)	n/a
A string that does not define a well-formed XML.	Empty character string ("") `abcXYZ` `<missingSlashInClosingTag>XYZ<missingSlashInClosingTag>`	n/a	`ProcessException:Failed to unmarshal`
A string that results in a well-formed XML that refers to a `root` element that is unknown to the server.	`<unknownRootElement>XYZ</unknownRootElement>`	n/a	`ProcessException: Failed to unmarshal`
A string that results in a well-formed XML that refers to a `root` element type defined for the server (here: `any`), but disregards its schema. ►NOTE◄ Content not provided for in the server-side applied schema is ignored!1	`<any>123</any>`	No value (`$null`)	n/a
	`<any><value>123</value></any>`	Data object with a `value` field that does not contain a value (`$null`)	n/a
A string that results in a well-formed XML that refers to a `root` element type defined for the server (here: `any`) and can be successfully validated against its schema. ►NOTE◄ Content not provided for in the server-side applied schema is ignored!	`<any xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <value xsi:type="xsd:long">123</value>` `</any>`	123(`Long` value)	n/a
	`<?xml version="1.0" encoding="UTF-8"?>` `<ord:Order xmlns:ord="SCM.ORDER" creatorId="1901" ownerId="1902" lastModified="1638460649053.053000000" lastModifierId="1901" numberOfPackages="3">` `<attributes>` `...` `</attributes>` `<lineItems>` `...` `</lineItem>` `</lineItems>` `</ord:Order>`	Entity of the 'Order' type (`ord:Order`); see Orders	n/a

Configuration

The value resolver does not use any parameters.

The string to be parsed by the server as XML for a data object is expected as the input value.

Examples

Create search object as input value for a 'view'

In conjunction with the Open view (Action) and the Search builder, the Server xml to object value resolver can be useful to generate an object of the 'search' (search) type as an input value for an overview.

The procedure is described in detail in the Open view (Action) example. Therefore, only the purpose and use of the Server xml to object value resolver will be briefly discussed here:

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.

images/download/attachments/102602396/EN_example_1_actions-version-1-modificationdate-1655302286492-api-v2.png

Manipulate XML data of an entity via 'string processing'

The following example shows how the Server xml to object value resolver can be used in conjunction with the Object to server xml value resolver to manipulate the data of an entity – here of the 'Order' type (see Orders) – in such a way that the manipulated data define a new entity – here of the 'Shipment' type (see Shipments). Here, all characteristics of the 'Order' are transferred to the 'Shipment', which is supported by the XML schema for Shipments.

Runtime example:

A shipment is created from an order with the following information about the companies and positions involved 'at the push of a button' – more precisely, by triggering a Custom action event via the ribbon button – which reflects the characteristics of the order that can be mapped to shipments:

images/download/attachments/102602396/EN_runtime_1-version-1-modificationdate-1655302062528-api-v2.PNG

For demonstration purposes, the created shipment is reproduced here in a similarly structured input form:

images/download/attachments/102602396/EN_runtime_2-version-1-modificationdate-1655302078731-api-v2.PNG

The 'Order type' (orderType) field is not provided in the schema for Shipments. It is omitted in the data of the created shipment.
The involved companies and line items are transferred completely. For the shipment line items, the form provides additional fields, which of course remain empty.

images/s/-95e2zf/9012/8yg2g7/_/images/icons/emoticons/warning.svg CAUTION Converting one entity type to another by manipulating XML data should not be mistaken as 'good practice'. It is generally not a recommended methodology for data manipulation and is used here only as a demonstration example of the use of the Server xml to object value resolver. A Lobster_data profile (with mappings between the associated Orchestration templates) or event handling with a specific sequence of value assignments will certainly solve the systematic data transformation between two entity types in a more robust, flexible, and maintainable way than the following configuration. Only because the data models or schemas of Orders and Shipments are largely compatible, is the path of a 'text processing' at the level of the server XMLs viable at all. The described 'text processing' does not claim to cover every conceivable 'data situation' for an order.

Configuration:

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.