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

This dialog shows the method we just created in Visual FoxPro. We see the name and also the in and out parameters. For instance, we see that the second parameter is named “BidDocument” and that there is a return value (RetVal) of type “integer” (i4). BizTalk always ads a first parameter which is the sender name and an additional out parameter that indicates whether the operation was successful (we only specified one parameter…). This demonstrates the importance of the new strong-typing feature for interfaces in Visual FoxPro 7.0.

We don’t need to change anything in this dialog and simply accept all the defaults by clicking “OK”.

So far, our example is relatively simple and straightforward. We receive one XML document and pass it to a COM component that receives one parameter and returns a value indicating whether or not we are good to go. However, this could be much more complex if our component had more parameters. For this reason, we also have to design the data flow. This can be done in the second page of the diagram:

The idea is simple. The document that is coming in through the first port we designed (from the message queue) is routed to the BidDocument parameter of the second port (our COM Component).

It’s going pretty well so far. We receive a message from a queue, hand it over to the COM component and receive a return value indicating whether we can accept the bid. We will now use the decision shape to put that return value to work. To do so, double-click the “Bid Acceptable” rule in the decision shape (make sure you double-click the rule and not the entire shape!) to get the Rule Properties dialog. Put the following code in the script expression field:

    Verify_out.RetVal = 1

The specified expression can be any valid VBScript expression. The syntax is a little weird at first, because the entire block of return values is presented to us as an object named “Verify_out” and the return value we specified in our component is accessible through the “RetVal” property.

I’m sure you can manage to create the script for the “No Prices Named” rule. We do not have to create any script expressions for the “Else” rule. This is similar to the “OTHERWISE” branch in a Visual FoxPro “DO CASE” structure.

Let’s proceed with the flow after the “Else” rule. All we have to do here is send a denial message. We can do so using the BizTalk routing services. Simply drop a “BizTalk Messaging” shape on your diagram, name the new port “SendDenial”, specify we want to send a message, and specify a BizTalk Server Channel. Since we don’t have a Channel to send a denial yet, you have to use the BizTalk Management Desk to create a new Channel. I named my channel “Send Bid Denial”. I describe how this is done further above in this document. As a rough guideline, first create a BizTalk Server Port to an organization (you can also use an existing port) such as West Wind Technologies. Then create the Channel that is linked to that port and name it “Send Bid Denial”. The inbound document format will be the EPSPurchaseBid document we have been using throughout this XLANG example. You can choose any document format you want for the outbound document. If the outbound document format is different from the inbound document, you will have to create a map to covert it. I created a special “BidDenial” document format. It is also up to you (or the administrator) to specify where the document is routed to. In my example, I set the port up to route to an email address for test purposes. Another good test option it routing to a file.

Once you are done creating the port on the diagram, select the “Send Denial” action shape and connect the right handle to the port. This will launch the “Add Message” dialog as in the previous scenarios. However, this time we can reuse the “EPSPurchaseBid” message we defined as the incoming message from the queue. To do so, select “Add a reference to an existing message” and click “OK”. If the arrow is read and point to the port, you are all set. Otherwise, double-click the action shape and change the message direction to “Send”.

Reusing the message saved us some work. Since we already specified how the “EPSPurchaseBid” is set up, we don’t have to specify document formats or the data flow.

Since this branch of the scenario ends after the denial notice is sent, we are all set. You can now go ahead and repeat the process for the bid approval and the quote. To keep the scenario simple, I recommend ending the flow (for now) after the approval notice. You can later implement the rest of it.

Compiling and Executing the XLANG Schedule

We are done implementing the application, so let’s go ahead and compile it. This is a simple step. First, save your diagram, then select “Make XLANG xxx…” from the file menu of the BizTalk Application Designer. This will create a compiled XLANG schedule and store it on your harddrive. We are now ready to execute it.

Manual Execution

The schedule we implemented requires a message to be placed in the specified queue before we can execute the XLANG Schedule. I created a form that performs that task for us:

The message in the editbox is a valid EPSPurchaseBid message just like the one created in my first routing examples at the beginning of this whitepaper.

The first step we have to take is posting this message to the queue we specified in the XLANG Schedule. Here’s the code that does that:

    LOCAL loMSMQMessage AS MSMQ.MSMQMessage
    LOCAL loMSMQTransaction AS MSMQ.MSMQTransactionDispenser
    loMSMQTransaction = CREATEOBJECT("MSMQ.MSMQTransactionDispenser")
    loMSMQInfo.FormatName = ALLTRIM(THISFORM.Text2.Value)
    loMSMQQueue = loMSMQInfo.Open(2,0)
    loMSMQMessage = CREATEOBJECT("MSMQ.MSMQMessage")
    loMSMQMessage.Body = THISFORM.Edit1.Value
    LOCAL lvTrans
    lvTrans = loMSMQTransaction.BeginTransaction()

The queue name is specified in the first textbox. You can see the exact name of the queue in the image above.

Once the message is in the queue, we can execute the XLANG Schedule. This is simple. Here is the code:


We simply use the GetObject() function and the file name (with some extra information) as the moniker. This leaves it up to the operating system how to actually run the schedule. This is very similar to using the name of a Word document as the moniker. In that case, the operating system figures out that Word is the server responsible for the specified document and executes it right away. The same happens with the XLANG Schedule. Once the operating system figures out what to do with it, it runs it right away.

Here’s the exact syntax for the moniker:


The moniker specifies the “sked” object to be used to figure out what object we need to run the schedule. The second part is the actual file name and finally, we specify the entry point, in this case “main” which is the beginning of the document (on long running scenarios we could run scenarios starting at different points).

When you run this code, the document will get processed and routed according to the schedule we just defined. If the bid was acceptable, we should get an approval notice, a denial notice or a quote. Where those documents will show up (and in what format) depends on your BizTalk Server Port configuration. As mentioned above, I like to route to email addresses and files for testing purposes.

Routing to an XLANG Schedule from BizTalk

This task is not yet supported in Beta 1, but it is planned for the release version.  As more information becomes available I will make it available on my website.

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