ImportTechnicalAccountsFromCSVExecutor

Long Running Task (LRT) that bulk-creates or updates Technical Accounts in CzechIdM by reading a semicolon-separated CSV file. Each CSV row represents one technical account. The task maps configurable column names to entity fields, validates the whole row before it writes anything, supports dry-run mode, and never re-points an existing account to a different provisioning system.

Version

How It Works

• The task reads the attached CSV file line by line (first line = header).
• For each data row it looks up an existing Technical Account by the value in the identifier column (matched against code) scoped to the system named in systemcolumn. The same code may legally exist on different systems - the lookup returns only the account linked to the row's system, if any.
• Depending on whether the account exists and which behaviour flags are set, the account is created, updated or skipped.
• Before anything is written, the whole row is validated in one gate. Every problem found in the row is reported together and the row is aborted without a partial write.
• Optional columns assign identity and role guarantors, link the account to a provisioning system and associate it with a Technical Asset.
• All item-level results are written to the LRT task log.

CSV Format

Task Parameters

File and Format

Column Mapping

Each of the column parameters below is the exact name of a column in the CSV header (case-sensitive). multivalueseparator is the exception - it is a value, not a column name.

Behaviour Flags

All flags are of type Boolean and default to false. All of the flags are required - setting them to blank is not valid and the import will not run.

Processing Logic per Row

Multi-Value Columns

directidentitycolumn and guaranteerolecolumn can contain multiple values separated by the multi-value separator (default `|`). Whitespace around each value is trimmed.

Example cell value:

Each value is resolved independently, but a value that cannot be resolved does not get skipped - it fails the whole row together with every other problem found in it.

System Linking Rules

Every Technical Account is expected to have exactly one AccAccount. The link is maintained via the TechnicalAccountAccount join entity.

Creating a New Account

When cancreate = true and the identifier is not found:

• systemcolumn is mandatory. If it is not configured or the system is not found in CzechIdM, the row fails with CSV_IMPORT_ACCOUNT_ERROR.
• If mappingcolumn is configured, the named mapping must exist on the system and must be of type TECHNICAL_ACCOUNT PROVISIONING. Otherwise the row fails.
• If mappingcolumn is not configured, the system must have exactly one TECHNICAL_ACCOUNT PROVISIONING mapping. Zero or more than one also fails the row.
• Once system and mapping are validated, a new AccAccount is created (uid = identifier) and linked via TechnicalAccountAccount.

Updating an Existing Account

The system, mapping and uid of the linked AccAccount are never changed and no new AccAccount or link is created. The tier and zone of the linked AccAccount are written when the corresponding columns are configured.

The systemcolumn and mappingcolumn values are a hard consistency check: a mismatch fails the row.

Technical Asset Assignment

Technical assets are looked up by their code (TechnicalAsset.code), not by the Name field. An asset code that cannot be resolved fails the row.

canchangeta does not switch the column off. The column is always read and the asset always resolved; the flag only gates a real change on an already existing account.

Assignment Check Script

Whenever a row ends up with a technical asset, the pair (asset, target AccAccount) is validated by a configurable Groovy script through TechnicalAssetService.isAssetAssignable. The script is named by the private configuration property idm.sec.tech.accountAssetAssignment.checkScript.

• techAccountAssetAssignmentAllowAll - the shipped default, always returns true.
• techAccountAssetAssignmentZoneMatch - requires the asset zone and the AccAccount zone to match; an asset without a zone is always accepted.

The check is evaluated against the effective asset (the one from the CSV, or the one already assigned when the CSV does not change it, so it also runs on rows that do not mention an asset) and the target AccAccount, that is the account as it will look once the row's tier and zone are applied. When the script rejects the pair, the row fails with CSV_IMPORT_ACCOUNT_ERROR before anything is written.

Code and Name Uniqueness Rules

Code (''identifiercolumn'' -> ''code'')

• code is unique per system. The same code may exist on different systems - each combination (code, system) yields its own Technical Account.
• The lookup combines code with the system named in systemcolumn. An account linked to a different system is invisible to the lookup, so a new account is created for the row's system.
• The lookup degrades to code-only in three cases: systemcolumn is not configured, the cell is blank, or the system named in the cell does not exist in CzechIdM. Uniqueness is then not enforced either - there is no system context to validate against, so "orphan" accounts (those without an AccAccount link) are not constrained on code at all and several orphans with the same code may coexist.
• For a new account the task checks up front that the code is free on the target system and fails the row otherwise. The product-side processors (TechnicalAccountCodeCheckProcessor, TechnicalAccountAccountCodeCheckProcessor) are the second line of defence; on the import's create path only the latter can still raise TECHNICAL_ACCOUNT_ALREADY_EXISTS_ON_SYSTEM, when the link is saved.

Name (''namecolumn'' -> ''externalCode'')

• externalCode (FE label "Name") must be unique across all Technical Accounts in CzechIdM, regardless of which system the account is linked to.
• A blank namecolumn cell (resulting in an empty externalCode) skips this validation.
• Enforced by the framework in AbstractReadWriteDtoService.validateEntity. The conflict surfaces as DuplicateExternalCodeException at save time, which the task records on the item as CSV_IMPORT_ACCOUNT_ERROR.

Dry-Run Mode

The task supports CzechIdM's built-in dry-run flag. When dry-run is enabled:

• No Technical Accounts are created or updated.
• No guarantors are assigned.
• No AccAccounts or TechnicalAccountAccount links are created and no tier or zone is written.
• Rows that would be created or updated are logged with CSV_IMPORT_ACCOUNT_WOULD_BE_CREATED or CSV_IMPORT_ACCOUNT_WOULD_BE_UPDATED and state NOT_EXECUTED.
• Skipped and failing rows are logged exactly as in a real run, with state EXCEPTION - a dry run therefore reports the same failures a real run would hit, including a rejection by the assignment check script.
• Would-be operations are written to the application log at INFO level (prefix [DRY-RUN]).
• The task counter still increments, so the row count can be verified.

Result Codes

Examples

Minimal CSV Example

Only identifier and name columns - no system, guarantors or asset.

Task configuration:

Full CSV Example

Task configuration:

See Also

• importtechassetlrt - the sibling task importing Technical Assets.