You know how to WSDL?

It's a measure of how unfamiliar this whole territory is to me that it's been three weeks since I last posted about my test drive of Grand Central's Business Services Network.

I had a long call the following week with Mangesh Bhandarkar from Grand Central's product management team, who very patiently talked me through some of the steps required to complete the process I'd been trying to build. Mangesh assures me that the Process Designer tool is easy enough to pick up for someone who's already had some experience of working with web services using a visual programming tool, but if like me you're a complete newcomer to the field it's frankly impossible without a bit of handholding.

Over the past week I've had another go at building the process, and I've jotted down a description of all the steps involved, as I encountered them. Sometimes I think it serves a useful purpose to write an account like this, because it highlights how longwinded a process can be for someone who hasn't been through the same learning experiences as other users. We all tend to forget how much know-how we take for granted in the things we do every day. For those to whom this is familiar ground, I hope it gives you either some insight into how Grand Central's tools work, or if not at least a sense of satisfaction at your superior skills. For those who, like me, are novices at this kind of thing, I hope it might provide enough information to allow you to replicate the service should you wish to.

In my earlier attempt, I had got stuck after dropping a blank service icon into my process flow. So I'm going to continue from there, and readers who want to create their own version of this service should refer to my previous posting to follow the steps up to this point.

It turns out that I only needed to double-click on the blank service and that brings up a dialog box where I can browse the complete directory of services. Or I could have gone to the directory pane in the bottom left corner, found the service I wanted, and dragged it directly into the designer workspace. So if I browse by category, expand the Grand Central Services folder and then the HTTP folder within it, I'll see the service I'm looking for. In fact, rather than the HTTP Gateway I had thought of, I now see that there's also a much simpler HTTP Get Service, so that's the one I'll pick. Having selected it, it pops open a service description, where I just click OK and it's there in my process.

Later on, I'll want to pass variables into the HTTP Gateway service as inputs from my incoming SOAP message, but for now I'll just set up some fixed variables to use while I create the basic process. I can either click process > variables in the menu bar or click on 'vars' in the toolbar. Variables in the Grand Central system are strongly typed, so when I go to add a variable named 'URL', I select 'xsd:string' from the list of available types. I also add a default value: this is the actual URL I'll be calling with the HTTP Get Service. Next, I add another variable called 'response', selecting type 'xsd:base64Binary'. This catch-all variable type will safely contain the response generated by calling the URL on my server.

Now I need to link the URL variable into the HTTP Get Service, so I click on the 'Data View' tab and then click on the icon that represents the HTTP Get Service. This fills the two panes at the bottom of the screen with trees showing the input and output elements. My URL variable is shown at the top of the left-hand pane, and I want to link it to the URL variable contained in the HTTP Get Service request part, which I'll see if I scroll down to the bottom of the right-hand pane. All I have to do is grab my URL variable in the left-hand pane and drag-and-drop it onto the request URL variable in the right-hand pane. A thick red line shows that the two are linked to each other.

That's easy enough, but I also need to add some steps to the process that will handle the response generated by the HTTP Get service. This is where Mangesh's advice proved especially invaluable, because I would never have thought of doing this without his prompting (and goodness knows how long it would have taken me to work out the rest of it, but this bit for certain I would never have grokked unaided).

To collect the response from the service I need to add not just one but two 'evaluate' steps to the process. These can be found in the 'other' section of the tasks list, and so I drag-and-drop them across into the process flow. That's the easy bit. Bear with me for the next few steps, as they're tricky to follow.

I now have to go into the Data View and double-click on the first 'evaluate' icon to open up the Expression Editor, where I'm going to link my 'response' variable to the response fetched by the HTTP Get Service. In the Output pane on the left-hand side, there's a list of various process components, starting with 'User Variables'. I click on the plus sign next to this and a list drops down of the variables I just defined. Then I right-click on the 'response' element, which opens up a list of available functions and actions. Dear reader, would you have thought of right-clicking at that moment? I thought not. But now that you have, select 'setVariableData()'. Go on, trust me on this.

