Hi there AppWorks fans,
Welcome to a new installment of AppWorks tips.
After a week of painful try-out sessions, I finally nailed it and this is my shared update on the OTDS connection to OTCS. I guess it was just my inexperience, but now I really understand how it all works together. Why this painful push through? Well, because (eventually) I want to gain more knowledge about the AppWorks ‘Business Workspaces’ building block on an entity! To be able to work with it, we are…:
- …firstly, required to have a connection with OpenText Content Server (which we created last week)
- …secondly, necessary on building knowledge about the “black box” called xECM
- …thirdly, mandatory to understand the seamless authentication from AppWorks to OTCS (through OTDS!)
- …fourthly enforced to gain knowledge about the popular “Connected Workspaces” (which I have zero experience with)
So, it will be a hard path to follow, but we’ve defined the first steps…
Let get right into it…
Spin up you installed VM from last week, where we’ve installed OTCS next to our AppWorks platform, and the central OTDS instance.
I’ve got these URLs available:
- OTCS classic UI: http://192.168.56.107:8282/livelink/cs?func=llworkspace
- OTCS smart UI: http://192.168.56.107:8282/livelink/cs/app/nodes/2000
- AppWorks: http://192.168.56.107:8080/home/appworks_tips/
- OTDS: http://192.168.56.107:8181/otds-admin/
We already learned about the connection between AppWorks and OTDS, now we’ll have a look at the connection between OTCS and OTDS. Let’s start in the OTCS classic UI where we have the ability to manage users and groups. Why not start from OTDS? Well, because I have a gut feeling OTCS works slightly different with OTDS (compared with AppWorks) from what I’ve seen so far (like the license part!).
So, login with the ‘admin’ account and open the ‘Users & Groups’ section:
Time to create a new user object:
You get a user creation screen where we just fill in the minimal information:
- Log-in name:
When ready…hit ‘Submit’!
There you have it…Our first hurdle to take:
After some short research I found out this action tries to create a user into OTDS under the partition named
Content Server Memberswith the OTDS User ID account represented for the created resource
cs_resource(check the “Users & Groups” section in OTDS on this)! I guess the partition name retrieval can be found behind this OTCS function: http://192.168.56.107:8282/livelink/cs?func=otdsintegration.migrate
Have a look here too!
A strange image when you look back at the same image from last week post! Here I see we’ve already updated the value to our partition name, but it’s updated for some reason? When I update the partition back to my already created partition in OTDS
content_server, we get a new error:
Looks like a valid message as I don’t meet the password policy of the OTDS partition. As we’re in DEV-mode, we just update in the password policy settings in OTDS (with all “zero” values):
Final note: I tried adding the User ID account of the
cs_resourcein OTDS as member to the group
firstname.lastname@example.org. A valid solution as the partition
Content Server Membersis created for me, but in this case I end up with a second partition which I would like to avoid!
After updating the above hurdle, we finally can create a new user object into OTCS which will also be available in OTDS (in the correct partition):
Can we now also login with this account? Let’s log out from our ‘admin’ account and login with ‘awadmin’ (where we are prompt with a password reset):
Do the reset (as this was a request from OTDS…Have a look into the OTDS account!), and now you should be able to login!
Looks like I’m not the only one
Time to turn the tide in the next section…
Synchronize from OTDS to OTCS
From experience, we know the AppWorks users can be pushed from OTDS (through a non-synchronized partition) to Appworks. We’ve created this connection on the OTDS resource corresponding for the intended platform. I have one for AppWorks, and last week we’ve created also one for OTCS named
cs_resource. What I can also remember from last week is the skipped part about the user and group synchronization (because of some missing services…remember?). Well, I found the holy grail, and we can make the synchronization happen, but first…enabling some webservices!
Open a MobaXTerm session to your VM and make sure you have an application server available! Well, by now we have 3 instances up and running:
The services we are looking for are located (as .WAR file) in this location of our OTCS instance:
/opt/opentext/cs/webservices/java/webapps/. We can do a simple copy from this location into the
webapps directory of our OTCS application server instance…Like this:
cp /opt/opentext/cs/webservices/java/webapps/cws.war /opt/tomcat_cs/latest/webapps/
Do we need to configure something for these services? Not from what I’ve experienced! We can just double-check on these URLs as they need to resolve a valid response for our next step:
The last URL will give an error
Authentication Required, but we will not call it like this…It’s fine!
Our next step is to update our OTDS resource
cs_resource with a user and group synchronization!
Go to the ‘Synchronization’ section, enable the synchronization option, and select the correct connector type:
Move to the ‘Connection information’ section and fill in the fields like this (and do a connection test in the end!):
- Member Service WSDL:
- Security Clearance WSDL:
- Authentication Service WSDL:
- REST API URL:
admin(with small letters)
admin(for my account)
- Default group:
DefaultGroup(should be valid OTCS group!)
- External users default group:
ExternalUsers(should be valid OTCS group!)
- Default permission mask:
Why the value
2063on the default permission mask? Well, I had a look in the database to see what’s happing when you update the permissions on a user object in OTCS:
#SELECT NAME, firstname, lastname, userprivileges FROM kuaf WHERE NAME LIKE 'awadmin%';
enabled = `15`
Public Access enabled = `2063` (incl. above)
Can create/modify users = `2095` (incl. above)
Can create/modify groups = `2159` (incl. above)
User administration rights = `2175` (incl. above)
eDiscovery rights = `10367` (incl. above)
System administration rights = `10623` (incl. above)
I wonder…Is this OTDS synchronization sufficient to make our OTCS created
awadmin account able to have a valid login now!? Let’s try out…For me that’s a green flag! 💚 ✅
Time to create a new OTDS user in the
content_server partition…Just a second user with name
awadmin2 to try it out!
Once created, we’ll execute a “consolidate” on the created member (if not yet automatically done after save of the OTDS user).
sudo tail -999f /opt/tomcat/latest/logs/directory-provenance.logon an entry like this:
Directory Server|Success Provenance|5,Object Create|192.168.56.1|""||""|
Push Connector|Success Provenance|15,Account Create In Resource||""||""|
"Created object of type __ACCOUNT__ named 'awadmin2' in resource cs_resource (071cb818-78bc-4e4d-b62c-9b9b2d67b1ab) with UID '4203'"
In OTCS? We see our new created user passing by with exactly our configured properties…NICEEEE!
Do we need any “Impersonation” settings on the resource!? I didn’t do it, but I guess we require to do it on a later time during our xECM exploration…Keep it in mind!
That’s it…Man, did we nail this one? Or what? “DONE”! We learned again a lot from OTDS in combination with OpenText Content Server which will greatly help us in our end-goal to make xECM up and running with the entity “Business Workspace” BB. Have a great week-end, and I CU in the next follow-up post which will be an xECM journey…cheers! 🍺
Another final interesting OpenText documentation resource can be found here
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”?