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.
Related
With my team, we are trying to set up an error handling policy common to several microservices (for the majority of cases). My team and I are struggling to understand the difference between a listener-level error handler and a container-level error handler. What are the real implications behind this choice? Is it only the fact that the container error handler does not have access to the message?
The KafkaListenerErrorHandler allows a more fine grained exception handling, we can use on the content of the exception to define if it is retryable or not.
In the error handler containers it seems more complicated, before it was possible to provide a custom classifier but not anymore, we can only pass a classification map.
In the past we used to use the SeekToCurrentErrorHandler (now DefaultErrorHandler), which was recommended in the documentation. I saw another StackOverflow thread related to this topic but I can't quite make the connection with our questions. The documentation doesn't seem to address the implications of this choice.
Thank you very much.
The main use case for the listener-level error handler is for request/reply processing; it allows the error handler to send some other result to the sender to indicate the request wasn't processed. As you say, it also provides access to the spring-messaging converted Message<?> (possibly with a converted payload); e.g. for logging; it can re-throw the exception to invoke the container EH.
Regarding classification, that change was to allow classifications to be added and removed dynamically. If you prefer to have the old behavior (allowing a custom classifier) to be restored, please open an issue on GitHub.
Are there any mechanisms in Rebus to deal with messages that would normally be handled by a saga but for which there is no current saga that matches the correlation property? Out of the box, I believe those messages are just consumed by Rebus but there is no visibility as to what happens with them.
i.e. NServiceBus has the IHandleSagaNotFound to allow endpoints to deal with this scenario
Unfortunately there's no way to handle that right now. As you've probably found out, a message is simply logged that Rebus could not find an existing saga data instance for the incoming message.
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)
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.
How can I call a BizTalk Orchestration dynamically knowing the Orchestration name?
The call Orchestration shapes need to know the name and parameters of Orchestrations at design time. I've tried using 'call' XLang keyword but it also required Orchestration name as Design Time like in expression shape, we can write as
call BizTalkApplication1.Orchestration1(param1,param2);
I'm looking for some way to specify calling orchestration name, coming from the incoming message or from SSO config store.
EDIT: I'musing BizTalk 2006 R1 (ESB Guidance is for R2 and I didn't get how it could solve my problem)
The way I've accomplished something similar in the past is by using direct binding ports in the orchestrations and letting the MsgBox do the dirty work for me. Basically, it goes something like this:
Make the callable orchestrations use a direct-bound port attached to your activating receive shape.
Set up a filter expression on your activating receive shape with a custom context-based property and set it equal to a value that uniquely identifies the orchestration (such as the orchestration name or whatever)
In the calling orchestration, create the message you'll want to use to fire the new orchestration. In that message, set your custom context property to the value that matches the filter used in the specific orchestration you want to fire.
Send the message through a direct-bound send port so that it gets sent to the MsgBox directly and the Pub/Sub mechanisms in BizTalk will take care of the rest.
One thing to watch out in step 4: To have this work correctly, you will need to create a new Correlation Set type that includes your custom context property, and then make sure that the direct-bound send port "follows" the correlation set on the send. Otherwise, the custom property will only be written (and not promoted) to the msg context and the routing will fail.
Hope this helps!
Look at ESB Guidance (www.codeplex.com/esb) This package provides the functionality you are looking for