BizTalk xs:date promotion shows inconsistency?

I think I may have found an inconsistency with BizTalk promotion mechanism.


Context

The system is using – roughly – two orchestration super-types:

  • The ones that are publishing business data from external sources to the enterprise data warehouse, and
  • The ones that are subscribing to (wait for) events on the bus and provide data to other enterprise systems for day to day operations.


One of the responsibilities of publisher super-type orchestrations is to notify subscriber super-type orchestrations when data is available in the warehouse. Publishers and subscribers do not know each others (no call/send shape or partner ports are allowed). This loosely-coupling behavior is supported with event messages that travel through the message box. Publishers creates the event messages for subscribes in this disconnected mode. Event messages have the same message type and only its inner element values would reveal which concept of data is available.


Subscribers may have to subscribe to many events. They can set the subscription filter with:

  • An event id that defines which concept of data is now available;
  • An event sub-id to identify the sub-concept of the data, if any;
  • A date. The date associated with the data (not the creation date of the event itself). Subscriber instances have their logic subject to the date.

These three (3) context properties are MessageDataPropertiesBase properties.

Some of these events can be published on the message box receive ports directly.


Problem

Subscribers failed to subscribe to the event message. The date promotion is inconsistent with

  • The format of the date as seen in the message content;
  • The W3C format of a date (which is based on iso8601), and
  • Promotion from a pipeline versus promotion from an orchestration.


The event schema is :

Where element type of date is xs:date. The date element has an associated promotion.

The property schema is:

Where the element type of date is xs:date. The date field of the event schema is associated with the date property of the property schema.


Examples


Scenario One: Promotion from a XML Receive pipeline


An xml instance of event schema is injected in a filedrop location. The xml instance is:

The context properties after the port processing are (as retrieved from HAT):

The pipeline has promoted a date value of "9/30/2008". This date format – m/d/yyyy – does not follow the format of a w3c xml schema date. However the distinguished field associated with the date element is identical to the message content:

Note that the date format "9/30/2008" is not the format specified by the regional settings of the account running the host instance. The regional settings is English(Canada) which has these properties. The date format is dd/MM/yyyy:



Scenario Two: Promotion from an orchestration

An orchestration creates an instance of an event and published the message by direct binding in the message box. The orcherstration is:

The MessageAssignement shape code is:

Then, the xml instance created is by the orchestration is:

and the context properties (as retrieved from HAT):

The value promoted for the date field – 10/1/2008 4:00:00 AM – has a format different from the pipeline promotion. This value has a timezone stamp appended to the date. The local timezone (Eastern Canada DST is -4:00:00). If fact, I do not understand the timezone value appended to the date value.


Scenario Three: do not trust HAT and test the correlation with a sequential convoy

The promoted properties are different from a pipeline and an orchestration. But could it be due to a HAT transformation? I tried different correlation scenarios with this sequential convoy orchestration:

The receive shape "Receive_1" initiate a correlation set. The correlation type contains only the PropSchema.date field.

An xml instance of an event was either published from a pipeline or from an orchestration.

The results are :


first event

from pipeline

first event

from orchestration

second event from pipeline

correlation successful

NO correlation

second event from orchestration

NO correlation

correlation successful



Finally: Questions

How BizTalk Server handles xs:date type for promotion fields?

Why the date format is not following w3c recommendation?

Why is it different from a pipeline vs an orchestration?

To have a format consistency, is there any workaround other than using xs:string type for promotion fields when it comes to a date value?


Then: Answers

Not found yet so stay tune.

Comments

Popular posts from this blog

IList Serialization with XmlSerializer. Good thing to know.

The Toyota Way