You'll see an expression appear in the main workspace pane. One of the terms is ARG. This is in black letters, which tells you that you need to substitute something more meaningful. Click on it to highlight it, and then click on 'Variable Expressions' in the Function Category list below. In the right-hand pane, click on 'getVariableAttachmentByID'. There, doesn't that make it more meaningful? No? OK, let's pause for a second to work out what's going on here.

What we're doing in the expression editor is assembling some program code that tells the process where to get the data to populate the 'response' variable we set up. The HTTP Get Service brings back the data as an attachment, so we set the variable data (using the setVariableData function) to pick up the variable contents of the attachment, identified by its ID (using the getVariableAttachmentByID function). Goodness knows how I would have worked out which functions to use if Mangesh hadn't told me, but that's another story I guess. OK, end of pause, let's continue.

That second function has two terms. Highlight the first, 'from_VariableName' and then look in the Output pane. Click on the '+' sign next to HTTP Get Service, and you'll see the 'response' variable drop down. Right-click on this and select 'Variable Name', which inserts '_HTTP Get Service_output' as the first term. Then click on the second term, 'AttachmentID', to highlight it, and type in 'response', which if you'd had time to read up about the HTTP Get Service, you would know happens to be the variable name that it gives to the attachment. Now you're done. Click OK.

The second 'evaluate' step simply picks up the attachment collected by the previous step and passes it to process output. Still in Data View, I double-click on the second 'evaluate' icon to open up the Expression Editor again. In the Function Category pane I highlight 'Variable Expressions' to bring up a list of Function Names in the right-hand pane . It's the first one of these that I want — addVariableAttachment — so I click on it (don't double-click, by the way, as there doesn't seem to be an 'undo' command, so you either have to manually edit out the extra code, or cancel out and start again, which is a pain).

Now there's a function expression in the workspace pane with three terms to be defined. The first, 'to_VariableName', has to be connected to the process output, so highlight it and then go to the Output pane and click on the '+' sign next to 'Process Output'. Fortunately, we're now wise to the right-click routine that was so much of a puzzle before, so right-click on 'Body' and select 'Variable Name'. The next of the three terms, 'variableToAdd' is the name of the variable we're picking up from the previous step, so just highlight it and type in 'response' between single quote marks. The contents of that variable will be passed to the third term, 'newAttachmentId', so we may as well give it the same name by typing in 'response' again. Now click OK.

Now that all that's in place, the final step to complete this simple process is to add a 'Reply' step. To do this, go back to process view, and in the Tasks pane on the far left click the arrowhead next to 'Flow Control'. Grab the 'Reply' icon and drop it into the process flow as the last step before the 'Finish'.

That's completed the process, so now click on the 'Save and compile' icon in the top menu bar (or on the 'File' menu). If all is well, you'll see 'Result: success' in the 'Compile Results' pane bottom left.

Now the moment of truth. This is a bit artificial at this stage — it's not a useful process yet, I'm just testing that it works, before I go on to add some more productive capabilities. But if it does work, I should be able to send a message from my Grand Central account that calls a URL on my web server, and which fetches the response as an attachment. Assuming it does work, then I can schedule Grand Central to send that same message at regular intervals, and that's when it starts to become interesting, because I can use this process to fetch regular reports, or to trigger scheduled events on my server (or both, of course).

Minimizing the Process Designer, I click the 'Messaging' tab in my Grand Central account area, and then select 'New Message'. In the 'Compose Message' window, I just need to give the message a name and a 'To:' address, which I select by pressing the 'Browse Directory' button alongside. In theory, I could email any service in the directory, but on this occasion, I select the 'My Directory' tab to pull up the list of my own private services, and select the one I've just finished building. I don't need to add a SOAP header or body to call this very simple process, because the variables are fixed. I just go to the bottom of the screen, save the message, and then press the 'send' button. When the 'Message Sent' screen comes up, I can click on the 'Poll for response message' option to see if it's been successful — and it has! Scrolling down to the Attachments section, I click on 'response' and it shows me the page generated by the target URL on my web server. At last, I have reached the first stage in my journey and created a working web service.

PS: I got an email today informing me that Grand Central has extended the closing date for its Golden Spike developers contest until January 31st. Just as well if people like me are going to have a chance of finishing any half-decent services. Even better news for developers who fancy showing off their superior skills at service assembly using Grand Central's browser-based process designer.

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