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.
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(
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