I said in my last post that the benefit of using Whitehorse has been marginal so far. To my surprise, I never got a single email refuting this. I still stand by that comment, although I am being a little hard on Whitehorse.

At this stage in the design process, I've painted a picture of my application design, and a picture of my logical datacenter design. I use the word picture explicitly, because that is what it is. It is a visual representation, without any additional information (metadata) attached. Kind of a flat representation of a 3D world. Today, I'm going to describe how I started to add that additional information, initially to the application design.

If you refer back to the application design in my previous post, you'll see I started by selecting one area of functionality we would be delivering (point-of-sale customer and sales order), and then built up an application design. To the basic POS system, I added some additional features to support further development, like an event publisher to allow new systems to be attached to the application, and a library of common services (InfrastructureLibrary). Remember also that my application utilises published SAP Web Services, which in my initial design I emulates using an ASP.NET Web Service (SAPWS).

The first thing I did today was to try to access the real SAP Web Services. I consulted the SAP API documentation and found the address of the WSDL files that described the Web Services I planned to utilise. Then, within the Application Diagram, I deleted the dummy ASP.NET Web Service (SAPWS), and added an External Web Service instead. When I did this, I got a dialog, which allowed me to specify the path to the WSDL file for the SAP API I wanted to use. I entered the URL, and this created an external Web Service in the Application Designer.

At this point I bumped into a couple of issues. Firstly, SAP exposes each API call as a separate web service, instead of a single web service with multiple web methods. This meant that I had to create a total of 8 separate external web services in the application designer, one for each SAP API I planned to call. This could make for a pretty cluttered Application Design if you planned to access a large number of SAP APIs.

The second issue came up when I looked at the signature of the SAP web services. These were RPC/encoded web services, rather than document/literal. I wanted to stick to document/literal web services, following the guidelines of the WS-I Basic Profile. I believe that later versions of SAP provide better web service interfaces. However, it became apparent that putting a web service façade across the front of the provided SAP web services was going to be a good idea.

 

 

You can see my Application Design above. Note that I cropped it a bit, to focus on the area of interest. At this stage, I had linked to each of the SAP web services, and I had defined the web services (and web methods) for my SAPFacade (a less granular set of business web services,  implemented in terms of native SAP web services). I still need to define the rest of my applications, but at this point I thought I'd have a little fun….

 

I checked everything into Visual Sourcesafe (I'm working stand-alone off my laptop, so no Team Server L), labelled the version, and then checked it all out again. Then I right-clicked on SAPFacade, and selected "Implement Application". VSTS created the ASP.NET Web Service project (in C#), automatically added web references to all of the SAP web services I had linked to in my Application Design, and created stubs for the methods of the two web services I had defined. Selecting one of the web methods, I was then immediately able to write the following code, with completion etc.

 

 

At this point, I really began to see some benefits from Whitehorse. Usually when I'm working with corporate customers, I don't get the luxury of completely "green fields" development. What I mean by that is that I invariably have to link my applications to existing applications/systems, and that I need to deploy those applications onto existing (sometimes shared) infrastructure (more about that next week). With a "static" design tool like Visio I typically can't pull in definitions from existing systems, and integrate them with my evolving design (although to be fair, I can pull in web services definitions in some other design tools). My Application Design was now starting to capture significant meta-data behind the visual elements, and more importantly, this meta-data is automatically transferred to the application developer (in the form of class definitions etc). I was beginning to get hooked!

One last really COOL feature! I talked above about the fact that I wasn't that happy with the exposed SAP web services, and I implemented a façade to those services which provided a web service interface that better suited me. Now of course as I continue to develop this application, I will build up a pretty comprehensive SAPFacade (a number of web services, grouped around specific business entities, such as SalesOrders, and Customers). Of course within my customer, other designers will be working on related applications, and these designers will benefit from the work I have done providing business level wrappers around the SAP web services. SO, what I can now do, is right-click on the SAPFacade application within the Application Designer, and select "Add To Toolbox". Now this component will be available on my toolbox, for re-use in other application designs (and I can export it for others to use as well). Of course I can use this to add other enterprise wide common components, like InfrastructureWS. Now that ROCKS!

More next week, as I start to "flesh out" my logical Datacenter Design.