[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ]

But let’s do this a step at a time, starting out with the first shape at the top-right corner. As you can see, this is an MSMQ item. For now, I assume that this scenario is started when a message gets put into a message queue. For now, we will not worry about how it gets there. To create this shape, simply drag and drop the Message Queuing shape on your diagram. This will launch a wizard. In the first step, you are asked to specify a port. This is NOT a port in the BizTalk Server sense. Just imagine a port as a connection between the right and left side of the diagram, and you won’t be too far off (there is a little more too it, but we will worry about that later). Name the first port “ReceivePB” and proceed to the next step (can you spot that port in the diagram above?).

Now, the wizard asks whether we already know what queue we want to use or whether this will be determined at runtime. In our example, we will hardcode a queue name, so we know it. Select the “Known at design time” option and proceed to the next step where you are asked to specify a queue name. To make the example further down work, name the queue “.\private$\ReceivePB”. Note that this requires MSMQ to be installed on your system, and it also requires the specified queue to exist. So while we are at it, open your Computer Management snap in, drill down to the queuing service node, right-click the “private” queues node and add a new node named “ReceivePB”. Make sure the queue is transactional.

OK, back to the wizard. In the last step (“Advanced”) stick to the default settings and click “Finish”.

This created a port and the MSMQ shape, but it did not yet create a connection to the first action shape in the diagram. To create that connection, highlight the “Receive Purchase Bid” shape and drag the right handle of the shape to the port. This will bring up another dialog. Select the options “The XLANG Scheduler Engine should asynchronously deliver the message” and “Create a new message” and click “OK”. You are now asked to specify a message name and an XML root element name. For both, use “EPSPurchaseBid”. This specifies that we will receive a purchase bid message and the root node of the incoming document is “EPSPurchaseBid”. We could also specify a schema for the incoming document, but for now, we’ll simply click OK.

The diagram should now show a blue arrow going from the port to the action shape. If the arrow is red and pointing the other way, double-click the “Receive Purchase Bid” action shape and change the “Message Direction” property to “Receive”.

We are now ready to receive a purchase bid (note that this could be the purchase bid document we set up when I described simple routing operations from West Wind to EPS further up in this document…). It is now time to do something with that information. Our flow chart defines that the next step is to calculate the prices. To do so, I created the following Visual FoxPro 7 COM component:

DEFINE CLASS VerifyBid AS Session OLEPublic
   PROCEDURE Verify (BidDocument AS String) AS Integer
      LOCAL loXMLDOM, loAgreement, loBidTotal
      loXMLDOM = CREATEOBJECT("Microsoft.XMLDOM")
      loXMLDOM.LoadXML(BidDocument)
     
      loAgreement = ;
         loXMLDOM.SelectSingleNode(;
         "EPSPurchaseBid/PBHeader/@TradingPartnerAgreement")
 
      IF loAgreement.Text = "WestWind"
         RETURN 1
      ENDIF
 
      loBidTotal = ;
         loXMLDOM.SelectSingleNode(;
         "EPSPurchaseBid/PBHeader/@BidTotal")
 
      IF VAL(loBidTotal.Text) > 0
         RETURN 0
      ELSE
         RETURN -1
      ENDIF
   ENDPROC
ENDDEFINE

The component is rather simple. It has one method that receives an XML string (a bid document) as a parameter and returns 1 if the bid is acceptable, 0 if it is not and –1 if no prices were named (the return value therefore is of type “integer”).

The decision mechanism is (for the sake if this example) rather simple. First, we check whether the agreement is with “West Wind”. If this is the case, we accept the bid. Otherwise, we check whether the total is greater than 0. If not, no price was named and we return –1. If none of this was the case, we simply return 0 to indicate that we do not want to accept the bid. This is a little farfetched, but it will be good enough for this example.

Compile this class in to a multi-threaded COM component and switch back to the BizTalk Application Designer.

Drop the “COM Component” shape onto the diagram. This launches a wizard similar to the one for the Message Queue shape. First, we define a new port. This time, we name it “VerifyPurchaseBid”. In step 2, we specify that we want to use the XLANG Scheduler Engine to instantiate the component. In step 3, we select the component we just compiled. I named mine “EPSPurchaseBid”, so I scroll down until I see that component, expand it, and select the “VerifyBid” class (which is the class we just created…). In the next step, we need to specify the methods we want to use. So far, the only method we have is “Verify”, so we select this one. In the last step, we accept all the defaults and click “Finish”.

Again, we created an implementation shape and a port, but the port isn’t connected to the “Calculate min. Prices” action shape. We create the connection in the same way we did above (select the action shape and drag the right handle to the port). This launches a dialog where we chose to execute the method synchronously and that we want to create a new message. Once we click “OK”, the following dialog appears:

[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ]