Call profile (Event action)
Event action – Abstract
Purpose: This calls a Lobster_data profile with the data of the current reference object. This is done immediately and basically synchronously (in contrast to the export). An XML structure is expected as a return value only if an entity is present as a reference object and is interpreted as an update for the entity. For other reference objects the profile call is processed synchronously, but without considering a return value.
See also: Export (event action), Profile call (resolver), Call profile (behaviour in forms),
The event action Call profile (Event action) calls a Lobster_data profile with the data of the current reference object.
In contrast to a profile call via Export, the call takes place immediately and generally synchronously, so that event handling is interrupted until the profile has been processed.
During the profile call, the data of the current reference object is passed as input data (XML). The further process depends on whether the reference object is an entity or not, i.e. a type of data object managed on the server side:
Reference object |
Effect |
Reference object is an entity |
If the reference object is an entity – i.e. an instance of a specific entity type defined on the server side – Lobster Data Platform / Orchestration expects an XML structure as the return value of the profile, which can be merged with the data structure of the reference object similar to the object structure during an Import, in order to update its volatile data status.
►NOTE◄ If the called profile returns no or an unsuitable return value, for example, because no corresponding response path is configured or active, or the provided content uses e.g. JSON format instead of the expected XML format, then an error occurs that causes a rollback of the transaction in Lobster Data Platform / Orchestration, while Lobster_data records the profile job as processed without errors. If a profile is executed only with the data of an entity without expecting a return value relevant to the content, a response path must always be created, which – e.g. via CronPassBackDataResponseUTF8 – returns a data structure that can be processed via merging but does not cause any changes. By selecting the 'as received' option for Content in the Content settings tab, for example, it is easy to ensure that the return value reflects the input data unchanged, while other response paths can refer to deviating Content from phases 3-5:
|
Reference object is not an entity |
If the reference object is not an entity, but rather, for example, a simple value, a list (see example) or a client object, a server XML of the corresponding data structure is also generated and transferred to the profile. Example (server XML for a list of strings)
<? xml version = "1.0" encoding = "UTF-8" ?> < list xmlns:xsd = "http://www.w3.org/2001/XMLSchema" xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" > < entry xsi:type = "xsd:string" >P1020</ entry > < entry xsi:type = "xsd:string" >X4896</ entry > ... </ list >
►IMPORTANT◄ For data objects that are not entities, Lobster Data Platform / Orchestration does not provide an update mechanism in connection with a profile call. A return value from the profile is therefore neither processed nor expected – in contrast to the call with the data of an entity. However, the profile call is still synchronous, i.e. for the runtime of the Lobster_data profile, the called event handling in Lobster Data Platform / Orchestration is interrupted. Afterwards, it is continued, whereby for the reference object itself the state when the profile was triggered remains unchanged, if the profile – e.g. via CronPassBackDataResponseUTF8 – delivers a return value to Lobster Data Platform / Orchestration. ►NOTE◄ In the context of a form, the Call profile behaviour can alternatively be used to pass any data object to a profile and then process the return value of the profile back in the portal. If required, alternative formats for data exchange between Lobster Data Platform / Orchestration and the called Lobster_data profile can also be selected there (e.g. JSON instead of XML), where data structures not bound to entity types can often be handled more efficiently. |
Assignments to MSG_CALL variables in the profile:
Information about the applicable logon context (company, role, user) is automatically assigned to the MSG_CALL variables predefined in profiles – as is usual for profile calls from Lobster_pro. These are automatically filled with values at runtime depending on the session's logon data and, if necessary, taking into account adjustments made by the Ausführen als event action, as follows:
Data object |
Value |
Variable name |
Data type |
ID (id) of the company account |
MSG_CALL_SCM_Company_id |
BigInteger |
|
Company account data object as XML (text) |
MSG_CALL_SCM_Company_xml |
String |
|
ID (id) of the role |
MSG_CALL_SCM_Role_id |
BigInteger |
|
ID (id) of the user account |
MSG_CALL_SCM_User_id |
BigInteger |
|
Username (username) |
MSG_CALL_SCM_User_username |
String |
|
User account data object as XML (Text) |
MSG_CALL_SCM_User_xml |
String |
Optionally, value assignments can be configured for further Variables to pass additional data to the called profile.
Configuration
The Profile name parameter identifies the profile to be called up. Existing profile names are suggested in a drop-down list via 'auto-completion' to match the entry in the text field.
►NOTE◄ Unlike the configuration of behaviours such as Call profile in the Form designer, access to profiles in event handlers is not constrained by Profilsicherheiten.
The option Fail on profile error? determines whether an error during the processing of the profile call (in Lobster_data) is also evaluated as an error (incl. rollback) within the event handling in Lobster Data Platform / Orchestration.
The option is deselected by default, so in case of an error during profile execution, event handling continues with an unchanged reference object.
If the option is selected, errors in Lobster_data will affect the transaction in Lobster Data Platform / Orchestration. An abort incl. rollback of the transaction can therefore be specifically triggered via the Lobster_data function throw exception.
The Variables section offers a Repeatable element in which value assignments for variables can be defined via the
and
symbols.
The assignments for these variables apply only to the context of the profile call.
A variable must be defined in the profile that uses the prefix MSG_CALL_ before the entry for the Variable name.
The value resolvers configured for the Value parameter are resolved at runtime at the same time the Export event action is executed. However, the note below must be observed when a data object is assigned as the value to the variable!
As the example of the second Variable name attachment in the image above illustrates, the option Send as file may also appear depending on the type of the return value of the value resolver.
If the Send as file option is checked, then the return value of the resolver is not assigned directly to the variable, but a path specification to a temporary file into which the corresponding content is written when the profile is called. After the profile call, such temporary files are automatically deleted again.
Example
Within an input form for orders, individual prices per item are 'obtained' from a commercial system upon request, provided that the respective item fulfills a number of criteria (EAN number filled in, another price entered, etc.). It should be possible to request prices for each item by specifying an individual target currency. Further details for looking up the prices should not play a role in this example.
Crucially, the request must be handled via a profile call, which must be executed selectively for each qualified order item. The prices obtained should appear immediately in the volatile data object of the order without having to save the order as a whole.
Configuration:
An event handler that uses a 'Get list price' Custom action event event as a Triggering event is configured as shown on the right:
►NOTE◄ Since an item is always an entity (here the OrderLineItem type), the profile can cause an update of the item's properties via the return value. Whether the position or the surrounding order has already been saved is irrelevant. The return value is simply merged with the data of the adjacent reference object. |
|