Hi there AppWorks fans,

Welcome to a new installment of AppWorks tips.

This week a look in the documentstore connector specifically for OpenText Content Server. We already did a ‘docstore’ connection with the Documentum CMS platform, so we have some experience upfront this time. From this experience we also know we need a seamless authentication mechanism from AppWorks to OTCS…One of the hurdles to take for this post. When this is in place, we should be able to rather easy create a new documentstore connection and save content (uploaded from a ‘Content’ BB in AppWorks) into OpenText Content server. This is also an important step in my xECM end-goal as the configured connector contains some extended ECM (xECM) related settings…We’ll see…How hard can it be?…

Let get right into it…

We’ll divide the post into 2 sections. First we’ll craft the seamless authentication! We need one single user to login into AppWorks, but is also a valid account in OTCS. This way our seamless user is also able to upload content into OTCS later on. From last post we made the awadmin account available, so let’s see if we can make this account also available on the AppWorks side. When the authentication part is ready, we should be able to build ourselves a new documentstore connection and play around with it…Keep on reading…You’ll see for yourself! 😉

Updates for correct authentication

From previous post we were able to login with the account awadmin onto our OTCS URL: http://192.168.56.107:8282/livelink/cs. Now let’s switch (with the same browser tab) to our AppWorks URL: http://192.168.56.107:8080/home/appworks_tips/

This is a pure OTDS message! The account is not even (yet!) available in AppWorks…Let’s fix this!

So, our account tries to access a resource ID? What resource will this be? Off-course our appworks_resource:

With this information in mind, we’ll jump to the ‘Access Roles’ section to get a grip on the ‘Access Role details’. Here we make sure to add our content_server partition as part of the ‘User Partitions’:

Don’t forget to hit that ‘Save’…It’s a common mistake to do!

When you monitor your logging: sudo tail -999f /opt/tomcat/latest/logs/directory-provenance.log, you should see the account passing by for the correct resource ID:

1
2
3
4

Push Connector|Success Provenance|15,Account Create In Resource||""||""|
"Created object of type __ACCOUNT__ named 'awadmin@content_server' in resource 
appworks_resource (bfc384c0-be69-44d9-9bfd-f42a869ee19d) with 
UID 'USER~39fd6672-06fd-103c-94f7-8f2d24cfc279'"

Well, where are we waiting for?…Have a login into AppWorks via awadmin:

With the other awdev account we can assign the ‘Developer’ role the this user to play around further…A task to do on your own. 🤗

We are now at a point where we have a seamless connection between OTCS and AppWorks, have a switch between the URLs…You should be fine…correct?

Creating a documentstore in AppWorks

Now the fun part of the post where we will create a documentstore connector on the AppWorks side to be able to store content into OpenText Content Server. Before we will create this we need to make sure 2 settings are in place:

1. An “Other” resource in AppWorks which points to the cs_resource
2. A “content” folder location in OTCS to point to from the connector

The “Other” resource

Open AppWorks (with an administrator account like awdev in my case) from your own organization and open the ‘Security Administration’ artifact. Go to the ‘OTDS Resources’ tab where you probably see the already configured ‘Platform’ OTDS configuration:

This one is already in place, but our documentstore connector requires an ‘Other’ resource too…The one from “Content Server”. This is what the “Administration” documentation is telling me:

So, just add a new one like this:

The resource ID can be found in OTDS like you saw some screenshots back!

That’s in place…next…

The “Content” folder

Time to enter OTCS with the available admin account on URL: http://192.168.56.107:8282/livelink/cs?func=llworkspace. We directly land in the ‘Enterprise’ workspace and are able to create a new folder:

Give it a nice name like AppWorksContent, leave the rest as is and hit the ‘Add’ button…easy? right? 😁

Now open the so-called ‘Functions’ menu of the folder (Yes, I learned something here!) and open the ‘Permissions’:

You now see the access roles who have permission to this folder. To make it simple for now, we just make sure ‘Public Access’ has ‘Full’ permission on this folder…Like this:

Is it smart? Probably not, but does it work? Hell YEAH…YOLO!!! 🤗…Uhh, and don’t forget to hit the ‘Update’ button!

Off-course it’s better to use a dedicated group to gain access to this folder, but that’s not the scope for the post.

Next step…It’s finally time to create the documentstore connector in our AppWorks platform. So, return to it and open the ‘System Resource Manager’ artifact (I execute this in my own organization). Here we can start the ‘New Service Group’ wizard:

In step 1, we select the ‘Document Store’ connector:

Hit ‘Next >’

Give it a name like docstore_service_group, select all the interfaces, and click ‘Next >’

Give the service a name like docstore_service_container, let it start-up automagically, assign it to the OS Process (as recommended by OT), and hit ‘Next >’

I know!…It’s an image with small letters, but I wanted to show you as much as possible to clear it all out! Windows has some magnifier setting you can use too! 🔍

Fill in the form like this, and hit ‘Next >’ in the end:

