pc:XmlImport

Imports one or more sets of literal appdata or metadata into a USoft repository. To build the data to be imported from executing USoft Blend directives, instead of supplying them as literal data, use pc:XmlImportApply instead.

<pc:XmlImport
     alias="name-literal"
     commit="commit-mode"
     source="file-path" >

  data-to-be-imported

</pc:XmlImport>

commit-mode  :=  { commit | rollback }

The required alias identifies the connection to the Rules Engine that you want to use. For aliases, see pc:RunRulesService.

The optional commit determines whether or not the operation is committed after import. Choose the "rollback" option for debugging purposes, in particular to find out if the external data violate any rules. In terms of data change, the net effect of running the operation with "rollback" is null.

To import successfully, you must specify either the source attribute or the data-to-be-imported XML content. If you use source, its value must point to an existing file on the file system that contains the data. Otherwise, the <pc:XmlImport> element must have exactly 1 child element.

This example resets a "Allow_Disable_Constraint" configuration parameter in USoft Authorizer so that, in a next step, data may be imported against a disabled Rules Engine.

<pc:XmlImport connection="{$authconn}"  commit="commit">
  <Additional_Parameters documentName="Additional Parameters">
    <T_AUTH_OC_PARAMS OC_ID="LAN" SET_TYPE="URE" PARAM_NAME="Allow_Disable_Constraint" PARAM_VALUE="True"/>
  </Additional_Parameters>
</pc:XmlImport>

The data to be imported must have the USoft single-table or multi-table XML format. This format is specified in USoft Definer Help. You can produce this format by calling sql:DataTableSetExport as a Blend call as in:

<pc:evaluate select="sql:DataTableSetExport($instance, '.*', 'c:\temp\myoutputfile.xml', '')" />

or by calling, from a USoft tool interface:

INVOKE XML.MultiExportTables WITH SELECT regular-expression ...

If the import is successful, the return document looks something like this.

This is potentially different from the input data, because the return document is a report of record values as they appear, or would appear, after constraints are applied. For example, if a business rule causes the INSURANCE flag for the imported record to be set to 'Y', the return data has INSURANCE='Y' but the input data has INSURANCE='N':

If you pass commit="commit", the return document reflects the database state. If you pass commit="rollback" (the default), the return document reflects what the database state would be if you had committed.

By specifying the optional assign:variable attribute, you can apply an xpath-expression to the return document and store the result in variable.

assign:variable="xpath-expression"

If you have been importing multiple documents successfully, each of the imported results is queued in the variable. The results may be dequeued one-by-one.