This Document is intended to guide the user through the practical steps necessary to build Web Services with TIBCO BusinessWorks 5.X. This document contains sample code and an example project, and is not intended for production use.
Web Services – TIBCO BusinessWorks™ 5.X Example Tutorial
Building a Document/Literal Web Service with TIBCO BusinessWorks 5.X
Overview of the Tutorial ............................................... 3
Web Services Methodology with BusinessWorks 5.X 4 Schemas for the SOAP Server ................................................. 4 Using the Schema in the WSDL Editor .................................... 6 Process Definition for the SOAP Server ................................. 8 SOAP Event Source .................................................................. 8 Java Code Activity as the Engine of the Service ................... 9 SOAP Send Reply .................................................................... 11 SOAP Client .............................................................................. 12 Retrieve Resources – Optional .............................................. 13 Building a SOAP Client ........................................................... 15 Multiple Operation PortType .................................................. 17 BusinessWorks 5.1.2 Project Example ................................. 18
The diagram above is the schematic for this example. There are two BusinessWorks Process Engines, one that exposes an HTTP Receiver and performs a SOAP Request/Reply to the second engine, which is the SOAP Server that encapsulates the actual service. This second engine is comprised of a SOAPEventSource, a Java Code Task, and a SOAPSendReply. The HTML Client POSTs three elements – the principle, the interest rate, and the number of months for the loan. The WebService does the calculation and returns the monthly loan payment. To simplify matters, I will omit the HTML and Browser aspects of the example.
Web Services Methodology with BusinessWorks 5.X There are two ways to approach building this “project” – you can pseudo-code the process, or ‘wing it’! If you chose the pseudo-code route, you will notice that you have: two processes, a complex schema that outlines the inputs and outputs (or two schemas – one for input and one for output), two WSDL files, two HTTP Connections, and two Process Definitions – one for the SOAP Client and one for the SOAP Server. If you know what you need, it is simpler if you have the objects “at hand”, so you can create them now! If you wished, you might want to “drag & drop” these elements into the project, otherwise, just follow along….
Schemas for the SOAP Server As the Service Description for the Service (concrete) depends on the SOAP Server (abstract), it makes sense to start this project with this process engine (Server Process Definition). We know that we need three inputs and a single output, so we create an XSD to represent our schema. Note that you must include a targetNamespace for use in WSDL. In TIBCO’s Turbo XML, this is available under File->Schema Properties.
Create appropriately names folders for your project. I have folders named:
Communications
WebServicesProcessDefs
WSDLs
Start by opening up the WSDLs Folder, and accessing the XML Tools Palette. Drag & Drop a Schema Object into the folder. As shown below, I have named this schema loanpayWS.
In BusinessWorks 5.X, targetNamespace is entered under the Configuration Tab as shown below:
Double-click on the Schema Icon, and you will see a ‘spreadsheet-like’ interface with which to build your XSD. Note that the Input Element has as its contents the other elements used in the SOAP client.
Using the Schema in the WSDL Editor Open up the WSDL Palette and Drag & Drop a WSDL object into your WSDLs Folder. You can “Copy from URL”, “Browse UDDI”, or you can double click to make your own WSDL – next, we will double-click and use the XSD we created in the last section. As this will be the Service WSDL, name it AbstractDocLiteral, and then Drag & Drop two Message Objects and a PortType and name the messages appropriately. Take the first message, and associate the input aspect of the Schema in five easy steps:
1. Click the “Plus” sign to add a Part to the Part Table
2. Name the Part “inputString”
3. Choose Element
4. Pick the Binoculars to browse the resources and pick the schema in Part Details
5. Navigate to the XSD, and highlight the element “input”, click O.K. then Apply.
For the Output message, perform the same process, but in the XSD, choose the element “answertext”.
Next, double-click on the PortType, and Drag & Drop an Operation – I’ve called this one OperationOne. In a similar fashion to assignment of the messages, you will use the process to add an input type, an output type, and an optional fault type to the Message Table, and then associate each kind with the specific type of message you just built earlier.
Here you see that I’ve created an input type for the Message Table that is associated with the inputMessage that we created for this WSDL. Repeat for the output type.
Now we are done with our Abstract WSDL creation! We will use this WSDL to create the Service, and with the addition of some communication specifics, we can derive the Concrete WSDL for our Client. Here is the WSDL Source:
Open the WebServiceProcessDefs Folder (or whatever you called it), and Drag & Drop a Process Definition Object into the folder, and name it WebSvcDocLitLoanPay. Next, Drag & Drop a SOAP Event Source, Java Code Activity, and SOAP SendReply Activities, and connect them as shown. Label them appropriately. We will need to go back to the project view and create a single HTTP Connection in the Communications Folder you created earlier – this configuration is as simple as picking a Port number that is not in use, I used Port 88.
Configure the SOAPEventSource by using the two binoculars on the Configuration Tab, and choosing the namespace and Port Type of the Abstract WSDL we just created, and check that it has both an Input and an Output. The second binocular will let you browse the Transport, and you will pick the HTTP Connection you just configured.
SOAP Event Source
Configure the SOAP SendReply by simply taking the default, which is to [Reply To: SOAPEventSource].
Java Code Activity as the Engine of the Service Configure the Java Code Activity by creating inputs and outputs that will map to the equivalent message parts of the WSDLs.
Open the Code Tab, and you will see two radio buttons – Invoke Method Body and Full Class. Using the Invoke Method Body format, cut and paste the following java code below the comment lines:
float PRIN = Float.parseFloat(prin); float INTEREST = Float.parseFloat(interest); int MONTHS = Integer.parseInt(months); double FIRST = Math.pow((1+INTEREST/1200),(-MONTHS)); float PART = (float)FIRST; float PAYMENT = PRIN/((1-PART)/(INTEREST/1200)); /* answertext is the answer */ answertext = (String.valueOf(PAYMENT));
With your code successfully compiled, you need to do some very simple mapping to associate the SOAP Event Source with the Java Code Activity. Move to the Input Tab, and expand both sides to expose the elements, and drag & drop as shown below:
SOAP Send Reply Next, move to the SOAPSendReply activity; in the Configuration Tab, you will associate this with the SOAPEventSource of this process. Open the Input Tab and configure the SOAP message to contain the output of the Java Code Activity. This map is a single line!
And…we are finished with the Web Service! Now, on to the Client…
SOAP Client By taking the schema and building an Abstract WSDL, we set the foundation for a Web Service by the addition of adding a Transport for Binding to the PortType. The result is a service with a port, and then you have a Concrete WSDL. By opening the WSDL Source Tab, you expose the Concrete WSDL. Highlight the Text and cut/paste into your favorite text editor and save. Next, go to “Project• Import Resources from File, Folder, URL…” Import the WSDL you just saved into the WSDLs Folder. I’ve called it DocLitConc. Alternately, you can drag & drop a new WSDL object, click the source button in the tool bar and then paste/apply/save.
Retrieve Resources – Optional Another way of retrieving the Concrete WSDL is to build a “Retrieve Resources” process in the Web Service Business Process. You will call this from an HTTP URL.
The configuration is straightforward, with explicit values for:
Building a SOAP Client In another project, or in the same project, create a WSDL Object and associate it with the Concrete WSDL we just described. You can do this by importing, cut/paste, or via the Retrieve Resource URL.
Next, create a Process Definition that includes a SOAPRequestReply. Optionally, you can include some HTTP activities if you want to interact from a form in a Web Browser, but the simplest is to build a process like this one:
The configuration steps are simple – you follow the same steps as you did when configuring the SOAPEventSource, but this time, you pick the Concrete WSDL rather than the Abstract one! The screen shot should look like this:
If you aren’t using a Browser, I find it useful to create input via the Output Editor in the Start Activity, and then mapping it appropriately to the inputs of the SOAPRequestReply.
Multiple Operation PortType Simply build out your WSDL with additional “related” Messages and then associate them in Operations within a PortType. You can optionally group Operations under multiple PortTypes. In the screenshot below, I’ve created a WSDL with four Operations under a single PortType, called FinancialServices, with operations of DoLoanPay, DoAccruedSavings, DoCompoundInterest, and DoLoanInterest (I imported the related XSDs – not shown):
