Hi there “Process Automation” fans,

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

We dive into part 3 of our Node-RED experience! I hope you got as enthusiastic as I am. So far, we can authenticate against OTDS and call the services of our beloved platform (that’s from an external perspective). But can we also call a Node-RED end-point (ReST?), start a flow, pass in the SAMLart ID, and call our services again (without explicit calling OTDS again!)…A great question where we expose the answer in this post! Let’s expand this question to another one; When we make the impossible, possible, is Node-RED a valid engine replacement (in terms of speed) for the internal BPM engine of OPA?…AHA…Now it’s getting interesting! Hold your breath as we’re going under…

Let get right into it…

Start off by booting your VM, incl. Node-RED, and the flow from last time. We learned about hitting the ‘inject’-node to trigger our flow, but what if we add a new type of node called ‘http in’…Like this:

The node settings look like this:

Execute a deployment, and now you guess what you can do now!? Yes, we can trigger an HTTP POST request with a body (in JSON!)…How? Well, watch this CURL command:

1

curl -X POST http://192.168.56.107:1880/api -H "Content-Type: application/json" -d "{\"SAMLartId\":\"...\", \"opaUrl\":\"http://192.168.56.107:8080/home/opa_tips/com.eibus.web.soap.Gateway.wcp\"}"

Be aware of the correctness on those quotes and the escaping of it…That’s Windows CMD stuff!
For CURL, you can use Unix on your VM or use CURL for Windows

You can find your result (and a hanging CURL command) in Node-Red:

The payload is delivered, but the ‘http request’-node fails on a missing URL…Sounds logic to me as the ‘opaUrl’ must be retrieved from the ‘msg.payload’ object and not from the ‘msg.input’ object of the ‘inject’-node!…Here we can two things now; We can update the “Set OPA URL” ‘change’-node grabbing the URL somewhere else OR (the better solution) we can add a ‘change’-node remapping the object, mapping our initial design:

And configure the new ‘change’-node with this:

Deploy, call the CURL command, and check the result:

Nice…that’s working…ALMOST! Do you see it’s an anonymous call and the CURL command is not finishing in the CMD screen!? Well, the first one is logic as we didn’t provide any SAMLart ID in our POST request; It’s now only ... (and requires remapping probably); Keep on reading! The second notice is the hanging CURL command and that’s because we don’t use (and give) an ‘http response’-node back like this. It’s as easy as sending back a 200-code:

Do a deployment and try it out…Trust me it works! Even the payload of the response gets back (in JSON!) to the CURL command for further consumption!

With the ‘change’-node you can even set the response payload to your own needs! OR you can even use the ‘xml’-node to convert JSON back to XML…Just like the OPA platform loves it!

Calling the API from OPA

With this is place it’s time to move into “Process Automation” and call our new API endpoint with a POST request where we require to pass a valid SAMLart ID, so we can skip all the re-authentication flow-parts in Node-RED! 🤗 Was that part all for nothing then? Well, it was not for me as I gained valuable insight, and you can benefit from it on other use-cases.

So, how to continue with the OPA platform!? The quick and easy route is via the HTTP connector. Let me follow my own post with some extra comments below on these quick steps:

1. Section “Create a ReST endpoint that sends back JSON”; That’s what we already have now from Node-RED!
2. Section “Add a run-time reference of type ‘Application Connector’”; Just follow it as explained.
3. Section “Create a new HTTP service connector”
   3a. Groupname: sg_http
   3b. Servicename: sc_http
   3c. Startup automatically
   3d. Assign it to the OS (as recommended by OT these days!)
   3f. Use the path with extra config.xml
4. Section “Create an XML Store with ‘XML Store Definition’”; Just follow as is and use this XML-config part and make sure the XML lands correctly in the ‘XMLStore Explorer’ artifact (as explained in the post)

1
2
3
4
5
6
7

<configurations xmlns="http://httpconnector.opentext.com/1.0/configuration">
 <connections>
  <connection id="NODE_RED">
   <url>http://192.168.56.107:1880</url>
  </connection>
 </connections>
</configurations>

5. Section “Check out the ‘HTTP Connection Manager’ artifact”; Just one to remember!
6. Section “Create a new custom webservice”; Follow as explained with this input:
   1. Source: Custom Web Service
   2. Name ws_node_red
   3. Namespace: node_red
   4. Interface name: wsi_node_red
   5. Class name to select: com.opentext.applicationconnector.httpconnector.HttpConnector
   6. Web service operations to add: api
   7. Use this as implementation part:

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

