Import (Integration function)
The Import (Integration function) function performs an Import based on the XML structure transferred as parameter a.
Even if the note for parameter a explicitly refers to the Batch import, a Single import structure can be used instead, as long as its functionality covers the desired Import.
If it is a Batch import that uses the value true for the attribute responsive, it returns a list of the entities affected by the import (see note for parameter b in table).
The optional parameter b can then be used to save this list as a DOM object with the specified name. The return value of the function is the number of affected entities.
If the parameter b is not used, this list (in XML format) appears as the return value of the function.
Otherwise, (Batch import without responsive attribute set or Single import) the number of entities affected by the import appears as the return value.
The login context for the Import is defined by the Integration login object, which parameter c defines as XML structure (a text value or a file path to a text file).
With parameter d, the function call can be qualified as a test run, so that the defined Import is not executed.
The return value of the function is then always -1.
CAUTION
By default, the Import (Integration function) function already triggers the defined Import during a 'mapping test' (see the note for parameter d in the table).
Parameter
|
Parameter |
Description |
Example |
Note |
|
a |
XML structure for an Import |
BatchImport
<?xml version="1.0" encoding="UTF-8"?><core:BatchImport ... trxControl="SINGLE"> <batch action="DELETE"><base:User id="815"></base:User></batch> <batch action="DELETE"><base:User id="816"></base:User></batch> ... <batch action="DELETE"><base:Role id="151"></base:Role></batch></core:BatchImport>
|
In principle, suitable XML can be assigned directly as text. Typically, a return value of the Integration function create xml from node is used, which evaluates a node of the target structure defining a Batch import or Single import (see the example below). An 'Import node' can be configured based on Orchestration templates and then connected to source data, e.g. via mapping. Then an executable XML structure including the necessary namespace declarations (omitted on the left in this example) is dynamically generated at profile runtime. |
|
b |
Name for a DOM object in which the result list of a 'responsive' Batch import should be stored |
importResponse |
Return value for the example for parameter a
<?xml version="1.0" encoding="UTF-8"?><list ... > <entry id="815" ... xsi:type="base:User">...</entry> <entry id="816" ... xsi:type="base:User">...</entry> ... <entry id="151" ... xsi:type="base:Role">...</entry></list> |
|
c |
XML structure for a Integration login |
<base:LobsterDataLoginRequest xmlns:base="SCM.BASE" userName="jabend" selectedRole="2" selectedCompany="501" /> |
In principle, suitable XML can be assigned directly as text. Instead, the value can also be assigned to a variable, which is filled at runtime using the Create Login Request (Integration function) function. |
|
d |
declares with the value true the function call as test run |
true (test run, i.e. import is not executed) false or no assignment (no test run, i.e. import is executed) |
Assigning the VAR_IS_TEST variable, which is automatically managed by the system. This parameter can be helpful to prevent unwanted imports, for example during a 'mapping test'. |
Example
In the course of a profile call, a Batch import should perform different actions (create, modify, delete) for entities of a type neutrally named as an Object below.
For this purpose, the Batch import to be executed is first defined in the 'importDefinition' node (including mapping). For this node, the property 'Applies to SQL only' is set to 'Yes', since its contents should not appear in the target file.
The structures for the sub-node 'BatchImport' and the 'Object' placed in its batch node (e.g. a base:User structure for Users) were created based on Orchestration templates and linked to source data by mapping where necessary.
The calculation node 'createLoginRequest' stores login data generated by the Create Login Request (Integration function) function for import in a variable 'var__LOGIN_REQUEST' declared for this purpose.
The 'executeImport' node defines in the calculation field 'resultsCount' the actual execution of the import via the Import (Integration function) function and assigns its return value (XML list) as sole content for the target file via the 'results' field:
|
|
The ‘resultsCount’ calculation field first uses the create xml from node function to generate the XML for the ‘BatchImport’ node. The b parameter, which can be used to suppress the xml header, is not used. The XML therefore contains the header. |
|
|
When Import (Integration function) (integration function) is then called, the Batch import XML is included as the result in the a parameter. The b parameter defines that the import response is to be saved as a DOM object with the name ‘importResponse’. The c parameter is used to retrieve the login data from the ‘var__LOGIN_REQUEST’ variable. The d parameter refers to the VAR_IS_TEST variable provided by the system, as the call should be made as a test run if, for example, a ‘mapping test’ is executed. |
|
|
Finally, the ‘results’ node should output the return value stored in the ‘importResponse’ DOM object as formatted text. This enables the general integration function |
►NOTE◄ The same result could be achieved more easily in the example if the 'results' node and the parameter b were omitted when calling Import (Integration function). In this case, no DOM object is created and the return value is the XML response from the Batch import directly available as text. However, the possibility of accessing the return value as a DOM object in order to evaluate or otherwise process the contained data is then no longer available.