Assertion based mechanism for SAP to OpenText xECM Connectivity?

Nitesh harjai · 2025-04-08T08:45:47+00:00

There was an error rendering this rich post.

Dear Developers,

I need your assistance in understanding the assertion-based mechanism for securely connecting SAP to OpenText xECM using the SAP client ID.

For the assertion-based mechanism, the login/create_sso2_ticket parameter needs to be set to 3. This can be configured via transaction /RZ10 in SAP.

I have two SAP systems, X100 and Y100, that need to be integrated with OpenText xECM. However, I only have one cloud environment, which includes a single OTDS, OTCS, and WSDL.

My primary concern is how to bifurcate the requests coming from both SAP systems to the OTDS?
Based on my understanding, this can be managed using different SAPSSOEXT authentication handlers in OTDS, each configured with distinct PSEs from the respective SAP systems.

Another challenge comes from the OpenText guide, which mentions that for the assertion-based mechanism to work, the web services pack must be deployed in the Tomcat > otsapxecm directory, as referenced in the article KB0779691.

If I deploy the web services in the Tomcat directory, the issue arises of how both SAP systems (X100 and Y100) will recognize which WSDL should handle the requests within the same OpenText system. The WSDL currently references SAP client="001" and SID="OTX" refer the image below, meaning I would need to either hardcode the values for one system or use these default values for only one of the SAP systems (either X100 or Y100).

Do you have any suggestions on how to use the same WSDL for both SAP environments while ensuring proper integration with a single OpenText system?

Thanks,
Nitesh

Find more posts tagged with

Note:

If there are Accepted Answers, those will be shown by default. You can switch to 'All Replies' by selecting the tab below.

Accepted answers

All comments

appuq

Why can't you instantiate another WSDL(proxy) in Tomcat? Oh, I know the TC server is maintained by OT cloud, and they won't be receptive to changes. Othwerwise you could write your own restapi implementation

Nitesh harjai

As the servers are on cloud I cant deploy the custom WSDL and changes to servers.

Is their any other way which will help out here ?

Or do I need to implement my first SAP machine x100 and once done I need to switch off and remove connection of x100 from everywhere and then I need to start with y100 sap machine implementation.

loss will be i cant connect both systems in one go.

appuq

This may work for you, but it is untested.

In your cloud OTCS server, you have to first create two external connections one to X100 and one to Y100 server

You then do the whole 9 yards of XECM thing in OTCloud

Using the OTCS GUI and not SAP, create one item each in that external system, think of this as a consultant doing a test run of the configuration,n so ideally you have one item from X100 and one item from Y100

In your XECM for SAP configuration in SAP, do what you need to do, stressing to put the external system correctly, so when X100 is doing the create, it uses the correct external system

My gut feel is SAP will construct a message like this(it is not my gut feel, I know that is the message :))

The properties name/value pair is optional only the ObjectID, ObjectType & externalSystemId

Are the mandatories here.If this works a year long supply of beer is appreciated:)

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:api.ecm.opentext.com" xmlns:urn1="urn:ECMLink.service.livelink.opentext.com">

   <soapenv:Header>

      <urn:OTAuthentication>

         <!--Optional:-->

         <urn:AuthenticationToken>1bDj3z2MXbtZRK9KjtMtsY</urn:AuthenticationToken>

      </urn:OTAuthentication>

   </soapenv:Header>

   <soapenv:Body>

      <urn1:createOrUpdateWorkspaces>

         <urn1:externalSystemId>X100</urn1:externalSystemId>

<urn1:boInfos>

<urn1:ObjectId>BEDFORD:13150</urn1:ObjectId>

<urn1:ObjectType>Asset</urn1:ObjectType>

<urn1:Properties><urn1:Name>assetnum</urn1:Name><urn1:Values>13150</urn1:Values></urn1:Properties>

<urn1:Properties><urn1:Name>location</urn1:Name><urn1:Values>BPM3100</urn1:Values></urn1:Properties>

<urn1:Properties> <urn1:Name>description</urn1:Name><urn1:Values>Top Breaker System test(Exit51)</urn1:Values>

</urn1:Properties><urn1:Properties><urn1:Name>siteid</urn1:Name><urn1:Values>BEDFORD</urn1:Values></urn1:Properties>

</urn1:boInfos>


      </urn1:createOrUpdateWorkspaces>

   </soapenv:Body>