<implementation 
   xmlns:c="http://schemas.cordys.com/cws/1.0" 
   xmlns="http://httpconnector.opentext.com/1.0/implementation" 
   xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" 
   type="HTTP">
 <connection-id>NODE_RED</connection-id>
 <uri>/api</uri>
 <http-method>POST</http-method>
 <request-handler 
   class="com.opentext.applicationconnector.httpconnector.impl.RestRequestHandler">
  <req-headers>
   <header name="Content-Type">application/json</header>
  </req-headers>
 </request-handler>
 <response-handler 
   class="com.opentext.applicationconnector.httpconnector.impl.RestResponseHandler" />
 <valid-response-code>200</valid-response-code>
 <namespaces />
</implementation>

After these quick steps and a full publication, you can evaluate the new webservice with a request like this (for our first try!):

1
2
3
4
5

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP:Body>
    <api xmlns="node_red">PARAMETER</api>
  </SOAP:Body>
</SOAP:Envelope>

Keep your Node-RED instance open where you will see a result passing by in the debugging screen:

Nice, white smoke on the other side of the line! 💪 Only, with invalid input! That’s something we can change like this:

1
2
3
4
5
6
7

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
   <SOAP:Body>
      <api xmlns="node_red">
         <opaUrl>http://192.168.56.107:8080/home/opa_tips/com.eibus.web.soap.Gateway.wcp</opaUrl>
      </api>
   </SOAP:Body>
</SOAP:Envelope>

Now, we do get a 200-code back! Only with two issues left. That’s an invalid XML response on the OPA side AND the request in Node-RED is “anonymous”!

The first issue is as easy as this:

The second? Well, that’s passing in a valid SAMLart ID via the request. How to get one? Easy, do an HTTP GET request to http://192.168.56.107:8080/home/opa_tips/com.eibus.sso.web.authentication.AuthenticationToken.wcp to get a grip on your current user SAMLart ID!

We move on with eventually a request like this in OPA:

1
2
3
4
5
6
7
8

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
   <SOAP:Body>
      <api xmlns="node_red">
         <opaUrl>http://192.168.56.107:8080/home/opa_tips/com.eibus.web.soap.Gateway.wcp</opaUrl>
         <samlArtId>{your_samlart_id}</samlArtId>
      </api>
   </SOAP:Body>
</SOAP:Envelope>

And a small remap in the ‘change’-node in our Node-RED flow:

Deploy the flow and do another call from the ‘Operation Test Tool’ in OPA…And guess what…

It’s a PARTY! 🥳 🎈 🎉 🎊

Let’s move on to our next level…

The final BPM

Well, that’s a simple two-activity BPM where we first get a grip on the SAMLart ID and next we call our new Node-RED api service operation. You could get the SAMLart ID already via the AuthenticationToken.wcp call, but from a BPM perspective this is not working.

I was first thinking about creating a new custom webservice over the HTTP connector to call the GET AuthenticationToken.wcp-endpoint, but this is not working because we’re already “outside” the platform at that point…Try that GET request on a new incognito tab without any open sessions!? Yes, at that time the “token” is empty!

We need to find something else which is our call from last week! Remember we call a Request method from Node-RED to get a new SAMLart ID with a header passing the OTDS-ticket? Well, from an OPA standpoint the “header” is already there and from the ‘Web Service Interface Explorer’ artifact, you can do an equal request like this:

1
2
3
4
5
6
7
8
9
10
11

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP:Body>
    <Request xmlns="urn:oasis:names:tc:SAML:1.0:protocol" RequestID="" MajorVersion="1" MinorVersion="1" IssueInstant="">
      <AuthenticationQuery AuthenticationMethod="">
        <ns1:Subject xmlns:ns1="urn:oasis:names:tc:SAML:1.0:assertion">
          <ns1:NameIdentifier NameQualifier="" Format=""/>
        </ns1:Subject>
      </AuthenticationQuery>
    </Request>
  </SOAP:Body>
</SOAP:Envelope>

So, create yourself a new BPM with two activities and the explained service operations injected (from the right-click context menu for an activity!):

If you can’t find the Request operation in the BPM, you need to add a runtime reference (in your project!) of type ‘Web Service Interface’ under the category ‘Cordys Single Sign-On’ and select ‘SAMLProtocol’

Finally, we only need to apply some solid mapping like this to make the kite/flyer fly…

Notes:

• The ‘Request’ operation depends on some “empty” attributes in the elements…So, just add them with an empty value.
• In the post-part of the ‘Request’, I map the ‘api’ input elements from a local XML structure which you can create under the process specific messages on the source side of the message map.
  Watch also the correct type of expression usage in the mapping to get a valid XML.

Did my A-Z test work? Well, what do you think! Yes, it did! 🥳

Here is the implementation JSON-file (of this post) for you to download, and to import into your Node-RED instance!

That’s an astonishing “DONE” after three weeks of Node-RED experiences against the OPA platform. It’s even better than expected with a great outcome. I hope you embrace it too with new insights beyond what we’ve covered at this blog-site. Keep it locked, give your comment, or share know ideas, and we see each other next week on a new and fresh tip about “Process Automation”. Have a good weekend!

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”?