Biztalk series (30) one-way port for request-Response

Biztalk is essentially an asynchronous message processing engine. The request and response modes of BizTalk are based on asynchronous synchronous message exchange. The message engine connects many asynchronous messages through the extended message architecture, and the relevant sets of messages are associated with request and response messages. For example, a client sends a SOAP request to the BizTalk soap adapter. The BizTalk orchestration that connects to the Web service to receive and process messages. And return a soap Response Message. The client program is a synchronous SOAP request. However, in the engine, many asynchronous messages are exchanged in parallel.

The five architecture attributes in request-response mode are as follows:

• BTS. correlationtoken allows the response message to be routed to the request-Response port.
• BTS. epmrrcorrelationtoken is used by the internal message engine to specify the server name, processing id, and unique guid of the request-Response Message stream.
• BTS. isrequestresponse specifies whether it is a request-Response Message.
• BTS. reqresptransmitpipelineid
• BTS. routedirecttotp is used by the internal message engine to allow cyclic callback of request-response messages.

　 　

Based on the above introduction, we have learned about the switching principle of Bidirectional ports (request-response mode) in BizTalk. Our idea is to implement bidirectional port functions through unidirectional ports, in theory, it is roughly like this: create a one-way port to receive requests from web service, subscribe to messages through message attributes in orchestration, and process messages after orchestration receives messages, for example, create an identical message (copy the corresponding attribute) and modify the value of the corresponding field. The new message is published to the MessageBox by sending the form and the relevant set is initialized. The message engine returns the message to the request and Response port based on the relevant set settings of the message.

It is a flowchart created based on theoretical analysis. The flowchart is very simple. The receiving and sending ports use the direct port type receive receiving shape and use filter to subscribe messages from MessageBox. The send form is to publish a message to MessageBox.

　　　

 

The expression statement in the construct new message shape is as follows: create a message and specify the value of the relevant set.

System. Diagnostics. EventLog. writeentry ("twowaydemo", "begin Process ");
Outmsg = inmsg;
Outmsg (*) = inmsg (*);

Outmsg. Body. Field = "[email protected]";
Outmsg. header. State = "completed ";
Outmsg (BTS. routedirecttotp) = true;
System. Diagnostics. EventLog. writeentry ("twowaydemo", "completed process ");

 

After the BizTalk project is deployed, you must publish the schema as a web service. create a receiving port in the BizTalk application. Because orchestration subscribes to messages through attributes, XML receive pipeline must be used in the soap receiving location. Finally, we can test the Web service through soapui to see that our SOAP request has been successfully processed by Orchestration and the processing result is returned.

 

Summary

The above simple demo involves a lot of BizTalk related knowledge, such as the publishing/subscription mechanism, related sets, and the use of soap adapters. However, I believe that the understanding of the BizTalk architecture is a great leap. Finally, one point here refers to the one-way port in orchestration. The port published by Web Service is bidirectional.

 

References

Microsoft Biztalk 2006 R2 documentation

ESB guidance documentation

Biztalk series (30) one-way port for request-Response