Thursday, May 27, 2004
Ok, it looks like Scott Woodgate has released details about the WSE Adapter for BizTalk beta program over on his blog here.
The WSE Adapter has a dependency on the WSE 2.0 release that has just recently been made available on the MSDN site.
Although this isn't strictly related to BizTalk (watch this space though!), it's a significant release with regards to security in web services (WS-Security is implemented to the OASIS 2004 standard) and a little thing called SOAP Messaging.
SOAP Messaging allows us to move closer to the SOA goal of defining web services that can be asynchronous, loosely coupled and interact using XML based messaging; rather than RPC over HTTP (current .NET web services implementation). Ok, I know that RPC over HTTP is effectively SOAP-RPC and is implemented as an XML message, but there is an important difference there. SOAP-RPC defines a format(s) for representing a method call, its parameters and their datatypes. SOAP Messaging is more lightweight in that the body of the SOAP message is simply an XML document that can be anything - say, an invoice. There is no SOAP-RPC encoding involved. In an SOA world, the XML messages are defined using schema and the behaviour of the web service as contract, and WSE 2.0 gets us on that road.
Therefore, in my view, WSE 2.0 becomes quite a powerful platform for building web services today in anticipation of Indigo and the nirvana of an SOA future...
Thursday, May 13, 2004
Just looking at the BizTalk help file (the latest) and was quite interested in how persistence was handled in orchestration in 2004. In 2002 a small change was made (over 2000) to make the persistence of state more efficient by allowing the persistence to be dropped at the start of a transaction. In 2004, it seems the persistence of orchestration state is better thought out with regard to resiliency of an orchestration.
It's one of those things that you know happens, but you're never quite sure exactly in what situations orchestration state is saved to the message box.
Thankfully, the latest BizTalk Server 2004 help addresses this, and can be found here. This is well worth a read if you're like me and want to know a little bit more about what happens under the covers.
Well, this was a little gem that was pointed out to me by a buddy from Microsoft UK who said that surely this little snippet of information was worth a drive in my new car!
Well, I'm not so sure, but it's useful nonetheless ;-)
So, onto the topic in hand. A documented feature of Send Ports in Orchestrations is that it is possible for an acknowledgement to be returned to the running orchestration when a message has been transmitted to its destination. It's often been the case (in previous versions) that it would be useful to know when a message has been transmitted, and if there is a transmission failure and the message goes into the suspend queue, then to be able to take corrective action in the orchestration. With Delivery Notifications it is possible to do that!
How does it work?
Well, when this option has been switched on, a context property called BTS.AckRequired is set that informs the adapter that a transmission acknowledgement is required. Once the message has been transmitted successfully an 'ack' is returned that the engine uses to progress the orchestration. If the message fails to be transmitted (after the retry count has been exhausted), then a 'nack' is returned instead. If a nack is received by the orchestration engine, then a DeliveryFailureException is thrown that can be caught in the orchestration using an Exception Block Handler in an enclosing non-atomic scope. The non-atomic enclosing scope is not exited until a ack/nack is received - which makes this very useful as the orchestration won't continue and will just block. The documentation states that an atomic scope is required for the send shape although I have found that it also seems to work in a non-atomic scope as well.
How do I do it?
In orchestration, perform the following steps to delivery notification heaven:
- Set up a port that is used to send messages.
- Look at the port properties, and set the Delivery Notification property to Transmitted.
- Create a non-atomic scope shape with the transaction type set to Long Running.
- Add an exception handler block to the scope to catch exceptions of type DeliveryFailureException.
- Add a send shape inside the scope and hook it up to the port.
Don't forget that the non-atomic scope (or the orchestration if no scope is specified) will not complete until either an ack or a nack is received. Very useful for running some sort of corrective action in case of transmission failure. Also, I've not tried, but I wonder if, rather than putting the corrective logic in the exception block, whether the succeeded() XLANG/s expression could be used to test if the scope had failed, and then perform corrective action but in the main flow of the orchestration. Sounds feasible I guess...
Tuesday, May 04, 2004
I received a comment from Scott Colestock (thanks Scott!) on the blog entry to do with multiple schemas with the same root name and namespace, and then BizTalk failing at runtime because 2 schemas exist.
Basically, another workaround to the problem is to ensure that you use a custom pipeline that uses the XML Disassembler or Assembler (depending on which way you're going!) that specifies exactly what schema to use to resolve the message name.Scott's article which covers this in detail can be found here.
Thanks again Scott :-)
The following knowledge base article on the Microsoft website lists the operating systems that are supported by the FTP adapter for sending and receiving files.
Click here for the article.