Hello everyone. Time to continue the SOAP Series. You can find other entries in the series here:
Configuring SBI as a Web Service Provider and testing an SBI Web Service with external tools, such as soapUI.
Limiting the response to the client through the use of schemas.
Configuring SBI to consume a web service automatically based on a WSDL with Dynamic Services.
Configuring an SBI Web Service client to manually create and post a SOAP Request.
Today we are looking at consuming a Web Service with Sterling B2B Integrator. The procedure which uses Dynamic Services will look pretty much the same whether the Web Service is hosted by SBI or another provider. All you really need to get going is the WSDL which defines the service.
Luckily, we just built a web service in the previous blog posts. I checked that out from Deployment → Web Services → Manager and saved it to my filesystem. As a refresher, let's have a look at some portions of it. I always start reading my WSDLs from the bottom up. So, let's start there:
<wsdl:binding name="GISBinding" type="mesa_xsd:GISPortType">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<soap:operation soapAction="sii:BSWS_NameLookup" style="document"/>
<soap:body parts="parameters" use="literal"/>
<wsdl:port binding="mesa_xsd:GISBinding" name="GISPort">
This snippet shows the endpoint of the service and the operations that it will support. This SBI service has only the one operation available, sii:BSWS_NameLookup. You can then work your way upwards in the WSDL. Each identifier should be declared higher up in the WSDL. For example, the <wsdl:binding> tag is of type “mesa_xsd:GISPortType” which is declared as:
Each of those message attributes have their own declarations higher up and so on and so on. As you follow the path up through the WSDL, you should work through all of the elements and the defined schemas for the web service.
So, let's check this WSDL in, and see what we get. Go to Deployment → Web Services → WSDL Check In. Enter a name for the WSDL (I used BSWS_GetName). Select HTTP for the transport, since we are going to a regular http endpoint without any SSL/TLS. Finally, select your file. Checking it in yields the following screen:
This shows that a dynamic service called DS_BSWS_GETNAME_PORT1_OPE1_Instance will be created to handle consuming the web service defined by this WSDL. Click Finish. Our dynamic service to consume is now ready to be added to a BP.
The BP itself is pretty straightforward. Here's what it looks like:
<assign to="." from="DOMToDoc(tmp, 'BSWS_NameLookup')"></assign>
<assign to="." from="*"></assign>
<assign to="." from="*"></assign>
A couple of things to note in this BP. The first assign creates the document structure that we want in ProcessData under a temporary node, tmp. This requires that the targetNamespace that the WSDL is looking for is defined in namespaces.properties or customer_overrides. Now my customer_overrides.properties contains BOTH the input and output namespaces:
The next assign takes the nodes under /ProcessData/tmp and moves them into a document named with the same name of the Operation you are invoking. In this case, BSWS_NameLookup. Also note that will be the name of the root node in the input document as well.
Finally, we invoke the dynamic service. This finds the document with the Operation name (BSWS_NameLookup), creates an enveloped SOAP Request out of it with appropriate headers, automatically posts it to the endpoint, and collects the response from the Web Service. If you are building your BP in the modeler, the dynamic services have their own stencil grouping that you can bring up from View → Stencil → Dynamic Services.
After getting all the resources in place and executing the BSWS_ConsumeWebService business process, we can look at the Documents screen at the Dynamic Service to see all of the documents that were involved. There are four total.
1. The original document we created from ProcessData, BSWS_NameLookup.
2. The generated Soap Request. It has been SOAP enveloped and appropriate HTTP Headers were added, including SOAPAction.
3. The raw response from the server. The first line should be the HTTP Status code. If it's successful, you will see a SOAP enveloped response below the headers containing the data you want. If the HTTP Status code is a failure (4xx or 5xx status code) you will most likely see a SOAP-FAULT document with some details about the failure.
4. PrimaryDocument. This will contain the unenveloped data from the SOAP Response.
So, those are the basics of using Dynamic Services without SSL/TLS. If you wanted to add that layer of encryption, you would need to be connecting to an HTTPS endpoint that would be defined in the WSDL. When you check in a WSDL with an HTTPS endpoint, you have to select HTTPS/Other Transport for the Transport setting. This introduces a big change in behavior for the Dynamic Service. When you have selected HTTPS/Other Transport, the Dynamic Service will generate the SOAP Request, and that's it. It's done. It won't do anything else for you.
The responsibility is on you to set up the HTTPS Transport when using SSL/TLS. So, you'd need to build out the BP, adding HTTP Client Adapter services to post the file to the endpoint. This is necessary so that you can configure the appropriate credentials or certificates in the BP so the post to the endpoint will be successful.
That's about it for today. Next time I'll be taking a look at crafting a SOAP Request from scratch. We'll also look at exactly what all those SOAP services available in the application are for.