Hi there AppWorks fans,

Welcome to a new installment of AppWorks tips.

This time a great insiders tip (and a struggle I had during my daily job) on making roles (created in AppWorks) available as ‘roles’ for the Identity package. Why?…Well, we want to use these roles to assign tasks to, but we see that roles created in AppWorks are not ‘visible’ in runtime! Let’s find out and…

Let get right into it…

Spin up your VM and make sure you have also OTDS connected to your AppWorks platform.

I start (in my case) with a clean image without any solution, but with OTDS connected to my organization. How?…Well that can be found here

So, I log in with a ‘Developer’ account ‘awdev@dev’ through a URL that looks like this: http://192.168.56.107:8080/home/appworks_tips/?authID=OTDS

With that account we can also go into runtime (http://192.168.56.104:8080/home/appworks_tips/app/start/web/?authID=OTDS) where we see our ‘Identity package’ node without any roles:

Now, how to add roles to this node? The last time I tried this, it was done through OTDS…a recap!

…

In OTDS we go to our ‘Partition’ (in my case the ‘dev’)

Go to ‘Actions’ and view those members. (You can already see I have just 1 ‘User’ available for this partition). Last time, when I tried out this feature, I had some problems with groups/roles that where not visible in the ‘Identity package’, so let’s do that again to make sure that it’s not working as expected (after this we jump into a solution!)

So, from that ‘View members’ action add a new ‘Group’ with the simple name ‘all_users’ and also a new ‘Role’ with the nice same of ‘manager’. Leave all the other fields empty, so you end up with this:

Our user was already synched…Now let’s consolidate those just created groups/roles.

Ohw yeah…Make sure you ‘Include groups’ on the ‘Access Roles’ for our created resource:

Go to the ‘Resources’ for that ‘Consolidate’ action on the ‘AppWorks’ resource:

When done we go back to the runtime of AppWorks where we see exactly what we saw before…No role in the ‘All roles’ section of the ‘Identity package’, but we do see the ‘manager’ role back in the ‘All groups’ section!?

In design-time?

Well, we see indeed those 2 items again, but this time as ‘Role’!? Do you understand it?

We can also see that the entry is saved in CARS as ‘organizational role’…I’m getting more and more curious!!

So far for the recap…Now for that solution that makes it possible to add a ‘role’ to the ‘All roles’ section in the ‘Identity package’

OTDS Push Roles

For this to happen we’ll dive back into design-time where we create a small project with a ‘roles’ folder to play around with. Something like this:

Right-click that ‘roles’ folder and create a new document of type ‘Role’

You get a new panel where we just create a new ‘Functional’ role with the name ‘reviewer’…

Save it and publish it.

Back in user management we see the new role passing by:

In runtime?…Believe me…It’s not there in the ‘All roles’ section of the identity package!

How do we get this role in there?

OK…Let’s open the ‘Security Administration’ artifact and go to the ‘OTDS Push Roles’ tab for the ‘OTDS Resources’:

What value will this feature bring to us?

Well, it will push the current roles (our ‘reviewer’) to a OTDS partition through the same ReST connector that makes the synchronization happen between OTDS and AppWorks (that we already configured in the mentioned post!).

So, let us fill-in our partition name that we created in OTDS (in my case ‘dev’), save it, and hit that ‘Push roles’ button.

Hit the ‘refresh’ button and see some output like this:

What did it do?

Well, let’s find out in OTDS!

Hmmm…what’s behind that magic #6?

View the members of our partition and check out those groups (Indeed…Not ‘Roles’!)!

OK…There we have our 5 roles that were mentioned in the status field of that ‘push’ action…including our ‘reviewer’ role!

Nice, but still nothing in runtime (yet!)…

And that’s correct because we need to consolidate these groups back to AppWorks!!

In that consolidate panel mark the resource…

…and hit that ‘Consolidate’ button.

Back in AppWorks runtime?

Ohwww Yeah! 👊

Now the great question…What is the difference in data in CARS (as that’s the place where it is eventually being saved) for ‘reviewer’, ‘manager’ and ‘all_users’!? Especially ‘all_users’ as they fall into the same ‘Group’ list in OTDS! For that we have the CMC tool!

Let’s grab some screenshots…

So, these conclusions can be made:

• The OTDS role ‘manager’ became an ‘All groups’ entry in the identity package and is an ‘organizational role’ for CARS
• The OTDS group ‘all_users’ became an ‘All groups’ entry in the identity package and is an ‘organizational role’ for CARS
• The AppWorks role ‘reviewer’ became an ‘All roles’ entry in the identity package (after an OTDS push) and is a ‘packaged role’ for CARS

For you guys and gals, I also created that functional ‘tester’ role in AppWorks to see the difference (this role was not yet pushed anywhere!):

…both are exactly the same in CARS!?

So, it must be something in the database that makes the difference between those 2 (from an identity perspective)!

To help you find it (I did a first try) you can enable the ‘all’ logging in the database configuration

1 2	sudo vi /var/lib/pgsql/11/data/postgresql.conf log_statement = 'all'

After this, do a tail on the logging tail -f /var/lib/pgsql/11/data/log/postgresql-Wed.log

This shows you the SQL statements triggered on the database side!

Now restart PostgreSQL systemctl restart postgresql-11.service

When you have that logging enabled and click in the ‘All roles’ in runtime you should see statements that look like this:

1
2
3
4
5
6
7

2021-01-06 14:20:12.311 CET [3534] LOG:  execute S_205: BEGIN
2021-01-06 14:20:12.311 CET [3534] LOG:  execute <unnamed>: select 1
2021-01-06 14:20:12.311 CET [3534] LOG:  execute S_1: COMMIT
2021-01-06 14:20:12.311 CET [3534] LOG:  execute S_205: BEGIN
2021-01-06 14:20:12.312 CET [3534] LOG:  execute S_206: SELECT O2OpenTextEntityIdentityComponentsIdentity.Id AS COL1, O2OpenTextEntityIdentityComponentsIdentity.S_DISCRIMINATORID AS COL2, O2OpenTextEntityIdentityComponentsIdentity.IdentityDisplayName AS COL3, O2OpenTextEntityIdentityComponentsIdentity.Package_Name AS COL4, O2OpenTextEntityIdentityComponentsIdentity.S_ITEM_STATUS AS COL5, O2OpenTextEntityIdentityComponentsIdentity.S_IS_TEMPORARY_COPY AS COL6, O2OpenTextEntityIdentityComponentsIdentity.Name AS COL7 FROM O2OpenTextEntityIdentityComponentsIdentity WHERE O2OpenTextEntityIdentityComponentsIdentity.S_DISCRIMINATORID IN ($1) AND (O2OpenTextEntityIdentityComponentsIdentity.S_ITEM_STATUS = $2 OR O2OpenTextEntityIdentityComponentsIdentity.S_ITEM_STATUS IS NULL) AND (O2OpenTextEntityIdentityComponentsIdentity.S_IS_TEMPORARY_COPY = $3 OR O2OpenTextEntityIdentityComponentsIdentity.S_IS_TEMPORARY_COPY IS NULL) ORDER BY O2OpenTextEntityIdentityComponentsIdentity.Id LIMIT $4 OFFSET $5
2021-01-06 14:20:12.312 CET [3534] DETAIL:  parameters: $1 = 'F8B156E1037111E6E9C6F07F4B63FBBF', $2 = '1', $3 = 'f', $4 = '200', $5 = '0'
2021-01-06 14:20:12.324 CET [3534] LOG:  execute S_1: COMMIT

Interesting, but more interesting when you make it readable like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

SELECT 
	O2OpenTextEntityIdentityComponentsIdentity.Id, 
	O2OpenTextEntityIdentityComponentsIdentity.S_DISCRIMINATORID, 
	O2OpenTextEntityIdentityComponentsIdentity.IdentityDisplayName, 
	O2OpenTextEntityIdentityComponentsIdentity.Package_Name, 
	O2OpenTextEntityIdentityComponentsIdentity.S_ITEM_STATUS, 
	O2OpenTextEntityIdentityComponentsIdentity.S_IS_TEMPORARY_COPY, 
	O2OpenTextEntityIdentityComponentsIdentity.Name 
FROM 
	O2OpenTextEntityIdentityComponentsIdentity 
WHERE 
	O2OpenTextEntityIdentityComponentsIdentity.S_DISCRIMINATORID IN ('F8B156E1037111E6E9C6F07F4B63FBBF') 
	AND (O2OpenTextEntityIdentityComponentsIdentity.S_ITEM_STATUS = '1' OR O2OpenTextEntityIdentityComponentsIdentity.S_ITEM_STATUS IS NULL) 
	AND (O2OpenTextEntityIdentityComponentsIdentity.S_IS_TEMPORARY_COPY = 'f' OR O2OpenTextEntityIdentityComponentsIdentity.S_IS_TEMPORARY_COPY IS NULL) 
ORDER BY 
	O2OpenTextEntityIdentityComponentsIdentity.Id LIMIT '200' OFFSET '0'

Put it into HeidiSQL for a result to play around with!

Let’s remove the DiscriminatorID from the where-clause and see something nice happening…

Ohw yeah…There are my ‘All groups’ entries!…They just fall under another ID…But ‘tester’ is not in the list? Correct as we didn’t push it up to OTDS and consolidate it back to AppWorks (which makes it part of the identity package!)

Let’s see when I re-push…A few moments later

With the interesting insert statement in the database logging:

1
2

insert into O2OpenTextEntityIdentityComponentsIdentity (Id, Name, Description, IdentityDisplayName, UniqueQualifier, S_ITEM_STATUS, S_IS_TEMPORARY_COPY, S_TEMPORARY_COPY_DATA, S_DISCRIMINATORID, Package_Name, memberid) 
values('655361', 'tester', 'tester', 'tester', 'F8B156E1037111E6E9C6F07F4B63FBBFtesterAppWorksTips proj_gen', '1', NULL, NULL, 'F8B156E1037111E6E9C6F07F4B63FBBF', 'AppWorksTips proj_gen', '60e20891-4e0a-331f-a8eb-491b3a5d855d')

Well, we nailed that one for sure …”DONE”. What a ticket to ride, but we learned a lot again from the platform, and its back-end. We now all know how to make it possible to add new ‘roles’ into the identity package for us consume from. The keyword here is “OTDS Push Roles”…Never to forget! These roles can now be used in runtime to send out tasks from a BPM or select them as part of a dropdown list. You can make it all happen after this post. Have a great week-end and I CU in the next one.

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 AppWorks guy”?