In this post we will examine some of the techniques used to build the Payment Upload process. You will see transactions, debraching messages, streaming and using XLANGMessages.
In the previous post we saw the main bill upload process. What I left out was the process that handles failed message routing.
The Famous Failed Routing Error
In the previous post, I showed you how correlation is vital for the correct operation of a business process. However, this correlation – being based on matching field values – is subject to failure.
For example, in our process, say that the bank sent the Bill Confirmation Rq, with a wrong AsyncRqUID. Using correlation BizTalk will try to route the message to running Ox instance but it won’t be able to do so.
In order to see this, drop a bill request message into the folder. Now while the process is waiting for the confirmation rq message, edit the asyncrqid. Now drop the message in the confirmation request folder. If you examine now the event log you will see the famous error: “The published message could not be routed because no subscribers were found”. This happened because BizTalk was not able to match the correlation and no other subscribers were found for the message.
This starts a series of articles about a BizTalk business process scenario. The entire solution can be downloaded from here:
The Scenario is a modification of a real business case for a payment gateway.
The gateways acts as a medium between vendors and banks:
In Summary, there are two types of transactions:
Atomic transactions, which take short time to execute (typically seconds). These transactions satisfy all ACID attributes, and thus need to acquire data locks on resource managers such as SQL Server. If all operations within a transaction scope succeed, then the transactions is committed automatically, else if any operation fails the entire transaction is rolled back. This is done via a transaction manager such as DTC.
Essential Guide to Certificates, Encryption, and Signatures
Integrated systems have to deal with tough challenges when it comes to secure messaging. If system A is sending a message to system B, this requires the implementation of important security measures. These can be summarized by:
- Authentication, where System B must authenticate System A before accepting its message
- Data Privacy, means that an intruder – should ever be able to peek into the message – must not be able to see sensitive data
- And Data Accuracy – or Integrity – which means that If an intruder intercepts the message and modifies it, this modification must be detected by System B
Secure messaging is achieved using public and private keys. These are numerical values that are mathematically linked. An organization generates these keys, it keeps the private key as its own secret, and distributes the public key to any organization that wants to do exchange secure messages. Because these keys are mathematically linked, data encrypted with the public key can only be decrypted by the private key.
I’m in the midst of a BizTalk project where we’re load testing our solution. Our receive adapters are WCF-based and therefore tuning WCF is a critical aspect of the overall solution performance. I have gone through the same tuning times before in every WCF project. But I always was lazy documenting the information and ended up looking up the bits and pieces time and time again to refresh my memory. Now I decided to document this information in a post for myself and others.
However, I will not simply write the keys to adjust and leave it there. I will explain the reason we adjust these keys and what they really mean. So bear with me and follow along.
This post is for two sets of readers: those who are new to Microsoft Business Rule Engine and are looking for a direct hands-on approach rather than going though the theory and architecture behind BRE (links for that at the Additional Resources section), and those who are familiar (but not experts) with the topic in general, and are looking to understand, in a practical manner, how to program with BRE and leverage some of its powerful offerings. Continue reading
When designing a BizTalk solution that involves WCF (which is most of the times), you need to carefully consider the exception handling mechanism. This requires understanding for both BizTalk Exception handling as well as WCF (and SOAF) faults.
This post explains the mechanisms to implement exception handling when you have a BizTalk process that both calls WCF services and when the process itself is exposed as a WCF service. Continue reading
A BizTalk message is any binary stream of data. It can be an XML Document, flat-file, .NET serialized class, or any other binary stream of data such as zip or pdf.
A BizTalk Message is represented by two different objects, depending on which part of BizTalk its being processed.
- In the Messaging Engine, all messages are represented by type IBaseMessage. Similarly, message parts are represented by IBaseMessagePart.
- So if you want to access a message and its parts within a pipeline, you will use the IBaseMessage and IBaseMessagePart types.
- Once inside an Orchestration, a message is represented by XLANGMessage.
- Also, once any message inside an Ox, its implicitly treated to be of type System.Xml.XmlDocument.
- This means that inside an Orchestration, you can cast any message to type XmlDocument,
- and you can represent any message whose type is unknown at design time, as XmlDocument. I will return to this when I discuss Typed and UnTyped messages.