Verifying Bindings, Enlisting, and Starting the Orchestration
To verify the orchestration bindings, refer to Figure 24
, which provides a snapshot of all required bindings and settings.
|Figure 24: The Port Binding Properties provides a summary of Inbound and Outbound logical and physical port mappings.|
The process of enlistment associates ports and orchestrations with the appropriate host and creates the corresponding subscriptions within the configuration database.
- Right-click the Northwind.BusinessWorkflows.RetailsOps orchestration and click Enlist.
At this point, the orchestration and ports are not yet capable of receiving or sending messages because the orchestration has not yet been started.
- Right-click the Northwind.BusinessWorkflows.RetailsOps orchestration, and click Start.
|Figure 25: Generating a UI wrapped proxy for the SOAP endpoint exposed by the SendPO orchestration using .NET WebServiceStudio, a free tool for testing SOAP Web services.|
You'll need to perform some testing to verify that the orchestration and all services meet the functional requirements.
First, you should be able to submit a purchase order for processing via a SOAP service endpoint. To test this, I use a great tool called Web services Studio (see Sidebar 4, ".NET WebServiceStudio"). This tool makes a fantastic, no-frills test harness for exercising SOAP services. The value and necessity of using test harnesses to provide interactive testing of services that make up a complex application cannot be overstated. After querying the WSDL file at the endpoint, I have a contract that I must fulfill as shown in Figure 25. Populating all relevant fields, I submit the purchase order to simulate the interface that the new online storefront will use.
Since this is a one way, asynchronous call, I do not expect any response via SOAP other than HTTP 202 Accepted (any errors in receiving the message would have resulted in a SOAP fault). Figure 26 shows the expected response from the RetailOpsService.
|Figure 26: An HTTP 202 (Accepted) is returned by the SOAP endpoint indicating that the message was accepted asynchronously by the orchestration.||
|Figure 27: The orchestration outputs the original message contents to the specified file folder to simulate notification of a successful transaction.||
Finally, to ensure that the purchase order was processed, inspect the C:\Outbound\CompletedPurchaseOrders
folder (or physical location you configured in the bindings) for an XML file corresponding to the purchase order submission. As shown in Figure 27
, there should be one .xml file for each submission made during the test. Opening the XML document reveals the details of the purchaseOrderMsg
At this point, the Retail Operations application is ready to be turned over for integration with the new online store front! Leveraging the Retail Operations application is simply a matter of consuming the service endpoint and invoking the service. In addition, the foundation has been laid for integrating various other applications with the new and improved Northwind back-office, all the while increasing transparency and increasing automation so that the business process can be managed more efficiently.
In addition to a very solid Messaging Engine, I demonstrated how the Orchestration Engine is a very flexible tool for getting the most out of messaging while naturally supporting the implementation of complex business process via intuitive and easy-to-use workflows.
After a high-level overview (in Part 1 of this article), you leveraged both the Messaging Engine and Orchestration Engine by jumping into a common integration scenario and demonstrated how a new, automated workflow, along with .NET, and ASMX SOAP web services could be implemented to streamline existing business processes while providing the building blocks for improved business process management.
Furthermore, you now understand the foundation for integrating the new solution with an existing business process to drive value without abandoning legacy systems, providing virtually endless possibilities for connecting new and existing services and applications without impacting the business process itself.
Finally, you applied some design techniques allowing you to address the problem domain in a loosely coupled manner that can be extended to support new workflows, components, and services as the needs of the organization change and grow.
Although our scenario has been grossly simplified for the purposes of illustration, it is a good example of similar integration scenarios that are prevalent in the enterprise today. It is clear that BizTalk Server 2006 is a very practical solution for addressing many of these EAI chores and goes far beyond messaging to provide a toolbox for addressing the integration spaghetti that exists as a result of the evolution of new and existing investments in enterprise software.
During the introduction (see the May/June issue of CoDe Magazine), I suggested that the Orchestration Designer provides a hint as to what the future of building software might look like (see Sidebar 5, "Orchestration Designer for Business Analysts"). As a matter of fact, Windows Workflow Foundation (WF), a new workflow modeling framework that is part of .NET 3.0, builds upon what Microsoft, and the industry as a whole, has learned from BizTalk Orchestration. Looking even further into the future, I believe that workflow-modeled software will become a mainstay in developing line-of-business applications, and we will start to see a number of specializations emerge in the industry, creating a distinction between traditional programmers and future information workers.
New technologies, including WF and Windows Communication Foundation (WCF) will no doubt be relevant to BizTalk Server, but I believe that by leveraging BizTalk Server 2006 as the integration glue for developing new applications that assimilate with legacy systems today, while laying a solid foundation for future enterprise application integration projects in the future, BizTalk will continue to provide tremendous value as an application server platform.
I hope that you have developed an appreciation for the depth and breadth of the core functionality and features available in BizTalk Server 2006 and that you will consider it for your future adventures in application integration!
I would like to thank Todd Sussman, Principal Consultant and BizTalk VTS, for teaching me what the books and hands-on experience could not. Those coffee breaks, instant messaging sessions, and white board discussions have been invaluable.
In addition, I would like to thank Tim Heuer and Diane Faigel at Microsoft for their help with the BizTalk Server 2006 documentation, which is referenced throughout the article.
Last, but certainly not least, I would like to acknowledge Juval Lowy, who over the course of a week in the summer of 2005 changed my career forever. His books, articles, classes, and lectures continue to provide valuable insight and mentoring; the fruits of which are interwoven throughout this article and my work at large.