Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Server

BizTalk Server 2006 : Starting a New BizTalk Project - Starting Preliminary Design

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
3/5/2013 6:00:29 PM

The team structure outlined previously gives the basics for forming and managing a large group of developers. It also allows the team to scale outwards or inwards depending on new requirements being introduced or having features move out of scope. The key takeaways from this model are the following:

  • Break the solution down into functional groups or subsystems. Assign and manage deliverables based on these groupings.

  • For projects that require common infrastructure, create a separate team that is responsible for creating and managing this. Ensure that the design for any common components is well defined and used by other functional teams.

  • Assign developers to either a functional team or to the common infrastructure team. Assigning developers to more than one team is often problematic as it forces them to split time for multiple deliverables.

  • Rotate developers across teams when deliverables are complete. This encourages cross-group collaboration and decreases "knowledge silos."

  • Encourage a regular build cycle. This will help to keep the project on track and gives the team members regular code check-in dates that must be met.

On a BizTalk development project, these concepts become even more important. Most BizTalk architects do not take the time necessary to determine how to properly structure the application so that it can be coded using a model like the one defined earlier. Likewise, very few map out what common infrastructure will be needed and what types of artifacts are "feature specific" and which are common infrastructure. Following is an exercise that illustrates this.

Design the Solution

List what features are needed for the solution to be implemented in this exercise scenario. Then list what common components will be required for each subsystem.

Scenario:

ABC Company, Inc., is creating a new solution using BizTalk Server. The system is an order fulfillment application that will receive order information from the public web site, a retail POS (Point of Sale) system, and a custom bulk order solution that is used by large customers. Only customers in good standing are eligible for automatic fulfillment, and presently the project is only piloting customers in four geographic regions. If a customer does not meet the requirements for automatic fulfillment, the order is rejected and manually fulfilled. For orders that can be autofulfilled, the solution must first check the stock availability for each product by an SAP ERP system using a custom API. If stock is not available, it must decide whether the order can be split into multiple shipments and fulfill each separately. If the order cannot be split shipped, it must be rejected and processed manually. If an order can be fulfilled, it must update the billing and shipping systems appropriately. The shipping system is a legacy mainframebased application that requires custom code to be executed to properly authenticate and send transactions to it.


Possible Solution:

In this scenario, the most logical approach would be to separate the solution based on the requirements. There are three key features of this solution:

  • Order taking from external sources (POS, web site, and bulk orders)

  • Stock checking and rules associated with split shipments

  • Updating downstream systems

Each subsystem will have its own pieces and artifacts; however, all of them will need to use the following types of core components:

  • Access to customer information

    • Common schema to define customer information

    • Standard way to get access to that customer information

    • Executing customer rules associated with automatic fulfillment

  • Coordination to ensure that the fulfillment process is handled in the proper order

  • Order rejection subsystem

  • Standard way to process exceptions and errors

In this scenario, the solution can be implemented using the architecture in Figure 1.

Figure 1 .External interfaces design

Feature 1: External Interfaces

This subsystem is responsible for receiving inbound messages from the three external interfaces. Here, the external interfaces can be XML messages, flat-file messages, or custom inbound API calls.[] In any case, this subsystem will need to parse the inbound document and transform it to a common schema that represents an "order" within this solution. This order schema will be used by all other subsystems. In the case of the bulk upload, the subsystem will be required to create individual orders based on the entire payload of messages stored within the order file.

[] In many cases, the system that will be sending BizTalk messages is either a proprietary COTS (commercial, off-theshelf) system or requires special transports such as a custom TCP listener. In these scenarios, it may be preferable to buy an external adapter or create a custom one using the Adapter Wizard.

This scenario can be implemented using receive ports within BizTalk along with several receive locations. Each receive location will define a custom receive pipeline if the document needs to be examined and/or disassembled before being processed. The port would then have different BizTalk transformations assigned to it to allow it to map the inbound system order schema to the common system order schema that is used by all subsystems.

Feature 2: Check Stock and Associated Rules

The stock-checking subsystem will be responsible for calling the customer lookup system, as shown in Figure 2. This will also check whether or not the order can be fulfilled and return the response. Note that in this scenario, the coordination of calling the order rejection system as well as the coordination of this process into the larger fulfillment process is left to the responsibility of the common infrastructure. This subsystem is responsible for determining whether an order can be fulfilled and is not responsible for how or why this information is needed. This is often referred to as black-boxing a solution. This will allow the subsystem to be built in isolation of any other subsystem. Only integration points are needed to be defined before development is started, in this case, the schemas for an order and a customer as well as the format of the response.

Figure 2 . Stock information service design

Feature 3: Update Downstream Systems

To update the downstream ERP and shipping systems, the validated order will need to be sent via a BizTalk send port via the appropriate adapter. This is demonstrated in Figure 3. The adapter to be used depends on what downstream system is going to be updated. In the case of the ERP system, if this were an SAP application, the port would use the SAP adapter. The same would hold true if it were an MQSeries queue—the port would use an MQSeries adapter. For the custom shipping solution, a custom adapter will need to be created if no off-the-shelf adapter is available. Note that in this system, the send pipelines are responsible for packaging the message into its appropriate format, adding any security information such as digital certificates, and encoding it properly so that the downstream system can read the order information. The send ports also return a response message back that indicates whether or not the update was successful. What to do with that response message is the responsibility of the caller, not the pipeline, adapter, or send port.

These common subsystems also need to be built:

  • Coordinate fulfillment process.

  • Get customer information.

  • Handle errors.

  • Handle order rejections.

Figure 3. Update Downstream Systems design
Other -----------------
- Microsoft Content Management Server Development : Validating Placeholder Controls - Validating the SingleAttachmentPlaceholderControl
- Microsoft Content Management Server Development : Validating Placeholder Controls - Validating the SingleImagePlaceholderControl
- Understanding Network Services and Active Directory Domain Controller Placement for Exchange Server 2007 : Domain Name System and Its Role in Exchange Server 2007
- Extending the Real-Time Communications Functionality of Exchange Server 2007 : Installing and Using the Communicator 2007 Client, Web Conferencing with Office Live Meeting
- System Center Configuration Manager 2007 : Operating System Deployment - Task Sequences (part 3) - Task Sequence Targeting
- System Center Configuration Manager 2007 : Operating System Deployment - Task Sequences (part 2) - Tasks
- System Center Configuration Manager 2007 : Operating System Deployment - Task Sequences (part 1) - Variables
- Microsoft Dynamics GP 2010 : Preventing Errors in Dynamics GP - Correcting errors by backing out, correcting, and copying Journal Entries
- Microsoft Dynamics GP 2010 : Preventing Errors in Dynamics GP - Preventing sales of Discontinued Inventory
- Windows Server 2003 on HP ProLiant Servers : Active Directory Logical Design - Replication Topology (part 3) - Designing an Efficient Replication Topology
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
 
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server