Configuration Guide
Configuration Guide
Breadcrumbs

Business Policies

Definition

A Business Policy allows to configure how to trigger actions on Object Types through a Feature with an optional configured Workflow.

Each time a Business Policy is created, an associated Job is created (according to the id of the Business Policy) in the "Business Service" tab. This job should be executed immediately or launched in scheduled mode to activate the Business Policy.

A Business Policy is triggered when:

  • the configured activation event is reached:

    • A scheduled activation time has been reached, either unique or recurring (e.g: every Sunday at 5pm or next Monday at 9am)

    • A fixed execution time has been reached (trigger execution fixed for a certain task/object)

  • a domain event has been received (e.g: an identity has been created)

However, a Business Policy might not be triggered if no execution targets could be resolved (the object may have been deleted...).

Usage

When the end of validity date of a user expires, we want to launch a Workflow to his/her manager.
In this case, the manager can validate or modify the end of validity date.

Steps

1

Configure an update Feature on Identity type with:

  • "endofvaliditydate" attribute in READ_WRITE mode

  • an operation which triggers a Workflow

2

Configure the Workflow which will be launched when this Attribute is modified.

3

Configure the Business Policy with an action using a Groovy script.

4

Access the update Feature of an Identity and add an end of validity date.

5

Access the admin portal.
Click on "System" then on "Jobs" to execute immediately the Business Policy (on the Business Service tab).

The Business Policy has been executed.
The Workflow has been generated for each identity concerned by the Business Policy.

image-20220928-065633.png

6

Access the Workflow dashboard on the User Portal to see all identities concerned by the user task.

image-20220928-065629.png

Configuration

🎯

You can access the Business Policy configuration :

  • by clicking on "Portal" → “Business Policies”

  • by clicking on "System" → "Configurations" → "Business Model" and perform an import/export.

Properties

Property name

Type

Mandatory

Description

Values (default value in bold)

id

String

YES

The identifier is the unique identifier of each Business Policy.

It is case sensitive and no special characters (except - or _) are allowed.

-

name

String

YES

The Business Policy name.

The name may be different from the identifier.Specifying the name first allows to define automatically the identifier.
Must be at least 4 characters long.

-

active

Boolean

NO

Allows to define if the Business Policy is activated or not.

ON, OFF

description

String

NO

Allows to describe the purpose of the Business Policy.

-

objectKind

Enum

YES

Allows to link the Business Policy to an Object kind.
The Policy will apply to this Object kind.

Identity, Organization, Resource, Role, Role Publication

scope

Scope

YES

Allows to configure on which Objects the Business Policy will be applied.

It is possible to define several Object Types.

-

activation

Enum

YES

Allows to choose how the Business Policy will be triggered either:

  • according to an event on an Object

  • according to a schedule

Object Event, Scheduled

handleEvent

RuleDefinition

NO

A test Rule to decide whether to handle the current event (can only be used in EVENT mode)

-

pageSize (only if activation is set to "Scheduled")

Integer

NO

Used to indicate how many objects can be processed in a batch by actions.

10 to 100

executionPlan (only if activation is set to "Scheduled")

Enum

NO

Used to configure the trigger frequency of the Business Policy:

  • Once: choose a scheduled date

  • Cron: choose how long the Business Policy is triggered (on the first day of the 10 months at 10 a.m., every monday...)

  • Interval: choose a frequency (every minute, every hour...)

Once, Cron, Interval

actions

Script, Notifications

NO

Used to configure:

  • a Groovy script to configure on which Feature the Business Policy is triggered.

  • a Notification to send when the event occurs.


It is possible to configure several actions.

-

Example

