Monday, May 19, 2008

SOA and ESB Architecture with BizTalk

Searching info about ESB Guidance, I found a recent little book (25 pages) by Robert V. Hogg & Ewan Fairweather, that seems to be very interesting.

This is the link http://www.wrox.com/WileyCDA/WroxTitle/productCd-047027011X.html.

BizTalk Accelerator for SWIFT 2008 Message Pack

BizTalk Server Team have launched Evaluation Program of BizTalk Accelerator for SWIFT 2008 Message Pack to test the next release of this product. BizTalk Accelerator for SWIFT 2008 Message Pack will provide compliance with SWIFT 2008 Standards Release Guide (SRG) specification.

The planned release schedule is:

- June 23, 2008 -> CTP
- July 21, 2008 -> Beta
- September 5, 2008 -> RTW

The 2008 Message Pack will include:

- Complete re-packaging of all SWIFT FIN Flat File message types and business rules.
- Updates to all message schemas and business rules for compliance with SWIFT 2008 Certification requirements.
- Roll-up of all schemas and business rule Hot fixes not superseded by 2008 requirements.
- Validation of SWIFT Reference data as a business rule rather than a schema

Friday, May 09, 2008

Endless XmlDisassembler

This is a curious behaviour of XmlDisassembler component. My problem was that I have developed a custom XmlDisassembler, that inside uses BizTalk XmlDisassembler component (Microsoft.BizTalk.Component.XmlDasmComp).

My component disassembles the message with the BizTalk component and discard some of the returned messages, based on some conditions. The problem is when I call XmlDasmComp's GetNext method, never ends.

Why? The problem is that in my conditions to discard the returned messages, I don't need to read the returned message. Inside the XmlDasmComp, in GetNext2 private method, it test a property 'IsNewDoc' to retrieve a new message or not. This property is updated only when we read the returned message.

Why this property is updated only when we read the returned message? Obvious, in BizTalk standard behaviour, it always read the returned message before to call GetNext method other time.

Standard behaviour in a BizTalk disassemble is:

1) XmlDasmComp.Disassemble
2) XmlDasmComp.GetNext (First Message)
3) Validate and ResolvePartyComponents (this components can read the message)
4) Receive Pipeline ends, then BizTalk READ THE MESSAGE
5) XmlDasmComp.GetNext (Second Message)
...
Until GetNext method returns a null message.

In my component, I was calling GetNext method continuosly without reading the message, so 'IsNewDoc' never was updated and GetNext method never ends.

Solution is, after calling GetNext method, I read the message and then I seek to the begin the message (If no, the internal Stream is in the last position and next components couldn't read it)

Thursday, May 08, 2008

Deploy Orchestrations: "Failed to update binding information"

Yesterday, I was redeploying an orchestration through BizTalk MMC -> MyApplication -> Add -> BizTalk Assemblies... with "Overwrite all" checked, when I received this error:



The detail error said that "Receive Location 'Receive Location MQ por FILE' has no Transport type specified.". I was confused, because Receive Location 'Receive Location MQ por FILE' didn't exists, it was a Receive Location that I have deleted weeks ago.

Searching for BindingInfo inside my computer, I discovered that BizTalk stores info about the last deployments in C:\Documents and Settings\[user name]\Application Data\Microsoft\BizTalk Server\Deployment\BindingFiles (over Vista in C:\Users\[user name]\AppData\Roaming\Microsoft\BizTalk Server\Deployment\BindingFiles).

When you do a redeployment, BizTalk uses this information. If this information is erroneous, we get this error "Failed to update binding information".

Solution is easy, remove the info binding file and we can redeploy our orchestration.