Striving towards reuse

The hard part is getting a service ready for reuse. So far, my test drive of Grand Central's Business Services Network has served only to demonstrate the hardship required to create a service. But in an ideal world, people like me wouldn't have to go that deep; programmers — who actually enjoy writing raw software code — would create the business-level services for the rest of us, and we'd just assemble them into composite processes without having to worry about arcane stuff like typing, the correct construction of 'for...while' statements and how to evaluate variables.

Last week I described the creation of a process that calls a URI and returns the response as a SOAP attachment. Today, I'm going to finish that off by adding the ability to specify the URI in the SOAP message that triggers the process. That turns my demonstration service into a much more useful function that might actually deliver some practical business benefits to somebody. And that's the beauty of reuse; once a meaningful service has been created, it's then possible to redeploy it in lots of different contexts, with the minimum of effort.

So I'm going to go back to Grand Central's process designer and open up the process I created last week, save it under a new name, and add the WSDL information that allows it to accept a URI as input data. Here's my step-by-step account.

Having saved the process under a new name, I double-click on the 'start' button in the Process Designer schematic of my process flow. This opens up what I like to think of as "the scary bit" (yes, another one), and which Process Designer calls the "WSDL Schema Editor".

Once the schema editor opens up, I select the 'Schema Builder' tab. Initially, I just want the schema to contain one input element, which is going to be the URL that I'm going to call, and one output element, which can be the status report from the service that I'll use to call it. Using the graphical Schema Builder, I need to drag-and-drop the 'ComplexType' icon across into the workspace for each element in turn, and fill it with the relevant definitions. So I drag in the first one, name it 'targetUrl' and click the arrowhead to open up another line. Then I drop in a 'String', which I'll call 'URL'. Repeat the process to create an element called 'status', containing a string called statusMessage.

Now I can select the 'Message Properties' tab and create the input and output parts of the WSDL definition. If I press the 'Add' button for the Input parts, it brings up a box labelled 'Untitled' next to a pull-down list of the elements I've just created. The targetUrl variable is going to be one of the inputs, so in the Input Parts section I type the name get_URL in the box and leave 'targetUrl' showing in the pull-down menu. Then I move down to the next section, click Add, then type get_status in the 'Untitled' box and select 'status' alongside it. That's completed my WSDL (phew! the scary bit is done) so I can now click on 'OK' and return to the main Process Designer screen.

Now I need to connect the input and output parts that I've just defined in my WSDL to the elements in my process. If I go to Data View and then double-click on the HTTP Get Service, the red line shows me that it's currently linking to the predefined variable URL that I set up before. Now I can also see another URL variable in the Process Input element, underneath get_URL. So I highlight this and drag it across onto the corresponding URL in the HTTP Get Service request tree. This replaces the old link with a new one. (Of course, I could construct an if statement to check that a valid URL has been provided and use the predefined URL if not, but I think I'll pass on that for now).

Then, moving on to the Reply element, I can link the Status variable from the HTTP Get Service response to the statusMessage variable in my process output.

The only other thing I have to do is adjust the second evaluate statement in my process. This is something Mangesh from Grand Central's product team advised me to do and, quite frankly, I have no idea why it's necessary, but he usually has good reasons for suggesting these things. Still in the Data View, I double-click on the second 'Evaluate' element to bring up the Expression Editor. I highlight the second 'response' in my addVariableAttachment function, highlight 'Variable Expressions' in the function category pane below, and then select getVariableAttachmentTypeById in the right-hand pane. This has two terms. I highlight the first, 'from_VariableName', then click on the '+' sign next to 'HTTP Get Service' in the left-hand pane, and right-click on 'response' so that I can select 'VariableName from the dropdown list. Next, I highlight 'attachmentID' and type in 'response' in single inverted commas. Then click OK.

Now I save and compile, and in theory it should all work as before, but this time with the ability to provide any URL in my originating message.

To achieve that, all I need to do is to compose a suitable SOAP message — easier said than done, although I'm told there are tools that help with this, even though they're not made available within the Grand Central portal.

So you'll just have to take my word for it that my XML below is correct. Go to messaging, select 'Create a new message', browse the directory to find the service just created and insert it in the 'To:' field, and then go down to the SOAP body textarea box and insert the following:

<m:getresponse xmlns:m="[the target namespace defined in your WSDL Schema]">
    <get_urlList>
        <m:URL>[put your desired URL here]</m:URL>
    </get_urlList>
</m:getresponse>

Then send the message. All being well, when you look at the response, you'll get a status message saying 'true' (which means it worked OK) and an attachment containing the output from your chosen URL, which can be either XML or HTML.

Having created this, it seemed to me that it would be useful to get a reminder of the URL in the return message as well, so (all confident now) I went back to the process designer, opened the schema editor, and added a second string called 'URL' to the 'status' element. Then I went into the Data View, double-clicked on the Reply element and connected the 'URL' from the get_URL element in the Process Input to the URL variable I'd just created in the get_status output element. After another save-and-compile, I now get a message returned that shows the URL that was called as well as the status message and the attachment.

I now feel that this exercise is getting closer to producing some really useful services. My next step will be having a go at publishing this service so that others can use it. I'll move ahead with that next week.

posted by Phil Wainewright 11:42 PM (GMT) | comments | link