Share via

What do I do if I did not get the Leap Year Fix installed in time?

  • Article

Although the fix has been avaialble for quite some time and also pushed through Microsoft Upodate, there could still be many customers who are unpatched and already experiencing the problem. 

BizTalk support and product teams have investigated into the possible impact of the issue and remedial measures. The escalation engineering team has put together an excellent FAQ explaining all of these in detail. I encourage you to please go through this before calling for support.

Here is an extract from the FAQ for customers who have not been able to apply the fix yet as of 2/29/2012:

--------------

Unfortunately, it depends. What you will see are suspended receive or send pipelines. 
You may see failed orchestrations if they were somehow dependent on the failed pipeline. 

 For a send pipeline, it will be suspended (resumable) and you can simply resume the instance after updating the machine to have the Leap Year Fix installed.

 A receive pipeline instance will be suspended (resumable) but resuming them will just result in the following error:

 EventType: Error

Event Source: BizTalk Server 2006

Event ID: 5719

There was a failure executing the receive pipeline:
"Microsoft.BizTalk.Edi.DefaultPipelines.EdiReceive,
Microsoft.BizTalk.Edi.EdiPipelines, Version=3.0.1.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35" Source: "EDI disassembler"
Receive Port: "<RP>" URI: "<URI>" Reason: No
Disassemble stage components can recognize the data.

The reason is that the failed instance has already converted the EDI message to XML (since the datatype validation happens after conversion) and resuming just hands this XML back to the pipeline and the EDI Disassembler component does not recognize XML data. 

In the case of a single EDI file that uses interchange splitting to split into multiple XML messages, you will have a suspended instance for each split message (since datatype
validation also happens after splitting) and again resuming will fail since EDI Disassembler will not recognize the XML data.

In order to successfully resume the instance, you will need to change the pipeline used by the receive port to a pipeline that can handle the XML data. That would be the passthrough pipeline, XML pipeline, or a custom pipeline. The message context properties will be preserved but be aware that EDI context
properties will no longer be promoted. This means that although the context properties will be available from an orchestration if you do
routing based on EDI-specific context, they will fail because they require promoted context properties. The list of properties that will still be
promoted even after resume are as follows:

  •  BTS.MessageType
  • BTS.ReceivePortName
  • BTS.InboundTransportType
  • BTS.InboundTransportLocation
  • BTS.ReceivePortID
  • BTS.LastInterchangeMessage

 There may be a few additional promoted properties for custom pipelines or specific adapters. Since BTS.MessageType is still promoted, you will still be able to route based on the type of EDI document - but the main thing to notice is that none of the actual EDI context properties are promoted. In order to have them promoted, you must create a custom pipeline that will promote the EDI properties that you use for routing and use that pipeline when resuming.

----------

Thanks

Guru

Comments

  • Anonymous
    March 01, 2012
    How do I rollback this fix?  We think it's causing duplication problems in biztalk.Thank you,JH