Hi there “Process Automation” fans,

Welcome to a new installment of “Process Automation” tips.

It’s a recurring question in each project: How to (re)construct a ‘UserDN’ value? What kind of value would it be and where do you need it for? Well, you mostly need it when you want to assign a task directly to a specific user; The value will look something like this:
cn=sysadmin,cn=organizational users,o=opa_tips,cn=cordys,cn=defaultInst,o=25.1.com

There are different ways to accomplish this with service calls like ReadUser, ReadPerson, GetUserDetails, and FindUserByName (you can find great examples here and here). Only, during a simple R&D session, I stumbled on another great (or maybe the best) service call to get a ‘UserDN’ quickly…

Let’s get right into it…

Task assignment happens in 3 places; That’s from a BPM perspective on activity level; That’s from a lifecycle perspective on activity level; That’s in the UI forwarding/assigning a task from someone to another someone. We focus on the lifecycle part as that’s the most challenging in projects.

You can also use assignment types like “Organizational unit” (in BPM it’s a “Team”), “Role”, and “Worklist”. They are strait forward; You’ll find examples here.

A typical use-case within each project is this one: You have a ‘Case’ type of entity with a lifecycle starting an activity from a state-entry construct. You want to assign the task to a selected user (from a toOne ‘Person’ relation) which converts into a new value for a new property; like case_user_dn (with 256 length):

All nice and great…gaining such ‘UserDN’ value in the property is advanced business logic via a BPM (short-lived) which we can start onChange (e_orc_set_user_dn) of a toOne ‘User’/‘Person’ (identity entity) relation change…if you have it on your entity:

With this part in place and a publication, you can create a simple case which will fail because of an empty ‘UserDN’ (for our lifecycle task):

The BPM bpm_set_user_dn should have an instance in the PIM…have a look for yourself!

All totally valid; when you fill in a valid ‘UserDN’ value (a copy from your ‘User Manager’ artifact), you’ll be fine…The only thing left now is automating the BPM logic setting the value automagically!

BPM implementation

Before we can set our value, we need to get a grip on the entity instance (incl. the relation). So, that’s a ‘Web service’ building block on the entity with READ (which reads also the toOne relation) and UPDATE (to set our precious value). By now, (I guess) you know we also require a service container of type ‘Application Server’ in the ‘System Resource Manager’…comment me otherwise!

Next step is writing some pseudocode for our BPM; Normally some steps like this:

1
2
3
4
5
6
7
8
9
10
11

Case caseInstance = ReadCase(instanceProperties.rootEntityInstanceId);
Person personInstance = ReadPerson(caseInstance.toOneMember.ItemId);
User userInstance = ReadUser(personInstance.toOneUser.ItemId);
//This is also possible to execute
User userByNameInstance = FindUserByName(userInstance.UserId); //OR personInstance.User_ID
//Eventually you want a result from this call...To validate your string
LDAP entry = GetUserDetails(String.format("cn=%s,cn=organizational users,%s", userInstance.UserId, instanceProperties.organization));
if(entry not empty) {
    String UserDN = entry.typle.old.user.organization.dn;
    UpdateCase(instanceProperties.rootEntityInstanceId, UserDN);
}

Nice and smart, but can we do better!? Yes, please…Watch this SOAP service:

1
2
3
4
5
6
7
8

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP:Body>
    <GetOrganizationalUsers xmlns="http://schemas.cordys.com/1.1/ldap">
      <dn>o=opa_tips,cn=cordys,cn=defaultInst,o=25.1.com</dn><!--Thats the 'instanceProperties.organization'!!-->
      <filter>*opadev@opa*</filter><!--That's the 'userInstance.UserId'!!-->
    </GetOrganizationalUsers>
  </SOAP:Body>
</SOAP:Envelope>

With a highly fascinating response (cleaned from namespace details):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

<data>
  <GetOrganizationalUsersResponse>
    <tuple>
      <old>
        <entry dn="cn=opadev@opa,cn=organizational users,o=opa_tips,cn=cordys,cn=defaultInst,o=25.1.com">
          <role>
            <string>cn=everyoneInopa_tips,cn=organizational roles,o=opa_tips,cn=cordys,cn=defaultInst,o=25.1.com</string>
            <string>cn=Developer,cn=Cordys@Work,cn=cordys,cn=defaultInst,o=25.1.com</string>
            <string>cn=Entity Runtime User,cn=OpenText Entity Runtime,cn=cordys,cn=defaultInst,o=25.1.com</string>
            <string>cn=Administrator,cn=Cordys@Work,cn=cordys,cn=defaultInst,o=25.1.com</string>
          </role>
          <description>
            <string>OPA Developer</string>
          </description>
          <isserviceaccount>
            <string>false</string>
          </isserviceaccount>
          <cn>
            <string>opadev@opa</string>
          </cn>
          <enable>
            <string>true</string>
          </enable>
          <managedby>
            <string>OTDS</string>
          </managedby>
          <objectclass>
            <string>top</string>
            <string>busorganizationalobject</string>
            <string>busorganizationaluser</string>
          </objectclass>
          <authenticationuser>
            <string>cn=opadev@opa,cn=authenticated users,cn=cordys,cn=defaultInst,o=25.1.com</string>
          </authenticationuser>
        </entry>
      </old>
    </tuple>
  </GetOrganizationalUsersResponse>
</data>

Do you see what I see!? That changes our pseudocode to this solid implementation:

1
2
3
4
5
6
7
8
9

Case caseInstance = ReadCase(instanceProperties.rootEntityInstanceId);
Person personInstance = ReadPerson(caseInstance.toOneMember.ItemId);
User userInstance = ReadUser(personInstance.toOneUser.ItemId);
//Eventually you want a result from this call.
LDAP entry = GetOrganizationalUsers(instanceProperties.organization, String.format("*%s*", userInstance.UserId));
if(entry not empty) {
    String UserDN = typle.old.entry.@dn;
    UpdatCase(instanceProperties.rootEntityInstanceId, UserDN);
}

For our post, the BPM is as simple as this:

The GetOrganizationalUsers call only requires a web service type of runtime reference in your project to use it in your BPM.

This is the consolidated view of the messagemap:

After publication, and selecting a related “Person” entity, our ‘UserDN’ value is nicely filled…

…which makes it an open entry to the lifecycle activity instance setting it to the correct user:

Make the ‘UserDN’ property hidden (or remove it from the forms) as it’s techie-stuff…not for end-users!

A nice and clean “DONE” where we exposed a valuable webservice call. It took a while before it clicked, but eventually these calls will have an impact on receiving a ‘UserDN’ value. “Know your services” is one of the quotes to be ahead of the curve from others…So, hereby another one on the list of valuable calls. Keep it locked here at “Process Automation Tips” for much more unspoken topics that amazes your thinking process for our beloved OPA platform. Ohwww…And have a great weekend as always!

Don’t forget to subscribe to get updates on the activities happening on this site. Have you noticed the quiz where you find out if you are also “The Process Automation guy”?