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

If the server is running, the document or the routing information may be invalid. In the worst case (document is invalid, document format isn’t defined, or one of the organizations is unknown), the message will end up in the “Suspended Queue”. Click on that node and check whether there are any messages in that queue. If so, right-click on it to see the error message that goes along with the problem. Typically, the error information will be very sparse, and you will be referred to the Event Viewer for more information. The Event Viewer is available inside the Administration interface. Just click on the “Application” node and look at the first error in the list. This should give you a good idea of what went wrong. You can then remove delete the message from the Queue, attempt to fix the problem and retry.

Sometimes, the error may not be very severe and BizTalk may think it will be able to route the message later on. In this case, it will end up in the “Retry Queue”. If your message is stuck in there, right-click on it and manually move it to the “Suspended Queue”. From here on proceed as described above.

Submitting Documents to Web Pages

OK, so far so good, but we don’t really want to use a VFP form to submit documents, do we? What we really want is a web site that the message can be posted to. Luckily, this is very similar to submitting messages from a VFP form.

In order to receive documents on a web site, you have to have some kind of processing mechanism such as a Visual FoxPro back-end (Web Connection, Visual WebBuilder or even FoxISAPI can be used) or Active Server Pages (ASP). Here’s an example of an ASP page that accepts the document and passes it on to BizTalk:

<%
Dim oBTS, objADO
if Request.totalBytes = 0 then
   Response.Write "No Data Posted From BizTalk Server."
   Err.Raise vbObjectError+ 101,,"No Data Posted."
   Response.End
end if
 
Set objADO = CreateObject("ADODB.Stream")
objADO.Open
objADO.Type = 1
objADO.Write Request.BinaryRead(Request.TotalBytes)
objADO.Position = 0
objADO.Type = 2
 
Set oBTS = Server.CreateObject("BizTalk.Interchange")
oBTS.Submit 1, objADO.ReadText, "West Wind Store Order",
   "Organization Name","West Wind Technologies",
   "Organization Name","Home Organization"
Set oBTS = Nothing
%>

Although the syntax has changed slightly, we are still performing the same basic task. We are instantiating an instance of the BizTalk.Interchange object and submitting the message, only this time the message came in as the request information that’s provided by ASP. Also, we had to take a detour through ADO to convert the submitted document into Unicode, a task Visual FoxPro takes care of for us in the form example.

For those of you using Web Connection or Visual WebBuilder, here is some code you can put into a process object or a VFP code snippet:

LOCAL lcDocument, loBT, lvResult
lcDocument = Request.Form()
loBT = CREATEOBJECT("BizTalk.Interchange")
lvResult = loBT.Submit(1,lcDocument,;
           "West Wind Store Order",;
           "Organization Name","West Wind Technologies",;
           "Organization Name","Home Organization")

OK, with this in place, West Wind Technologies can now submit an order document to our web site to automatically route the order to our backend processing system (well, at this point the document ends up as a text file on disk, but we are not done yet…).

Submitting a Self-Routing Document

Self-Routing Documents contain information about the source organization, destination organization, document type and organization identifiers. All this information has to be identified in the document definition to indicate to BizTalk Server where that information can be found. This is done using the “Dictionary” tab in the document editor.

Depending on the submitted message, the routing information can be contained in the actual message (this is typically the case in BizTalk Framework compliant messages) or in an envelope.

When submitting a self-routing document, the basic steps are the same as with manually routed documents (see above) with the difference that only the first two parameters are passed to the Submit() method.

Routing Documents to Non-BizTalk Organizations

A very important aspect of B2B scenarios is that you cannot count on your business partners running a BizTalk Server on their end. You can’t even count on them using XML. In fact, you can’t even count on them having any B2B system in place. So there has to be good ways to route information to organizations that are organized differently (or aren’t organized at all). BizTalk provides several features to support these scenarios. In most cases you will be fine setting up the communication using email. You can route messages to email addresses, but you cannot retrieve documents through incoming mail automatically.Instead you have to write your own components that watch for incoming mail and submit it to BizTalk (just like you can’t retrieve documents over the Internet automatically, but you have to write a server component such as the ASP page from above…).

At the time I write this, BizTalk Server Beta 1 is available. This version does not support some of the features that were available in the Tech Preview version and that have been discussed by Microsoft, such as faxing information. We’ll have to wait and see what features the release version will support.

Routing to Application Integrator Components (AIC)

Application Integrator Components (AICs) can be used to extend BizTalk’s routing mechanism. Let’s assume for instance, that you would like to route straight into a Visual FoxPro DBF, rather than an HTTP address or any of the other targets supported by BizTalk. Obviously, BizTalk Server does not know how to handle DBFs, but you can write a COM Component that does.

Note: At the point of writing, AICs cannot be created using the currently available Visual FoxPro 7.0 beta version. For this reason, I only describe a small Visual Basic example that raises a message box. I will make more information available as soon as Visual FoxPro supports this feature. Here is the Visual Basic code that creates an AIC:

Implements IBTSAppIntegration
Private Function IBTSAppIntegration_ProcessMessage( _
   ByVal bstrDocument As String) As String
   MsgBox bstrDocument
End Function

The idea is to implement the “IBTSAppIntegration” interface. You need to compile this code into a COM Component and register it in the COM+ Catalog (add the component to a COM+ Application). This is important! When a component is added that implements the IBTSAppIntegration interface, it is automatically registered with BizTalk Server.

Note: The interface is defined in the Microsoft BizTalk Server Application Interface Components 1.0 Type Library. You need to add that library to your Visual Basic project references before you can compile the above code.

Tracking Documents

BizTalk Server 2000 allows tracking all documents that are routed through the BizTalk Server engine. Tracking can be specified on Channels. In order to activate tracking on a channel, BizTalk Server itself has to be configured for tracking. This can be done in the BizTalk Server Administration snap-in. Simply right-click a server group and select the tracking page.

You can look at tracking information using a web based tracking interface that is automatically installed with BizTalk Server 2000. You have a link to the tracking page in your start menu. The initial page allows specifying a query:

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