Import From Report

Last modified 23 Apr 2024 08:57 +02:00
Advanced Feature

The import from report, often requires scripting and other special configuration options. If the set-up is not correct you are risking potential override or deletion of midPoint and/or account data.

Proceed with caution.

Import Behaviour 'Import From report'

MidPoint supports 'import reports'/'reverse reports'. This feature is still experimental. The basic idea is that the report output generated by midPoint can also be used in reverse way - you can import it back to midPoint. In addition, it is also possible to import a custom defined report output.

This might be handy if you wand to update or change some already imported objects in some other way than through the midPoint UI (e.g. in some spreadsheet) and reimport them back. Yet as mentioned above, this feature is still experimental and such details often require custom configuration.

Midpoint support two kind of import configuration. Configuration for Object Import and Import script.

Object Import

MidPoint has to understand the report output data structure to preform the import correctly. This is configured in the report (ReportType), in a similar way as for exporting, so the configuration has to contain the information about columns and paths to which they are mapped. For details on how to configure standard reports please see this link. For now, only reports generated from object collections and CSV format is supported (CSV FileFormatType).

Example of Imported File:

CSV file
"Name";"Administrative status";"Valid from";"Nick";"AssignmentOid";"Subtype"
"testUser01";"enabled";"2020-07-07T00:00:00.000+02:00";"nick1";"00000000-0000-0000-0000-000000000008,00000000-0000-0000-0000-000000000004";"sub1,sub22"
"testUser02";"enabled";"2020-07-07T00:00:00.000+02:00";"NICK2";;

Example below shows report (ReportType) configuration for importing CSV file with header and two records above.

Import Behavior Example

Behaviour and Options

You have to specify the direction of the report,in this case import and rather than the export direction, for this you need define the element behavior. Behavior contains the direction Import or Export. Also, a part of the behavior configuration is the parameter importOptions, which has the following elements:

Name Description Type

overwrite

If set to "true", objects that are in the repository will be overwritten by the imported objects. It may not be applicable to all import types. E.g. it makes no sense for import from resource, as this is not storing objects in the repository directly.

boolean

keepOid

If set to "true", objects that are overwritten will reuse the same OID as previous objects. May be potentially dangerous. USE WITH CARE.

boolean

stopAfterErrors

Number of errors that will cause import to stop. If set to one the import will stop on first error. If set to zero or a negative value the import will continue in case of any number of errors.

int

summarizeSucceses

If set to true the successfully imported items will be summarized in the result. WARNING: setting this to false may result in a very large result structure and may cause overflow of the system memory.

boolean

summarizeErrors

If set to true the import errors will be summarized in the result.

boolean

referentialIntegrity

boolean

validateStaticSchema

boolean

validateDynamicSchema

boolean

encryptProtectedValues

boolean

fetchResourceSchema

boolean

keepMetadata

If set to true then the metadata from the source file will be kept after the operation. If set to false then the original metadata will be replaced with new metadata on each object.

boolean

modelExecutionOptions

If present, these options are used for adding objects into the repository. Null option values might be overridden by import-related options. In particular, the missing "raw" option is overridden to "true". So, if you want the operation run in non-raw mode, set "raw" option to "false" (e.g. runs also global templates, policy configuration, etc…​).

ModelExecuteOptionsType

compatMode

Compatibility model. If selected then the data parsing will be less strict. E.g. removed element will be ignored.

boolean

In previous example of report we define mapping values from columns to items in new object. The name of the column in the CSV file has to be same as the name defined in view. Definition of the name from a view has some rules. Name is obtained from Label of DispalyType for column, when Label is empty, then Midpoint finds the name from the item definition based on the Path element in a column.

Definition of a column also contains import/expression which can be used to define a script for generating items. Scripts have to return a real value, for example String or List of values for multivalued items, for example List<AssignmentType>. The script has a variable input which is a String when the item is single valued or a List<String>, when item is multivalued.

Import Script

You can define importScript in element behaviour. The Script contains variables with the same name as headers of imported CSV file. For example the following file will provide us with the variables with names username, role_name, action, valid_from and valid_to.

Example of Imported File
CSV file
"username";"role_name";"action";"valid_from";"valid_to"
"testUser02";"Superuser";"A";"2018-01-01";"2025-05-01"
"testUser01";"Superuser";"D";;
"fakeUser";"Superuser";"M";"2018-01-01";"2025-05-01"
"jack";"Superuser";A;"2018-01-01";"2025-02-01"
"jack";"Superuser";"M";"2018-01-01";"2025-05-01"
"jack";"FakeRole";"M";"2018-01-01";"2025-05-01"

In the next example we change the assignments of users based on username.(e.g. the first line 'testUser02'). The operation which is executed is specified by the variable action ('A'=add, 'M'=modify, 'R'=remove). The target of the assignment is chosen via the variable role_name, which represents a role in midPoint. Variables valid_from and valid_to are mapped to the properties activation/validFrom and activation/validTo of assignment.

Import Script Behavior Example
Was this page helpful?
YES NO
Thanks for your feedback