Business Policy Example
XML
<?xml version="1.0" encoding="UTF-8"?>
<kit:DataSet xmlns:atlastcf="http://www.memority.com/atlas/tcf/1_0" xmlns:ctd="http://www.memority.com/citadel/1_0" xmlns:ctdbpmn="http://www.memority.com/citadel/bpmn/1_0" xmlns:ctdbum="http://www.memority.com/citadel/bum/1_0" xmlns:ctdcore="http://www.memority.com/citadel/core/1_0" xmlns:ctdidm="http://www.memority.com/citadel/idm/1_0" xmlns:ctdrep="http://www.memority.com/citadel/rep/1_0" xmlns:ctdrule="http://www.memority.com/citadel/rule/1_0" xmlns:ctdtnt="http://www.memority.com/citadel/tnt/1_0" xmlns:i18n="http://www.memority.com/toolkit/addons/i18n/1_0" xmlns:kit="http://www.memority.com/toolkit/1_0" xmlns:maiaamcp="http://www.memority.com/maia/amcp/1_0" xmlns:netfilter="http://www.memority.com/toolkit/network-filtering/1_0" xmlns:rule="http://www.memority.com/toolkit/rule/1_0" xmlns:ruleaddon="http://www.memority.com/toolkit/addons/rule/1_0" xmlns:search="http://www.memority.com/toolkit/search-expression/1_0" xmlns:settings="http://www.memority.com/toolkit/addons/settings/1_0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <ctdbum:BusinessPolicy id="identity-triggerWorkFlow-Manager-policy">
      <name>Trigger external workflow after manager update</name>
      <description></description>
      <activation>OBJECT_EVENT</activation>
      <pageSize>10</pageSize>
      <scope type="EXPRESSION" objectKind="IDENTITY">
         <searchExpression>
            <search:Prop op="EQUALS" name="status">
               <value script="false">NORMAL</value>
            </search:Prop>
         </searchExpression>
         <objectTypes>
            <objectType>internal</objectType>
         </objectTypes>
      </scope>
      <active>true</active>
      <actions>
         <action>
            <script><![CDATA[LOG.debug("Start objectEvent-business-ManagerUpdate-policy")
      // Get Manager
      def manager
      def managerId
      def originalManager
      if(OBJECT.type == "internal"){
        manager = FIND.identity().withAttributesProjection("email","preferredLanguage","commonName").withId(OBJECT.manager) as ApiObject
        originalManager = OPERATION.originalObject?.manager
      }
      else{
        manager = FIND.identity().withAttributesProjection("email","preferredLanguage","commonName").withId(OBJECT.budgetManager) as ApiObject
        originalManager = OPERATION.originalObject?.budgetManager
      }
      managerId = manager.id
      if (OPERATION.operation == ObjectOperation.PATCH && managerId && managerId !=originalManager) {
        API_FEATURE.newExecutionFor("identity-auto-updateManager")
                .withObjectId(OBJECT.id)
                .withField("originalManager",originalManager)
                .withPatch()
                .set("manualOngoingAction").value("Manager Update")
                .end()
                .execute()
        LOG.debug("End objectEvent-business-ManagerUpdate-policy")

        ActionOutcome.success()
      }
      return ActionOutcome.noop()]]></script>
         </action>
      </actions>
      <secondaryActions/>
   </ctdbum:BusinessPolicy>
</kit:DataSet>
  • Object Policies

    An Object Policy is an Identity Management Service Policy allowing to execute arbitrary actions on Managed Objects, either on a scheduled basis, or in reaction to an Object Operation.

  • Deduplication Policies

    A Deduplication Policy describes how duplicates should be searched for when creating a managed object.

  • Manual Provisioning Policies

    A Manual Provisioning Policy allows to define that manual provisioning or deprovisioning Workflow is launched when the Role assignment status changes.

  • Object Lifecycle Policies

    An Object Lifecycle Policy allows to configure rules, on all Object Types, that will alter an Object attribute directly when certain lifecycle events occur.

  • Password Policies

    A Password Policy determines how passwords should be composed and which rules apply to their lifecycle.

  • Role Request Policies

    A Role Request Policy allows to define if a Role can be requested, for whom, by whom, and using which Workflow.

  • Memority MFA Account Policies

    A Memority MFA Policy allows to configure how multi factor authentication should be applied to a population of user

  • SoD Policies

    In Memority, SoD rules are based on a SoD policy. A SOD Policy allows to define what kinds of conflicts you can specify and what attributes the system will use to detect them.