Monday, September 17, 2007

I was helping a client upgrade their BizTalk Server 2004 machine from an evaluation version of the SAP Adapter to the paid version. We got an interesting error warning in the Application Event Log right after the upgrade:

Event Type: Warning
Event Source: SQLSERVERAGENT
Event Category: Job Engine
Event ID: 208
Date: 9/17/2007
Time: 2:09:03 PM
User: N/A
Computer: XXXXXX
Description:
SQL Server Scheduled Job 'MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb' (0xD3864F44666B084B85AE11128905F6AE) - Status: Failed - Invoked on: 2007-09-17 14:09:03 - Message: The job failed. The Job was invoked by Schedule 19 (Schedule). The last step to run was step 1 (Purge).

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

This warning repeated every minute.

The problem was that when we installed the adapter, the job mentioned above had it's owner changed from the local BizTalk administrator to the "regular" BizTalk user. We changed the user to match all of the other BizTalk jobs in SQL, and no more warning messages.

Thursday, March 01, 2007

EDI R2 Issue (Not a Bug)

I recently implemented two outbound EDI transactions for a client, an 852 and an 867 to a single customer. I found that I was only able to send a single value for the GS01 element to a particular partner, even though I had entered a line for each transaction in the EDI setup for that partner.

In the EDI setup parameters for a partner (X12 Properties/Party as Interchange Receiver/X12 Interchange Envelope Definition/GS and ST Segment Definition), you can enter multiple lines to set up GS segments for different transactions for that partner. Normally, for an 867 the GS01 element should have the value “PT”, and the 852 should have the value “PD”. What actually happened is that if a particular line was set to be the “default”, the values on that line were being used for all transactions. And there is no way to avoid setting one of the lines as default.

The problem in this case went back to the EDI R2 tutorial. I blindly copied the parameters for my transactions from the outbound parameters that they had set up for the partner named "THEM". The target namespace was set to
http://schemas.microsoft.com/Edi/X12
, whereas for my configuration it needed to be set to
http://schemas.microsoft.com/Edi/X12/2006
. The ST1 value, version, and namespace are all used to identify the line that applies to the particular outbound transaction, and the rest of the parameters on that line are then used to build the GS segment. This is clearly specified later on in the documentation, on a page called "Configuring X12 Interchange Envelope Generation" under:
Development > Developing BizTalk Server EDI Solutions > Configuring a Party for an EDI Solution > Configuring X12-Specific Party Properties

Wednesday, February 21, 2007

BizTalk Orchestration Error Message

Sometimes when I'm editing an Expression shape in an orchestration, I see a little red exclamation point, which shows the following when moused over: "The expression that you have entered is not valid. Click to edit in the Expression Editor". Usually, when I click on the shape, it's easy to see what the trouble is.

However, there are times when clicking on the shape doesn't show anything that looks incorrect. If that wasn't strange enough, there are times when the orchestration will compile even though it shows the error in the orchestration designer. And stranger still is something that I just noticed -- when I took out a send shape immediately following the Expression shape, the orchestration would no longer compile.

I have found 3 possible causes. This isn't intended to be an exhaustive list:
  • This seems to occur most often when I try to wrap a string onto more than one line by using the "+" operator.
  • In the orchestration view, one of the items will show an error. This should be pretty easy to fix from the orchestration view.
  • Variables with identical names are declared in more than one scope. I'm not sure why this is a problem, but it does seem to be sometimes.
Another similar (vague) error that shows up sometimes during compilation is "errors exist for one or more children". One of the causes of this error is this code that is used to obtain the GUID of the currently running orchestration:

orchName = Microsoft.XLANGs.Core.Service.RootService.ServiceId

Thanks to Scott Colestock for pointing this out. He suggests using the following code instead:

YourOrchName(Microsoft.XLANGs.BaseTypes.InstanceId)

Thursday, February 01, 2007

Where Are Those Darned R2 EDI Schemas

For some reason, I keep forgetting this...BizTalk R2 EDI schemas are kept in an executable ZIP file (EXE extension) at C:\Program Files\Microsoft BizTalk Server 2006\XSD_Schema\EDIMicrosoftEdiXSDTemplates.exe.

By the way, the new BizTalk EDI support in R2 is way better than in previous versions. They have schemas for every X12 EDI document I could want, plus lots more. There's also support for EDIFACT, which I haven't had the privilege of using yet...

Setting up the EDI transactions is also much easier. Actually, there are some transactions that I never was able to set up using the old EDI system.

To compare the old EDI system to the new, it took me less than 1/2 the time to set up a real life outbound 810 transaction. Not bad.

Tuesday, January 30, 2007

Note About BizTalk xpath Function

I just wanted to archive some sample code here...I've used the xpath function in BizTalk orchestrations fairly often, but it always takes me a couple of tries to get it right.

Here's a snippet that I have used successfully to assign a value to a field in an EDI 810 document:

n104Path = "/*[local-name()='X12_00401_810']" +
"/*[local-name()='N1Loop1'][3]" +
"/*[local-name()='N1']/*[local-name()='N104']";
xpath(Edi810, n104Path) = Response.myField;


Here's another that I have used to extract the value from the same field in an EDI 810 document (there's a difference in the xpath expression, here I'm using the XPath string() function):

// check n104 element (under "ship to")
n104Path = "string(/*[local-name()='X12_00401_810']" +
"/*[local-name()='N1Loop1'][3]" +
"/*[local-name()='N1']/*[local-name()='N104'])";
n104String = (System.String)xpath(Edi810,n104Path);
n104String = n104String.Trim();


I have seen examples that look like the following, but when I try them the string value is just null:

n104Path = "/*[local-name()='X12_00401_810']" +
"/*[local-name()='N1Loop1'][3]" +
"/*[local-name()='N1']/*[local-name()='N104']/text()";

Saturday, September 09, 2006

I found 2 links that I want to keep here, for my future reference. If someone else uses them, I ask that they deposit $10,000 in my swiss bank account...(doesn't hurt to ask, right)?

The first one, from David Hurtado's blog, shows how to promote context properties within an orchestration. It also has a link to Jon Flander's blog to show how to do this in a pipeline component (which I believe you could now use inside an orchestration with BizTalk 2006).

The second link is to Jan Eliasen's blog. I've been tearing my hair out because for most of DTD's that I get from customers, when I import them into Visual Studio and use the schema editor, all of the nodes show up at the top level. Jan showed me how to get the schema to show up in VS in a clean, heirarchical way.

Friday, March 03, 2006

BizTalk Pipelines Factoid

I'm sitting in the BizTalk 2006 Deep Dive training in Redmond right now, and the instructor told me some stuff that I don't remember seeing elsewhere. So I'm going to document this for myself and others.

The provided XMLTransmit pipeline will ensure that an incoming document is well formed XML, but it won't validate the document against a schema. In order to validate against a schema, you need to create a pipeline and do one of two things:

  • Drop an XML disassembler component into the pipeline, set the "Validate document structure" property to false, and then drop an XML validator component as well. This will validate the XML document against any schema that is deployed to your host.
  • Drop only an XML disassembler into the pipeline, set the "Validate document structure" property to true, and then add one or more schemas to the "Document schemas" property.

Note that if you use the XML validator component as desribed above, you don't have to specify a schema. However, if you do specify a schema (or schemas) in this component, the pipeline will then validate only against that specific schema (or schemas).

If you do choose to use a port to validate according to a schema, BizTalk 2006 will make it easier. In BTS 2006, pipelines support parameters, and you can override the schema(s) that are used.

BTW, I'm using the word "factoid" in the title because I figure if functoid is a word, than factoid must also be.