• Store name: xECM (this can be anything!)
• Store type: OpenText Content Server
• Authentication type: OTDS resource (where you can select the one we’ve defined in the ‘Other’ resource!)
• Content Server details:
  • End point URL: http://192.168.56.107:8282/cws/services/DocumentManagement (We made this service end-point come alive in the post from last week)
  • Repository root: AppWorksContent (Is the folder in OTCS we’ve just created!)
  • Content Server URL: http://192.168.56.107:8282/livelink/cs (duh??)

We can leave the rest as is…

• No “Viewer” settings (Brava! / Intelligent Viewing) are required
• No ‘Template init details’ are required…Whatever that might be!? (leave a comment)
• No further ‘xECM’ config required (yet!)…That’s our next post, for next week! 😇

Finally, you can finish the wizard, and you have yourself a nice documentstore connector available! Let’s hit the gas and upload content I would say? Sure, but for this we need an entity with a “Content” panel in the layout…right? Sure!…Why don’t you create it my friend? Ohw…You require some well-defined steps? Here you go (or have a look at this post again, where we do the same for the ‘Documentum’ ECM connector).

1. Open your workspace and corresponding project (or create one if you don’t have it yet)
2. Create an ‘entities’ folder’
3. Create a new ‘Entity’ type of document in this new folder (just with one property, and generate all the rest)
4. Update the layout of the entity with a ‘Content panel’
5. Add the ‘Content’ BB to it
6. Publish it all, and have a first test

Ohw yeah…Don’t forget to test with the seamless created account awadmin!!! (I was so stupid to test with the awdev account)

A glimpse of my entity:

Where I have the ability to upload a new file:

Let’s give it first try…With…As always! our hurdle to take:

Time for a logging view on our TomEE server (as that’s where it’s eventually being executed): sudo tail -999f /opt/tomee/latest/logs/catalina.out

There you have it (our root-cause of the problem!):

1
2

Caused by: com.opentext.otds.OtdsException: Error Code=1012 
message=Impersonation not enabled on resource bfc384c0-be69-44d9-9bfd-f42a869ee19d

This is a simple one to solve in OTDS!

Have a second re-test in the AppWorks runtime where we have ourselves a green flag:

Post checks

Let’s see what we can find after this green flagged content upload. It’s always interesting to have a closer look on the back-end side of things! 🤠

What happens in OTCS, stays in OTCS

An image can tell a thousand words:

We can clearly see the creation of a path where we find our document.

Later on (after playing a bit around), I also saw 2 other folders passing by with their own “Category” applied to it (continue reading…)

What’s happening in the database

Let’s have a look with HeidiSQL with an interesting query like this (we’ve learned this trick here):

SELECT id, id1, s_content_type, s_filename, s_filesize, s_storage, s_lastmodified, s_title FROM o2appworks_tipsgenericcontents;

You will retrieve this kind of information:

1
2
3
4
5
6
7

{
   "documentURL":"AppWorksContent/appworks_tips/appworks_tipsgeneric/test/1/Contents/Default/contract.txt",
   "documentName":"contract.txt",
   "documentId":"4406",
   "linked":false,
   "businessWorkspaceId":null
}

When we have a look at the properties of the document from within OTCS, we can clearly see a match with the ‘documentId’:

Don’t ask me what ‘Nickname’ has to do with it, but ‘smells’ to me like a unique ID for the document…Maybe a legacy property? Comment me!

Get the properties of our just uploaded document in AppWorks runtime

Well, this failed (the first time) with a TomEE “catalina.out” error:

1
2
3
4
5
6
7

faultstring: 
Error while processing soap request. Insufficient permission to add node to container..
faultactor: http://schemas.cordys.com/documentstore/default/1.0
resourceID: Cordys.DocumentStore.Messages.commonError
...
at com.cordys.documentstore.client.otcs.CreateAndAssignCategories.createCategoriesFolder(CreateAndAssignCategories.java:204)
at com.cordys.documentstore.client.otcs.CreateAndAssignCategories.execute(CreateAndAssignCategories.java:180)

It looks like the first time we try to retrieve properties the connector needs to update some category settings in our AppWorksContent folder. After I’ve updated my awadmin account settings in OTCS with more privileges…

…it was all working fine, and I see indeed some “Category” updates in the AppWorksContent folder:

After this, I restored those privileges again, and it kept on working…All the other actions were also possible (like check-out / check-in). This is the properties view from within AppWorks runtime on the uploaded content:

Have yourself a look in the /app/admin layer of AppWorks

I was hoping to find something here (like we also saw with the Documentum docstore connector), but it’s rather empty!

Maybe this is (for now) empty because we didn’t apply any xECM configuration yet on the connector…Let’s double-check this in the next post (as I’m sure it should show something from what I understand).

That’s it…I think a well-earned “DONE”, where we made the next step available on the end-goal. Which is the final destination to make xECM working for our AppWorks platform. We’re getting there…for sure, but it’s a lot to configure and also a lot to figure out! Off-course I had some help from OpenText professional services to make this all happen…thank you for that! I’m glad it all works out as planned as I’m sure a lot of people will struggle on these kinds of service binding activities. Now you know it too…Make use of it and share your own thoughts about it. Have a great week-end…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”?