How to make conditional rule strings in account templates

[Abinash Behera]

I have a date in a string format in IDM and while provisioning to a custom database account this needs to be parsed using the following format:

Date format: DDMMYYYY

 

Rule String: %UCU06:5,4%-%UCU06:3,2%-%UCU06:1,2%

 

the format yields YYYY-MM-DD

 

however, when there is no date this yields "--", and that fails provisioning as that is not a valid date type for a database

 

could i check in the first place if the date is blank and then convert the date using rule strings?

 

any pointers or alternate solutions are appreciated. The base date format may not be changed as that is the customer specified format.

 

Thanks

Abinash

[Philippe.Guihard]

Hi Abinash,

 

I do not see any easy quick solution based on existing template rule strings and built-in functions.
The solution is to write a Custom Function Program Exit.
Please look at:

https://docops.ca.com/ca-identity-manager/12-6-8/EN/reference/program-exits/common-program-exits/custom-function-program-exits
It requires some technical development skills.
In the past I had written the following TEC595663 tech doc:
https://support.ca.com/us/knowledge-base-articles.TEC595663.html
You can see my sample Custom Function Program Exit which returns an XML block with the expected formatted date as "yyyy-mm-ddTHH:MM:SSZ" of the current date/time in local time.
In your case, %UCU06% can be passed in argument to your custom function, e.g.: %$FuncName(%UCU06%)%, your program exit can test if the argument is empty, if so returning an empty result value else the formatted date.

 

Philippe.

[SumeetM]

Hi Abinash,

 

Instead of using Rule Strings, you can try PX policy to implement date business logic and update account directly or update Custom Field.

 

Regards,

Sumeet

 

 

 

[Abinash Behera]

Hi Sumeet, 

 

I would like to pursue this idea, as a Program exit would be a bit tricky. Are you suggesting we can change the values in the customfields in an Globaluser, without making changes to to the user in IDM?

 

could you please elaborate?

 

Thanks

Abinash

 

PS: how are you doing? been a long time since we met!

[SumeetM]

Hi Abinash,

 

I am doing good thanks.

 

You can't directly update Custom Field of Global User via PX. Is the date value validation and propagation required only for one endpoint? Or required for multiple endpoints?

 

Option1:

In any case, if I assume that, you don't need to update Global User's custom field, then use PX to directly update Date attribute. PX will give flexibility for validation & update date value in whatever format which is expected by endpoint. You can have different types of validations and values for different types of endpoints.

 

Option2:

Now if you still want to update Global User's Custom Field, go with BLTH. Inside BLTH, perform all the date validations which is required and update the User Store attribute which is going to hold date value. Updating the User from BLTH will update the Date value at User Store and automatically the value will propagate to Global User's Custom Field if Attr Mapping is correctly set. Following code should work:

 

User user = BLTHContext.getSubject();

user.setAttribute("dateAttr", "2017-08-29");

user.modifyObject();

 

 

Regards,

Sumeet

 

[Abinash Behera]

Hi Sumeet,

 

I am trying to configure a PX to update the account with the required value, and that seems possible, however, I am stuck at a point in the task where the account is not created when the policy is evaluating, as the task is a create user task and the birthright AD account is an identity policy. I tried, AssignProvisioningRoleEvent to no avail. How do I delay the update till the account is created?

 

Thanks,

Abinash

[SumeetM]

Hi Abinash,

 

For validation, while updating AD attributes, you can check whether AD account is already present or not in PX. If not created, don't update the account. This can be done via Entry Rule or Action Rule Condition at PX.

 

However, this was for validation. Once PX has executed, it will never execute again. If you want to delay the update process via PX by certain seconds, a java program can be executed in between to hold update having Thread.sleep() or r14.1 has an in-built feature for having delay inside PX.

 

Again that's temporary solution. All events in Identity Manager are asynchronous in nature that's why this problem occurs. If you want a synchronous solution, you need to move towards Java code (BLTH/Event Listener) for creating AD account or assigning Provisioning Role, checking if account is created and once created, update the AD account attributes. Everything in Java code being synchronous.

 

Regards,

Sumeet

 

[KennyV]

I would not advise with custom coded provisioning program exit as that has been marked for deprecation long ago and adds complexity/cost to upgrades and maintainability of the system.

 

Instead you may want to review the below documentation link which mentions some existing built-in rule string functions. The FIRSTOF and NOTEMPTY ones look like they might be helpful to meet your requirements.

 

Built-in Rule Functions - CA Identity Manager - 12.6.8 - CA Technologies Documentation 

[Abinash Behera]

Hi Kenny,

 

The NOTEMPTY does not seem to me as a likely option as it fails provisioning when the value is empty, and that is no different from now, which fails provisioning due to an incorrect format for the date.

 

The FIRSTOF is taking the first value, in my case i am creating the entire date from its value, so: 

 

for example:

FIRSTOF(%UCU06:5,4%-%UCU06:3,2%-%UCU06:1,2%,'')

 

this will create the first value as '--' and that is not blank so it will be set and fail provisioning. 

 

have i understood it incorrectly?

 

Thanks

Abinash

[KennyV]

The FIRSTOF or NOTEMPTY would be useful if you were trying to set some default values if no date was set in %UCU06% in your case.

 

As was mentioned in someone's earlier reply you could look to use PX Policies or Javascript in the IM screen to ensure that a value exists and/or a default value is set and also look to handle the formatting in the IM layer such that the already formatted value (if any) is passed to the Provisioning User's %UCU06% and then you can simply reference %UCU06% without trying to reformat it within a template's rulestring. That is probably best.