Wednesday, August 24, 2005

"Call" Orchestration and Dynamic Ports

In my present project there came a requirement to create a "common orchestration" that would take the "response" XML from PSFT and apply business rules. This "common orchestration" should work with all present Orchestrations that are already on production. This Orchestration has to be very flexible and accommodate the various possible parameters from Main orchestration.

This "Common Orchestration" is just like any another orchestration but will have NO "Receive" shapes. I used an "Request-Response" "dynamic" port that will read PSFT HTTP gateway address from REGISTRY KEY. The two-way dynamic port will receive status XML from PSFT and analyze the node for "success" and "failure". If it is a failure then the "Main Orchestration" will go in suspended mode but "resumable". Once the error is fixed, manual intervention will be required to send the message again by resuming it using HAT. An error message will be generated in the event viewer so the Production support people can be informed.

Main Orchestration will call this "Common Orchestration" using "Call Shape" and pass the parameters.

I used the following code for the dynamic port: PortName(Microsoft.XLANGs.BaseTypes.Address) = getmethodURL()

Friday, August 19, 2005

Interesting Observation regarding HTTP adapter receive codes

I had an interesting discussion with my co worker. The ASP.Net page I deigned to pass XML through HTTP POST to Biztalk was returning code "200" for succesful submission. The discussion rotated around the fact that this code is being send by webserver or Biztalk. According to MSFT website, code 202 is returned by one-way receive port and code 200 is returned by Http "Request-Response" port. Since we are using one way port, we should be getting a 202 message from Biztalk if any. But we are getting 200. I also read somewhere that Biztalk looks for 200 message from webserver before it starts processing files. This lead me to believe that 200 is infact sent my webserver. But, I am not entirely convinced by it.

Friday, August 12, 2005

Biztalk Macros for FileNames

I want to thank Jan Tielen for the following formats:

%datetime%:Coordinated Universal Time (UTC) date time in the format YYYY-MM-DDThhmmss (for example, 1997-07-12T103508).

%datetime_bts2000%: UTC date time in the format YYYYMMDDhhmmsss, where sss means seconds and milliseconds (for example, 199707121035234 means 1997/07/12, 10:35:23 and 400 milliseconds).

%datetime.tz%:Local date time plus time zone from GMT in the format YYYY-MM-DDThhmmssTZD, (for example, 1997-07-12T103508+800).

%DestinationParty%:Name of the destination party. The value comes from message the context property BTS.DestinationParty.

%DestinationPartyID%:Identifier of the destination party (GUID). The value comes from the message context property BTS.DestinationPartyID.

%DestinationPartyQualifier%:Qualifier of the destination party. The value comes from the message context property BTS.DestinationPartyQualifier.

%MessageID%:Globally unique identifier (GUID) of the message in BizTalk Server. The value comes directly from the message context property BTS.MessageID.

%SourceFileName%:Name of the file from where the File adapter read the message. The file name includes extension and excludes the file path, for example, foo.xml. When substituting this property, the File adapter extracts the file name from the absolute file path stored in the FILE.ReceivedFileName context property. If the context property does not have a value, for example, if message was received on an adapter other than File adapter, then the macro will not be substituted and will remain in the file name as is (for example, C:\Drop\%SourceFileName%).

%SourceParty%:Name of the source party from which the File adapter received the message.

%SourcePartyID%:Identifier of the source party (GUID). The value comes from the message context property BTS.SourcePartyID.

%SourcePartyQualifier%:Qualifier of the source party from which the File adapter received the message.

%time%:UTC time in the format hhmmss.

%time.tz;%Local time plus time zone from GMT in the format hhmmssTZD (for example, 124525+530).

Sunday, August 07, 2005

ASP.Net issue

In my present project, I had to create an ASP.Net page to receive XML documents and pass it do biztalk on basis of Query string: This is what I found out.

1) Ensure that the "Virtual Directory" in IIS where the ASPX is located is configured for Execute permissions for "Scripts and Executibles"

2) Unlike ASP page where we use "server" object, ASP.Net takes the incoming XML as "stream". Be very careful in converting the stream to array and then to string. Make sure that the stream is "encoded" while its being received by ASPX and "decoded" while it is being sent by ASPX page to Biztalk.

3) I have seen some sample code on various website using ASCII encoding. I had lots of problems with it and after wasting several hours I found out that "UTF-8" encoding is the one that does the trick.

4) Last and not the least: Do not forget to restart the IIS (Run Command "iisreset") when you get 500 errror.