/ Management  

Connect OpenText Content Server with OTDS

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:

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:

otcs_otds_001

Time to create a new user object:

otcs_otds_002

You get a user creation screen where we just fill in the minimal information:

  • Log-in name: awadmin
  • Department: DefaultGroup
  • Password: admin

When ready…hit ‘Submit’!

There you have it…Our first hurdle to take:

otcs_otds_003

After some short research I found out this action tries to create a user into OTDS under the partition named Content Server Members with 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!

otcs_otds_004

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:

otcs_otds_005

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):

otcs_otds_006

Final note: I tried adding the User ID account of the cs_resource in OTDS as member to the group otdsadmins@otds.admin. A valid solution as the partition Content Server Members is 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):

otcs_otds_007

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):

otcs_otds_008

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!

Hmmmmm…NOT!

otcs_otds_009

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:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
{
    "appservers":[
        {   "name":"AppWorks",
            "type":"TomEE",
            "post":8080,
            "path":"/opt/tomee"
        },
        {   "name":"OTDS",
            "type":"Tomcat",
            "post":8181,
            "path":"/opt/tomcat"
        },
        {   "name":"OTCS",
            "type":"Tomcat",
            "post":8282,
            "path":"/opt/tomcat_cs"
        }
    ]
}

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:

1
2
cp /opt/opentext/cs/webservices/java/webapps/cws.war /opt/tomcat_cs/latest/webapps/
cp /opt/opentext/cs/webservices/java/webapps/cs-services-rmsecmanagement.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:

  • http://192.168.56.107:8282/cws/services/MemberService?wsdl
  • http://192.168.56.107:8282/cws/services/Authentication?wsdl
  • http://192.168.56.107:8282/cs-services-rmsecmanagement/services/RMSecManagement?wsdl
  • http://192.168.56.107:8282/livelink/cs/api?resource=test

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!

otcs_otds_010

Go to the ‘Synchronization’ section, enable the synchronization option, and select the correct connector type:

otcs_otds_011

Move to the ‘Connection information’ section and fill in the fields like this (and do a connection test in the end!):

  • Member Service WSDL: http://192.168.56.107:8282/cws/services/MemberService?wsdl
  • Security Clearance WSDL: http://192.168.56.107:8282/cs-services-rmsecmanagement/services/RMSecManagement?wsdl
  • Authentication Service WSDL: http://192.168.56.107:8282/cws/services/Authentication?wsdl
  • REST API URL: http://192.168.56.107:8282/livelink/cs/api
  • Username: admin (with small letters)
  • Password: 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: 2063
  • Department: DefaultGroup

otcs_otds_012

Why the value 2063 on 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:

1
2
3
4
5
6
7
8
#SELECT NAME, firstname, lastname, userprivileges FROM kuaf WHERE NAME LIKE 'awadmin%';
Log-in 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).

otcs_otds_013

Monitor sudo tail -999f /opt/tomcat/latest/logs/directory-provenance.log on an entry like this:

1
2
3
4
Directory Server|Success Provenance|5,Object Create|192.168.56.1|""||""|
"entryDN=cn=awadmin2,ou=Root,ou=content_server,ou=IdentityProviders,dc=identity,dc=opentext,dc=net; objectClass=oTPerson"
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”?