</soapenv:Envelope>

Nitesh harjai

Thanks @appuq i will test this and post the result here if that works or not.

I will try to deploy the WSDL to OT or will ask OT support to start the process.

appuq

Not sure I understand the last part . IF OT is on cloud as in a K8S deployment, they have the WSDL already deployed, and the OTCS application is running on TC. I access our cluster for certification, and I shell onto the pods, and I can see tomcat and OTCS and all that jazz. The important thing to understand is the flow. I know there are some very old cloud customers who just run virtual machines as well.

XECM Clients(SAP, Success Factors, Sales Force, Maximo, Microsoft Dynamics, Service Now and and …..)

→Either WSDL based or REST based(SAP,Maximo and a lot of old apps are SOAP WSDL based)

→XECM Frame Work in Oscript( what I refer to as the 9 yards,Classification,Category,Workspace,Connection,BO Type,Templates)

Connection+BO Type uniquely defines the XECM client….

Nitesh harjai

Hi @appuq,

As per my understanding, my system is deployed on Kubernetes (K8) and hosted on OpenText Cloud, while the SAP system is hosted on a private cloud managed by the customer.

Regarding the connection from SAP to OpenText, I have been following the guidelines provided in the OpenText documentation to ensure smooth connectivity. According to the guide, when the login/create_sso2_ticket parameter is set to 2, no changes are required to the WSDL files. However, in my case, the customer's SAP system has the login/create_sso2_ticket parameter set to 3, which, as explained in the guide, activates the assertion-based mechanism.

This setup requires the deployment of the relevant WSDL files, as detailed in the provided KB article, in order to establish proper connectivity.

"https://support.opentext.com/csm?id=kb_article_view&sysparm_article=KB0779691"

If this file is present in Tomcat directory then I am good to go.

Thanks,
Nitesh

appuq

Hmm, the K8 changes are difficult from a cloud perspective because, by design pods are ephemeral. So for you to understand, here's the thing. If the pod is deployed and we see OTCS, we can go and install a module just like we do in regular things, but when the pod is destroyed or recreated,it won't remember anything. So as an OT partner, if we have to persist a module or patch, we use a technology called "init_containers" which is a process by which our module and any number of other partner modules get added to the base image. Perhaps they can do this for the tomcat as well.I have no clue. If all fails all they have to do is to put it in another tomcat outside the cluster and accessible and you will be fine.

Nitesh harjai

@appuq

Let me reach out to OpenText Support for assistance in deploying the necessary changes for the assertion-based mechanism, as outlined in the guidelines. I will keep you updated after the test results.

To clarify, if we deploy the WSDLs mentioned above, the ExternalSystemID will be set to a single SAP client (e.g., X100). However, we are dealing with two SAP clients—X100 and Y100—connecting to the same OpenText system.

As you mentioned, the combination of connection and BO type defines the xECM client. In my case, the BO type is the same for both X100 and Y100, but the connections are different. My confusion lies in the fact that when calling the WSDL, only one ExternalSystemID can be set i.e either x100 or y100, not both.

<soapenv:Body>      <urn1:createOrUpdateWorkspaces>

         <urn1:externalSystemId>X100</urn1:externalSystemId>

<urn1:boInfos>

Thanks
Nitesh

appuq

Your use case is no different from two XECM clients placing their content and using proper configuration in the same OTCS system.

Don't let my SOAP message confuse you :) I thought you would like to learn that is why I was verbose.

What happens is ABAP will read the config in your first SAP system and construct that message in which case it will get X100

Your second system will read its configuration, in which case it will get Y100. This is why I said you should not rely on SAP as the first configuration test, you should use the OTCS GUI and point to X100 and create an item, and then to Y100 and create an item. If that is working, then your idea will work.

PS: If you are an advanced ABAP professional, you can get the message as I pasted above

The SAME SAP system may be difficult to send two different message sets so long as there are two SAP systems, you are fine.

The WSDL controls which OTCS server the message is landing on

Note:I don't want to confuse you, but XECM also has concepts like cross-application and composite, which are slicing and dicing different systems

Nitesh harjai

Thanks clear with the answer now.

We will do the test and see how it will work,

As soon as ABAP will construct the message the client id of sap will be contsructed in my case x100 from x100 sap system and y100 from y100 sap system and based on that it will bifurcate the request.

Thanks,

Nitesh