Hi there “Process Automation” fans,

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

Greatness passed my path of knowledge that opens doors I was not aware could open! It’s all about testing external services. Not the services itself, but mocking them, so we control the outcome ourselves from an OpenText “Process Automation” point of view. Never depend on an external service you don’t have under control, but make sure to understand the principles and the outcomes, so you can mock it for your own testing; That includes the worst-case scenarios! Long time ago (in 2022) I did a similar post on mocking a ReST endpoint with WireMock consuming JSON; This time we do about the same, but now by mocking a SOAP endpoint consuming XML…How? Well, using a tool we probably all know, but I was not aware this tool could do what I wanted it to do!?

Let get right into it…

This first question that we answer is: What is the tool? It’s SoapUI and you’ll find it here. You can do the installation for yourself; it’s just hitting next until you can’t go any further.

Once ready, start up the tool and leave it in peace for now…In the meantime also boot up your “Process Automation” platform VM which we’ll use later to connect both.

But first…We need a Web Services Description Language (WSDL) which describes the functionality (and its operations) of a webservice. It’s a “contract-first” approach where we first design of what we can do and build the implementation (on what will happen) later. “Smells” like interfacing from a Java programmers’ perspective.

You can use online WSDL files (see table below), but you can also generate something interesting online here, save it, and expose it via a web library definition in “Process Automation” over a URL looking like this: http://192.168.56.107:8080/home/opa_tips/wsdl/your_file.wsdl…comment me if you don’t have a clue!?

This is a list of public Soap APIs which you can use for testing and playing:

For fast progression, I use the public API CountryInfoService for now. For this post we only need the WSDL link as our target is to mock it which mimics an implementation! AHA! 🤩

So, it’s now time to open SoapUI again. Here you can create a new SOAP project where you can paste in the URL of the WSDL:

You get two “Bindings”; we only need one. I go for CountryInfoServiceSoapBinding

You can now right-click the binding and generate a mock service (which is a powerful and underrated feature…keep reading!)

We go “all in” by checkmark everything:

Watch the port 8088 which must be available on your machine…In case you run any other “secret” services!

Hit OK and watch the magic going on:

Once it’s running fine, you can access “the mock” via your browser at http://localhost:8088/mockCountryInfoServiceSoapBinding?WSDL

Back to your ‘Mockservice’ in SoapUI where you can edit the mock operation CapitalCity (for now!) and open the request:

You can now fire the request and watch the response:

Watch also the URL where you send it to!

Great, but our nl-NL request show a ? as response!? And we don’t have any implementation, so #WTF!? Yes, my friend! That’s the power of mocking! You create a kind of man in the middle where you are in control of the response! 💪

Now for the greatest trick of all…Go back to the response and edit it! Update it with Netherlands and give it a second shot on the request:

Haha!! It’s magic!…But now watch this (for a worst-case scenario!):

You can read more about the faultcode here

Now hit the request again and see what will happen:

Ohw that’s nice!! Why? Well, we can now continue to our next step on consuming this from a “Process Automation” perspective…Via the UDDI connector!

These are the quick steps:

1. Create a new service container from the ‘System Resource Manager’ artifact
   1a. Connector type: UDDI Service
   1b. Group name: sg_uddi
   1c. Select service interface: Method Set UDDI
   1d. Service name: sc_uddi
   1e. Startup automatically
   1f. Assign to the OS Process
2. Create a new ‘Web Service’ type of document (like you also create a new entity)
   2a. Source is Import WSDL
   2b. Name: ws_country_info
   2c. URL (accessible from your local laptop!): http://192.168.56.1:8088/mockCountryInfoServiceSoapBinding?WSDL
   2d. Show the services and select them all.
3. In the properties of CountryInfoServiceSoapBinding you need to connect it to the UDDI service container!
4. Publish the project, and you can now do the test call in operation CapitalCity…Or any other.
5. In case of &^%#&^%@ look in the artifact ‘External Services Configuration’ where you can update the service settings. On change, restart the UDDI container!

Following that post and eventually calling the worst-case scenario MockService gives me a proper “worst-case” error (as expected!):

Be aware you need to make sure the MockService is accessible from the “Process Automation” VM; In my case via http://192.168.56.1:8088/mockCountryInfoServiceSoapBinding which required me to also open a firewall entry within Windows (locally).

…

Other interesting insights during my explorations:

• What WSDL is for webservices and its functionality, is Xml Schema Definition (XSD) for XML and its data!
• “Contract-based” OR “Design-by-contract” OR “Contract-first”…It’s all the same thing!
• Also interesting is a search on Google (or use ChatGPT) on this query: Which is better JSON or XML?
• You also need to send a Fault-response WITHOUT comments (like <!--Optional:-->)!…Otherwise, you get this error:

So, this is totally valid for a Fault-response:

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

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
 <soapenv:Body>
  <soapenv:Fault>
   <faultcode>SOAP-ENV:Server</faultcode>
   <faultstring xml:lang="en">Unknown ISO code!</faultstring>
   <faultactor>system</faultactor>
   <detail>
    <custom>
     <message>You're doing it wrong!</message>
    </custom>
   </detail>
  </soapenv:Fault>
 </soapenv:Body>
</soapenv:Envelope>

That a splendid “DONE” with a powerful feature within SoapUI I was not aware of. Mocking is a useful tool and gives you control on the outcome where you normally don’t have any control about. Teach yourself this stuff; Talking to others and looking how others do their tricks can be extremely helpful. Keep it focused, and we see each other next week on another episode of “Process Automation Tips”.

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