Implementing a Business Process An Example

Earlier in this chapter, we looked at a UML-based method that helps us in analysis and design of our Problem domain.We used a Bank Account example—in particular, the Make Money Transfer Use Case—to show what the different ICONIX steps are in the analysis and design phase of a project. It is true that such an example has a limited value, and the advantage of a method such as ICONIX will only manifest itself in larger projects. Hopefully, you already see its value and haves plans to start reading books on UML—after you finish this book, of course. If you have already used UML, you may have gotten a different look on how a minimal UML also works. In this chapter, we set out to show you what BizTalk Orchestration Services is all about.You have seen what you can accomplish with the BizTalk Orchestration Designer, but now it is time to see how you go from the ICONIX results—for which we use our Make Money Transfer—to a working business process in Orchestration Designer. Let us walk through our example and see how we can make it work. Afterward, we will try to make some generalizations that can help you as guidelines for bridging the gap between the design and implementation. (The source code for this example is available at Take the following into account:

■ Since our BizTalk business process is not involved in any user interface interaction, some other application needs to take care of that. A good option is Active Server Pages.

■ We have to decide what instantiates our schedule. We have two options: (1) when the customer clicks the "Make Money Transfer" button; or (2) when the customer clicks OK to shoot out the money transfer transaction. For our schedule, we will choose the former, so we keep the Use

Case as it is designed. Since we need to make the instantiation for this customer, the instantiating message just needs to contain the customer credentials.

■ The first real action is to retrieve a list of bank account numbers that the customer owns.This can be done to make a call to a component that we develop to do so. In our schedule, we will use a Script component for quick development.

■ We will choose to send the message over a queue that is created for every schedule instance, and will use this queue throughout the rest of the schedule to communicate with the Active Server Pages that wrap the user interface.

■ The next step is to wait until the customer sends his or her transaction data. For security reasons, we decide not to wait longer than five minutes; after that, we end the schedule. Whether the ending is an End or Abort will depend on the use of a long-running transaction.

■ Once the data comes in, we can start validating it. However, one of our alternate courses is that the customer can cancel the transaction.We assume that, either way, we get a message that has the transaction data, and a Status field. This field can be used to transmit the cancellation.

■ So, we have a three-way decision: abort, timeout, or OK. The latter will be wrapped in the Continue rule of the Decision.

■ The next thing to do is start validating the recipient data. We use a Script component to do so.

■ If the data is not OK, we need to return an error message and wait on new data. In real-life application data, you will see that this validation is performed into the first tier; this can be the Web site or even an ActiveX Control on the customer's system. In our example, we keep it in the schedule. Again, we need a Decision.

■ The next actions are Retrieve Bank Account Details, Retrieve Customer, and Validate Bank Account Data. For convenience and because they handle the same data, we do all in the same Script component.

■ If the bank account data does not validate, we return an error, or we create a preliminary transaction, followed by a request for a confirmation.

■ Now we must wait for a response—again, for five minutes max—and we can get an OK or Cancel back.

■ If we get the Conformation, we can shoot a message to the Process Debit Transaction Schedule.Whether this message instantiates this Schedule or if it is continuously running to process all transaction is a decision you can make yourself. It will work either way. In this example, we use a Channel. Since we do not know if or when the transaction actually is processed, we will not wait for it and finish the Make Money Transfer schedule.

Now we have completed the draft of our Use Case business process, we can decide on the use of a transaction. There are indicators that make it worth considering the use of one or more transactions:

■ We using a five-minute waiting period and since dehydration starts after 180 seconds, we must be sure that we do not need to persist any data. However, we do not want the timeout period to abort the transaction and retry it, since we timed out for security reasons.

■ In case we receive invalid recipient data, we have to wait for a new response. If we want to use a transaction, we can just abort it and start again.

For the sake of the example, we will use a long-running transaction. Figure 7.39 shows the flow before the transaction, and Figure 7.40 shows the flow after the transaction. One thing to notice is that even with a simple Use Case, the page is being filled quickly, which can be a serious handicap. (We had to heavily edit the flowchart to get it on one page in this book!) Figure 7.41 shows the action port setup, which also had to be edited to fit in the book. Figure 7.42 shows you the data flow that corresponds to Figure 7.39. Lastly, Figure 7.43 shows the partial data flow page.

Figure 7.39 The Make Money Transfer Schedule Business Flow without Transaction

Receive Customer Identification


Retrieve Bank Accounts




Display Bank Accounts




Receive Transaction Data



Validate Recipient ecj^er

Decision —I Not OK

Else I-


Confirmation Request





Receive Response



Was this article helpful?

0 0

Post a comment