Versions Compared

Old Version 12

changes.mady.by.user Ann Base (Deactivated)

Saved on

compared with

New Version 13

changes.mady.by.user Ylva Andersson

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Updates in "Core Objects: Drop Relation" for Smart ID 22.04.

Excerpt


Expand
titleCore Objects: Check Relation

Description

Use this task to check if a relation between two core objects exists. The names of both data pools have to be provided. The direction of the relation is not relevant, meaning that source and destination may be exchanged.

Configuration

To use this task, configure the following delegate expression in your service task:

Code Block
${checkObjectRelationParametrizedTask}


The following parameters can be configured in Identity Manager Admin:

ParameterMandatorySample ValueDescription
sourceDataPoolName


The name of the source data pool that is used to check the relation with the destination data pool.

destinationDataPoolName


The name of the destination data pool that is used to check the relation with the source data pool.
resultVariable


The name of the field indicating if a relation between the source and destination data pool exists. Contains either a "true" or "false" value.

"True" means that the objects are related to each other. "False" means that there is no relation between them.



Expand
titleCore Objects: Create Relation

Description

Use this task to create a relation between two core objects.

Object Relations tab

In this tab you manage the object relation types. A default entry is already set per tenant. Exactly one configuration must be the default configuration which is used when saving data, see Set up process in Identity Manager, the Save Data task.

Include these two fields in an object relations configuration:

  • Name: name of the object relation type
  • Default: determines if this configuration should be the default configuration

Configuration

To use this task, configure the following delegate expression in your service task:

Code Block
${createRelationParametrizedJavaDelegate}

The following parameters can be configured in Identity Manager Admin:

ParameterMandatoryValueDescription

source


Data pool name of the source of the relation, which has to be created. The core template name of this data pool will be saved in the database.

destination


Data pool name of the target of the relation, which has to be created. The core template name of this data pool will be saved in the database.

includeRelationTypeToCompareOfObjects

Valid values:

  • true
  • false (default at design time) 

Flag indicating if the relation type should be included when searching if the relation already exists. If you want to create multiple relations of different types between two core objects this parameter has to be set to true.

exceptionIsThrownIfRelationAlreadyExists

Valid values:

  • true (default at design time)
  • false

Flag indicating how the application reacts if the relation already exists. If set to "true" then throw Exception, else do nothing.

relationType

Default
Type of the relation. The object relation type must exist or an exception is thrown.



Expand
titleCore Objects: Drop Relation

Description

Use this task to remove existing relations between objects. The removal applies for all relations between one specific object and either:

  • a single second object, or
  • all other objects belonging to the named Data Pool
  • all other objects belonging to the same named template.

Furthermore, it is independently possible to restrict the removal to relations of a specific type.

Example: An employee started working with a replacement card. Later he or she receives an employee card. The connection to the re-usable reusable replacement card can then be removed.

Note
  • Single: Both objects must be loaded into the process map before the relation can be dropped.
  • Either secondDataPoolName, secondDataPoolNameDropAll, or coreTemplateName must be provided but not both . Only one of them is allowed. The one ones that is are not used must be deleted.

Configuration

To use this task, configure the following delegate expression in your service task: 

Code Block
${dropRelationsParametrizedTask}

The following parameters can be configured in Identity Manager Admin:

ParameterMandatoryValueDescription

dataPoolName

Image Modified


Data pool name of the object whose relation shall be removed.

secondDataPoolName-


(warning) Only one of these three parameters is allowed to be filled!

Single Drop: Data pool name of the second single object. This object has to be available inside the Process Map.
secondDataPoolNameDropAll-Data pool Drop: Name of a Data pool. Relations to all objects belonging to this data pool are removed.
coreTemplateName-Core Template Drop: Name of a Core template. Relations to all objects belonging to this template are removed.

objectType



Deprecated. This parameter has the same meaning as coreTemplateName and is only provided for downgrade compatibility.

relationType-
When configured, only relations of the specified type are removed.



Expand
titleCore Objects: Expiry Check

Description

Use this task to find core objects (for example, soft tokens), that will expire within a given time range.

Configuration

To use this task, configure the following delegate expression in your service task:

Code Block
${coreObjectExpiryCheckParameterizedTask}

 The following parameters can be configured in Identity Manager Admin:

ParameterMandatoryDefault valueDescription

coreTemplateNameList


Comma separated list of core template names that shall be the base of the search.
fieldName


Name of the data pool field that indicates the expiration date, for example, ValidTo. The data pool must belong to the core template(s) mentioned above.
offsetInDays


The offset in days before the related core objects expire.

The base is the field specified by fieldName, for example ValidTo. If you provide a value for offsetInDays, then logically it is

ValidTo - offsetInDays = dateToFindSofttoken

  • If dateToFindSofttokens is still in the future compared to the currentDate, then the soft token will not be found.
  • If dateToFindSofttokens is equal to the current date or if it is in the past, then the soft tokens will be found.

Example:

Expiry date of a soft token is 31st March 2017. If the offsetInDays is set to 30, the service task will only find the soft token with the beginning of 1st March 2017.

coreObjectIdListVariableName-CoreObject_Ids

Name of the variable containing the core objects that were found during the search. It contains only the core object ids.

Example: PcmDpCertificate_Coreobjects

Meta_CoreObjectState_Field


Name of the data pool field that indicates the state of the core object. The data pool must belong to the core template(s) mentioned above.

Example: Meta_CoreObjectState_PstmDpCertificate or Meta_CoreObjectState_BaseDpEmployee

Meta_CoreObjectState_Value


The actual state that shall be used for filtering the search.

Example: issued, active etc.



...