Hi there “Process Automation” fans,

Welcome to a new installment of “Process Automation” tips.

We run this platform now for over 5 years with weekly posts and interesting topics. I did a recap on my backlog quickly and one topic seems underrated on this blog site…What is it? Tell me, tell me? Well, it’s the “Gateway” of the platform! Your first entry-point to make all the fancy stuff we’re building possible to call! O-boy…Is it that important? It is from an administration point of view, but for us low-code developers it’s also interesting to understand how this stuff works. So, I dedicate this post to the “Gateway” of our beloved platform.

Don’t mix this post with the “ReST Gateway Connector” or the “Gateway server”; Both are two different components which we leave out of scope for this post.

Let get right into it…

The first question is: Where can we find this “Gateway”? Great question and for this we start in runtime (where your knowledge workers start each day!). Starting with a platform login screen (not OTDS), you can see this within the developer console <F12> of the browser:

Make sure you use the platform login screen; Not the OTDS login screen…You can bypass this via http://192.168.56.101:8080/home/opa_tips/app/start?authID=X where X is just a non-existing thing. Your administrator probably did a configuration to forward you “by default” to the OTDS login screen.

So, there you have it…Our entrance to the platform! DONE! 😁

…

Nice, but how can we see when and what message blocks/passes the entry of the gateway? Interesting question! For this, I did some quick R&D (with some quick remote debug session) and bumped to the file ./components/webgateway/webgateway.jar…How obvious! It also moved me to this class com.eibus.web.soap.Gateway with methods getRequestXML(...) and setResponseXML(...). These methods expose to log the request on Info-level. Soooooo…Time for some file hacking on Unix. sudo vi /opt/opentext/ProcessAutomationCE/defaultInst/config/Log4j2Configuration.xml

Add the section in the “Gateway request/response” comment below:

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

<Loggers>
  <Logger name="com.cordys.cap.applicationconnector.CAPMethod$CapLogger" level="info" additivity="false">
   <AppenderRef ref="ApplicationNameBasedAppender"/>
  </Logger>
  <Logger name="com.eibus.management.AlertSystem" level="info">
   <!--AppenderRef ref="OSBasedEventAppender"/-->
  </Logger>
  <Logger name="com.eibus.management.ManagedComponent" level="info"/>
  <!--START Gateway request/response-->
  <Logger name="com.eibus.web.soap.Gateway" level="info"/>
  <!--END Gateway request/response-->
  <Root level="error">
   <AppenderRef ref="file"/>
   <AppenderRef ref="CordysZeroConfJDBCAppender"/>
  </Root>
 </Loggers>

Later, I also conclude it’s documented in “Enabling logging for gateway” of the admin-guide…But what fun is that!? 😂

There is no need to restart anything; Just monitor the correct file to see all the requests/responses passing by: sudo tail -999f /opt/opentext/ProcessAutomationCE/defaultInst/Logs/Application_Server.xml

Great Scott!

ATTENTION, ATTENTION: Never forget to undo this setting when you’re done researching!

So, what else? Well, how does the Gateway “know” which service container to call after the request is valid? Let’s start with this first request coming in the logfile directly after login:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
 <SOAP:Header>
  <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
   <wsse:UsernameToken xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
    <wsse:Username>sysadmin</wsse:Username>
    <wsse:Password>admin</wsse:Password>
   </wsse:UsernameToken>
  </wsse:Security>
  <i18n:international xmlns:i18n="http://www.w3.org/2005/09/ws-i18n">
   <i18n:locale>en-US</i18n:locale>
  </i18n:international>
 </SOAP:Header>
 <SOAP:Body>
  <samlp:Request xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" MajorVersion="1" MinorVersion="1" IssueInstant="2024-11-15T21:20:39Z" RequestID="addfae5c8-378d-4b3b-89d6-8d346439d26b">
   <samlp:AuthenticationQuery>
    <saml:Subject xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
     <saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">sysadmin</saml:NameIdentifier>
    </saml:Subject>
   </samlp:AuthenticationQuery>
  </samlp:Request>
 </SOAP:Body>
</SOAP:Envelope>

I wasn’t aware of this, but do you see the security breach in the above request (copied from the logfile)? Yes, it exposes credentials! #RED_ALERT and a reason to use OTDS as identity provider (IdP)!

Request is the name of the operation found in the namespace urn:oasis:names:tc:SAML:1.0:protocol; We can search this operation via the ‘Web Service Interface Explorer’ artifact; And guess what:

And when we open this service group from the ‘/system’ space, we’ll find the responsible service container (and the matching ‘Web Service Interface’!):

Getting the properties of the service container, lets you change the more specific service settings (not for now).

So, that’s a close loop…Are you still with me? For the full clarification, when you call any other Soap service (via the ‘Web Service Interface Explorer’) like GetUserDetails with an empty <dn/> it works the same, but this time via the LDAP service group.

External calls (from outside the platform)

The above is all quick talk on internal service calls, but what about an external service call? From SoapUI? Yes, please! For this we first grep a WSDL of a service operation:

Now have a look at the bottom for a URL like this (you can decode it here):

1

http://192.168.56.107:8080/cordys/WSDLGateway.wcp?service=http://schemas.cordys.com/1.0/ldap/GetUserDetails&organization=o=system,cn=cordys,cn=defaultInst,o=mydomain.com&version=isv

No way!!!! Yes, my friend…Copy this URL in SoapUI for a new Soap project and do your magic!

Or include the credential header for even more fancy stuff:

These are now platform accounts but have a read here for the same tricks over OTDS and SAML-stuff (also, not for now)!

We’re getting off-track…What about a wrong request that does not match a service group (by changing the namespace to ldap2!)

AHA!! So, based on the namespace it finds the corresponding service group that has a web service interface applied which implements the requested operation! Lessons learned here on the fly! 💪

Two interesting, related artifacts

Now that we understand the principles of the gateway, we’ll do a quick dive onto two artifacts within the platform. It’s the ‘Web Gateway Monitor’ and the ‘Test Web Gateway’. If you never hear of it, open the ‘/system’ space (via the sysadmin account) and check these:

First the monitor; Open the artifact and have a look:

Interesting to view the platform with some numbers; Make a screenshot, reset the numbers, and double check on a later period with a comparison.

Have also a look at this direct (HTTP GET) URL: http://192.168.56.107:8080/cordys/com.eibus.web.application.GatewayMonitor.wcp

The second artifact is the ‘Test Web Gateway’. This artifact lets you fire requests against the gateway with multiple connections and parallel actions. A great tool to put the system under a stress test (outside office hours!). Unmark the “Asynchronous Calls” option for direct feedback; if you can’t wait for the report, you can follow the trail live via the option ‘Report during processing’.

Read here about a great speed test example using this artifact.

…

Finally, you can find more about this “gateway” in the documentation in sections: “OpenText Process Automation Web gateway” and “Managing Web gateway”.

And yes, “OpenText Process Automation” as the new name for “AppWorks”!

A great gateway “DONE” where we exposed the insights of the platform gateway. It’s not that hard to understand once you know where to look; It all sounds overly complicated, but it’s basic stuff you need to understand as a low-code developer and an administrator. Make sure the gateway performs at its best and make sure to arrange your services groups and corresponding service containers as efficient as possible. Have a great weekend and CU next week. Cheerz!

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 Process Automation guy”?