Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Enterprise Application Integration with Microsoft BizTalk Server 2006, Part 2 : Page 2

Walk through this simple but common integration scenario to find out how to include BizTalk Server 2006 in your own application integration projects.


advertisement
Requirements and Scope
One of the primary roles of application integration is to integrate new and existing applications to support the business process. In this case there are a number of components and services that need to be developed and integrated to support the new and improved Northwind Traders business process. Assume that another team is building the new web site, so the deliverable that this article will address is an entry point, or a gateway to the middle-tier components and services. I'll show you how to use the .NET Framework, Visual C#, SOAP web services, and BizTalk Server to build, orchestrate, and deploy the foundation for the company's business process engine.
Sequence diagrams and object models provide a useful system and API aspect to the design, but the business process, or workflow, must also be modeled to ensure that the business process is implemented correctly.
The best way to communicate the requirements for these new middle-tier components and services is by looking at the proposed business process depicted in Figure 2, which provides a "happy path" for the new and improved order fulfillment process at Northwind Traders.

 
Figure 2: The proposed Northwind Traders Order & Fulfillment process.
The use case diagrams make it clear that the IT department must design and develop a number of components and services to support the new Retail Operations application. This is the Northwind Trader's business process at its core, and as such represents a blueprint—representative of the desires and expectations of its stakeholders—for addressing a technical solution. This kind of interactive dialogue with the business and stakeholders is critical, because they are not so much concerned with the technology or architecture as they are in getting the results they expect. The fact that this article has no user interface deliverables will make it even more important to maintain the right focus on the component and service definitions and APIs so that they can be consumed as easily as possible by the developers of the Web site that will leverage the Retail Operations application as it's middle-tier. Designing the Solution
After digesting the requirements it is time to perform some pragmatic modeling. This step is critical in not only understanding the business domain, but in thinking about how, technically, the requirements will be met.

There are several great options for capturing this information. Figure 3 depicts an informal sketch of a system-level sequence diagram. Architects use sequence diagrams to think about and communicate time and interaction between platforms and components to depict synchronous versus asynchronous calling patterns. Method signatures may change during development, but because this is a system-level aspect diagram, we will be able to discern the various components and services being proposed for each interaction that contain the Retail Operations application.

 
Figure 3: A system-level sequence diagram for the new Northwind Traders Order & Fulfillment process provides the time and component interaction aspects of the system.
 
Figure 4: The object model for the core components and services that will be orchestrated by BizTalk Server Orchestration.
Figure 4 provides a light object model of the required components/services. This model serves as a basic API reference for architects, developers, program managers, and analysts. Although object models will undoubtedly change somewhat during the development process, initial drafts should capture all of the major operations that will be supported. In fact, the API should be somewhat simple to correlate to the use case diagram.


The goal of this modeling exercise is not to provide academically accurate UML 2.0 diagrams; but rather to be pragmatic in communicating the proposed design and other relevant aspects to the appropriate audience. See Sidebar 1, "Agile Modeling," for a great reference to these and other modeling diagrams.

BTS 2006 provides an optional Microsoft Visio add in, known as the Orchestration Designer for Business Analysts (ODBA). The tool is intended for facilitating collaboration among developer, analyst, and stakeholder in designing orchestrations around business processes.
Sequence diagrams and object models provide a useful system and API aspect to the design, which is useful mostly to architects, developers, program managers, and analysts. The business process, or workflow, must also be carefully modeled to ensure that all of the artifacts depicted in the previous models are implemented such that they actually support the business process. It goes without saying that getting the business process right is critical, and as such should be a very collaborative exercise between architects, developers, program managers, analysts, and business stakeholders. To do so, I'll use a business process model diagram to communicate the workflow of the proposed business process.

Business process modeling facilitates the ability for both engineering and business roles to collaborate and verify that the model is accurate and reflects the current (or proposed) business process. The BizTalk Orchestration Designer has an extremely intuitive design surface that naturally resembles business process models very well. In addition, BTS 2006 provides an optional Microsoft Visio add in, known as the Orchestration Designer for Business Analysts (ODBA). The tool facilitates collaboration among all roles in planning the design of orchestrations around business processes. I will use the ODBA to model the business process and workflow depicted in the proposed use case in Figure 2. Later, I'll show you how to import the diagram into Visual Studio 2005 and use it as a blueprint for implementing the orchestration itself.

Using ODBA to Model the Business Process

Author's Note: ODBA is free, but you must have Microsoft Visio 2003 in order to use ODBA. Installation is completely MSI-based and takes under two minutes. If you would like to skip this walkthrough and use the Orchestration Designer to create the general workflow, you may do so. Keep in mind that the fully functional Visual Studio 2005 solution is also available for download and can be used as a reference as well.

 
Figure 5: The Orchestration Designer for Business Analyst template is an add-in to Microsoft Visio.
  1. Having installed ODBA, go to Start—> Programs—> BizTalk Server 2006, and select Orchestration Designer for Business Analysts. Alternatively, within Microsoft Visio 2003, click New, select BizTalk, and choose the Orchestration Designer for Business Analysts template. You will see a blank drawing as shown in Figure 5.
  2. Drag a Group Shape from the Orchestration Designer stencils and drop it under the Begin Shape. A Group Shape isolates activities so they occur as a unit of work. The first part of the orchestration will begin with retail-related operations, so name the new Group "Retail Activities."
  3. As reflected in the use case, you'll first handle billing and general ledger posting. Drag two Action Shapes into the Retail Activities Group and name each similar to what was captured in the use case (see Figure 2). Connect each shape (by simply dragging the arrow), starting with the Begin Shape, down to the Group Shape, and from the beginning of each shape to the next shape.
  4. Perform similar steps for Inventory and Print activities.
  5. Now, outside of the groups, add a final Action Shape called "Notify." Connect the outer boundary of the Print Activities Shape to the top of the Notify Shape. At this point, the diagram should resemble the image shown in Figure 6.
  6.  
    Figure 6: An Action Shape is added to the business workflow which will be used to send a notification when the order and fulfillment process has completed successfully.
     
    Figure 7: The Orchestration Checker provides Orchestration Designer for Business Analysts users with a way to validate workflow logic.
  7. This is a great time to introduce the Orchestration Checker. This tool is like a logic debugger to validate that you've followed the rules for interconnecting shapes and overall flow. To run it against the orchestration you just built, within Visio, click on the ODBA menu and select Check Orchestration. The tool reports that the business process does not end with a valid shape, (see Figure 7).
  8. With the Orchestration Checker still running, drag an End Shape to the bottom of the diagram and connect the bottom of the Notify Action Shape to the top of the End Shape. Click Recheck. The validation succeeds. Figure 8 shows the final diagram.
  9.  
    Figure 8: The process is modeled in Orchestration Designer for Business Analysts, a Microsoft Visio add-in designed for the collaboration between developers and business analysts in modeling business workflow.
     
    Figure 9: The business process diagram modeled in Orchestration Designer for Business Analysts can be easily exported as a blueprint for BizTalk Server 2006 Orchestration.
  10. Rename the tab at the bottom of the screen to SendPO. The SendPO orchestration will be the heart of the order and fulfillment workflow.
  11. Next, click the ODBA menu and select Export to BizTalk. In the dialog box, ensure that you've selected the SendPO Business Process page and click Browse to name the file. Save it in the location shown in Figure 9.
  12. Click OK to export the Visio diagram as a BizTalk Server 2006 Orchestration called SendPO.odx.


Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap