What is the recommended way to split messages in send pipelines? - biztalk

I need to split a bizTalk message in the send pipeline. This is easy with disassemblers in receive pipelines, but doesn't work in send pipelines (makes sense).
So what is the recommended way to do it? The only easy way to do it is to write the outbound message to file, then reprocess it using a receive pipeline with a disassembler, and then send the generated messages through a outbound pipeline. Honestly, I don't need the additional roundtrip through the message box, but I don't want to create a custom send adapter.
Any other suggestions? Any easy way to save messages with multiple parts using the ootb file adapter?

While your solution is probably the best approach for this, you can also think about splitting the message inside of an orchestration (not the best practice) before the message even hits the send pipeline. The send pipeline is obviously designed for composition of messages and not decomposition so I would stay away from any custom code to handle this.
Here's a good article on debatching messages.

Why don't you use receive pipeline to split the messages at the first place. Anyways your solution uses receive pipeline. You don't want to write outbound message to file system and process it using receive pipeline again.

Related

Microservice to Microservice Architecure using gRPC : .NET Core

So I've this Microservice architecture where there is an ApiGateway, 2 microservices i.e., Configurations. API and API-1. The Configuration. API is mainly responsible to parse the JSON request and
access the DB and update Status tables, also to fetch required data, it even adds up more values to the JSON request and send it to the API-1. API-1 is responsible to just generate report based on the json passed.
Yes I can merge the configurations. API to the API-1 and make it a single service/container but the requirement is not to merge and create two different components i.e., 1 component purely based on
fetching the data, updating the status while the other just to generate the reports.
So here are some questions:
: Should I use gRPC for the configuration.API or is there a better way to achieve this.
Thank you.
RPC is a synchronous communication so you have to come up with strong reason to use it in service to service communication. it brings the fast and performant communication on the table but also coupling to the services. if you insist use rpc it is better to use MASSTRANSIT to implement the rpc in less coupled way. however in most cases the asynchronous event-base communication is recommended to avoid coupling (in that case look at CAP theory, SAGA, circuit breaker ).
since you said
but the requirement is not to merege and create two different
components
and that is your reason and also base on the fact
also to fetch requried data, it even adds up more values to the JSON
request and send it to the API-1
i think the second one makes scenes more. how ever i cant understand why you change the database position since you said the configuration service is responsible for that.
if your report service needs request huge data to generate report you have to think about the design. there is no more profile on you domain so there cannot be an absolute answer to this. but consider data reduce from insertion or request or some sort of pre-calculation if you could and also caching responses.

Biztalk multiple continuous calls to webservices

Here is the problem:
Biztalk application should get data from webservice into two steps:
1.Request list of changed clients GetChangedClients(date) and receive list in format:
<clients>
<client id='C1'>
<client id='C2'>
....
<client id='CN'>
</clients>
2.After receiving list of clients Biztalk will issue one call per client like
getChanges("C1")
getChanges("C2")
....
getChanges("CN")
3.After changes messages received they will be passed to WCF-port.
Question:
What would be the best way to build this into biztalk
(building orchestration with a loop, call component to create multiple messages with clientid, create custom adapter ) ?
I think that the scatter-gatherer pattern would work well for this. In your orchestration split the clients xml document into individual client messages, then publish these to a orchestration that handles them along with a correlation token. The orchestration that does the individual calls and sends the response back to the controlling orchestration. An example can be found at http://www.richardhallgren.com/a-loosely-coupled-scatter-and-gather-implementation-in-biztalk-2006/
Another place for an example of this is at http://blogs.msdn.com/b/cvidotto/archive/2006/12/18/biztalk-server-2006-code-samples-awesome.aspx. Search for Implementing Scatter and Gather Pattern.
One of the simplest way to this, is to use Partner Direct Ports in BizTalk.

Is Biztalk 2010 Receive Shape Filter configurable

I am currently writing an orchestration that is directly bound to the message box, picks up messages and filters according to the filter expression in the receive shape inside said orchestration. The problem I'm having is this; I want to be able to change the filter in the BizTalk bindings, just like send filters are changed in the bindings. Really, I just don't want to have to recompile and re deploy every time My filter changes. Is there a way to do this? I'm thinking maybe modify the binding.xml file somehow, or possibly try a custom pipeline with configurable properties(as my last resort).
If it matters I typically use the BizTalk Deployment Framework for deployments.
No, it is not possible to modify a Receive Shape Filter at Runtime.
If the filter needs to be dynamic, then you will have to apply that logic upstream. The idea of using a custom Pipeline Component is a common solution.
One other approach to consider is leaving you Receive Shape Filter broad and testing each incoming message with the BRE. If it 'passes', continue processing, otherwise exit. BRE Policies/Rules can be updated at runtime.
For this sort of thing you will probably want to execute Business Rules in the Receive Pipeline that then sets a context property on the message that then determines the routing.
That way the filter in the Orchestration is lightweight and doesn't need to be changed.
See http://brepipelineframework.codeplex.com/ (Disclosure: This is written by a colleague of mine)

Validating messages in an orchestration, or receive port

I've been working under the assumption that a message entering an orchestration was validated against the messages schema, only to realize recently that this is not the case. There doesn't appear to be a validate shape, so I'm wondering if there is a clean reusable pattern out there to implement this?
You can validate the messages on an XMLReceive pipeline, but unfortunately this requires specifying the DocumentSpecNames which can detract from the flexibility of the receive.
A workaround is to use a custom "ValidatingXmlPipeline" and add the XMLValidator pipeline component to it.
As per your original question, there is a config setting in btsntsvc.config under Debugging called ValidateSchemas when message variables are assigned. I can't say I've used this as it will probably impact performance.

Biztalk, need to consume a web service

What I need to do to send a request and to receive answer from the Web Service that I want to consume.
What i have done:
I have done the "add web Reference"
I added a Send Shape and a Receive Shape and a I configured a port that sent and received with web Type, the port binding Specify later and I connect with the Request and response to the Send and Receive shape.
I believe I am missing something ?
From your description I am guessing you might be missing -
A definition of the request and
response messages; you need to
ensure you have a request and
response message defined, with their
types being the generated web types.
Select the correct message for both
the send and receive shape. send
shape uses the request message,
receive shape uses the response
message.
Construct the request message using a construct and a transform or assignment shape before the send shape. the easiest way to get started is to use a map in a transform shape to create the request from whatever message triggered your process, but the exact implementation detail will, of course, depend on your scenario
This should be enough to call the service I would have thought
There are many blog posts on the subject, here's one I found with a quick search that shows all the pieces needed
I'm currently working my way through a project using Biztalk to consume a web service. I think you may have a error when compiling similar to :
"Use of unreconstructed message"
If this is the problem, add a construct message shape to the orchestration before the send to the web service port.
I'm stuck with creating the message syntax but this should get you moving.

Resources