I need to have two orchestrations that take the same input schema message from an HTTP Receive Port.
The orchestrations do different things.
I do not understand how can I call either an orchestration or the other one.
I have just a solution in my mind but I don't think it right.
I create two different receive location. One orchestration -> One receive location..
It looks like the correct solution. But create a receive location mean create a virtual folder in my http site on IIS that contains the BTSHTTPReceive.dll.
So my doubt is: If I have 20 orchestration with same input, should I create 20 virtual folder that contain the DLL?
It looks an horrible solution.
What is the correct way to solve my problem?
Is this a one-way or a two-way receive port/location?
In case of a one-way receive location, just promote properties and use basic content based routing (CBR) using publish/subcribe on your properties.
In case of a two-way receive location: which response will you be giving to your application?
Think of your orchestration as your web service. You need to take in the request and generate one response. How you deal with that request by forwarding it to N number of other orchestrations/applications is up to you, but publish/subscribe is built for this behavior.
Related
I have normal receive port using a WCF-Adapter for oracle that uses a polling query. Now the problem is that the receive port not only needs to run once the polling query has a hit, but also once per day, regardless of the polling-statement.
Is there a way to make it possible without creating the entire process again?
The cleanest way will be to use an additional receive location. So you will end up with one receive port that contains two receive locations, one for each query.
In the past I have done this with the WCF adapter when polling SQL Server. The use of two locations did require duplicating the schema, unfortunately, to account for the different namespaces. You will probably need two different (and essentially identical) schemas as well.
WCF-SQL polling locations require distinct InboundId values while WCF Oracle polling (as you have noted in the comments) requires different a PollingId for each receive location.
The ESB toolkit includes pipeline components to remove and add namespaces, if you need additional downstream applications work with only a single schema on the messages coming from both locations and/or do not also want to duplicate a BizTalk map.
Change your polling statement so that it has an OR CURRENT_TIME() BETWEEN ....
That way it will trigger at the time you want.
I have a receive port. It calls a stored procedure for transport, then the receive pipeline is just passthrureceive (I tried XMLReceive, but that caused many more issues). I have a send port that has the filter set so it picks up the type of the receive port. The send port has a map and send pipeline. The map maps the xml from the receive port to a flat file schema, and then sends it to it's location. THe send pipeline has a flat file assembler.
So the map never runs. I just get errors from the send pipeline saying it can't match the document. No it can't, because it wasn't mapped. I read that you need an XML Disassembler on the recieve pipeline of the receive location. I added that, and that just started destroying my messages. They just get turned into a blank message or just a " in the message. So the XML disassembler is clearly not working right. I'm not sure what to do at this point.
OK, I figured it out. I have to use the XML disassembler to make the map run. The reason it was erasing my messages is, well I don't know the reason, but when I set the schema to "elementFormDefault = Qualified", it worked. I'm not really sure what that did, as I really don't have a good understanding of the whole qualified message thing, but that was the problem for me.
There is a wizard in Visual Studio to help you create the schemas and bindings that you use to communicate with stored procedures. I guess you didn't use that? (Right click on the project, hit "Add", then "Add Generated Items", then "Consume Adapter Service")
I'm calling my stored procedure from an orchestration hooked to two way send/receive port. I'm using a custom WCF type port with XMLTransmit and XMLReceive for the pipelines. This seems to work fine. The caveat being it's always a bit fiddly getting WCF to work since there are so many options.
In order to map from one format to another on ports, you need to have MessageType promoted. In your case it can be accomplished by using XMLReceive on the receive pipeline.
i am new to servlet programming. i want to know that... is it possible to pass objects between two servlets residing on different application servers??? say two tomcat servers...
means what i want to do is:
[browser]--> [app server 1 performs some operation on data]--> [server 2 does some operation on data]
i am sure it is possible but can anyone tell me how??
Short of server clustering (which you don't want to get into at this point, trust me), the only way to do this is to send a redirect from the first server to the other, encoding the data you want to send on to the URL.
You can't pass the actual object, since the servlets are on different servers, so passing data is the best you'll be able to manage.
If you do fancy playing with Tomcat clustering, then this gives the facility of storing objects in the HTTP session which are replicated across all servers in the cluster. I'd definitely categorise this is as "advanced usage", though, and not something to get into if you're new to this stuff.
If they are on two different servers you might want to 'duplicate' the original HttpServletRequest that has been made to the first server/servlet. You can do that by opening URLConnection to the other server/servlet and copy data from the first one request to its outputStream.
I am not sure if I ask the right question, but this is the scenario I am trying to run:
Multiple files (XML and a few related files, "attachments") have to get into BizTalk as a single message. I have looked into existing adapters, and don't see that done with existing once. To be more accurate, files are taken from file system. Files are not found at the same time, but arrive one at a time, when order is not ensured. XML (content) file is the one that knows what attachments it has to have (what other files).
We are looking into BizTalk 2009 and I was wondering would be that responsibility of a custom Adaptor, or something else. And were I could look for samples.
Thanks.
It is probably possible to do what you want using a custom adapter, though I'd recommend against it. You can achieve what you require using orchestration.
What you are looking for is likey a convoy, or at the least some use of correlation.
In BizTalk a convoy is a messaging pattern (as opposed a BizTalk feature) that allows groups of messages to be processed by a single orchestration.
You essentially use correlation on a receive port to group messages together in either a parallel (what you probably want) or sequential fashion.
There is an article [here](http://msdn.microsoft.com/en-us/library/ms942189(BTS.10\).aspx) by Stephen W. Thomas about convoys (it is for BT 2004 but the concepts still hold) and there is a lot of additional information on the web and in books (Professional BizTalk server 2006 has a subsection on them)
Without more details on your scenario it is hard to know exactly how the convoy would be built but below are two approaches to look at (also, I've not had a chance to properly use BT2009 so there may be extended support for correlation scenarios that help you out).
Flexible Correlation
If you don't know anything about the files listed in the context XML you will probably need a pattern like the one described by Charles Young in this post.
Non-uniform sequential convoy
If you do have a little bit of info before hand one way might be as follows (basically a Non-uniform sequential convoy):
This makes the assumption that there is some way of linking all the files together so you can correlate them.
Create a single orchestration that subscribes to you inbound receive port (which contains the file receive location).
This orchestration will have a single activation receive shape that is set up for your content file.
Once the orchestration is started by a content file a second correlated receive shape starts picking up the messages that match that content file. (this second receive could possible be in a loop to allow for variable numbers of files)
You then pack them all together into a single outbound file of your design and send them out once the full number of files has been received.
Seems to me a better approach would be to implement the above requirements with a combination of a custom pipeline component and/or a custom adapter. I assume you do not really need to manipulate the incoming files - except for the content XML file - or that you couldn't since they are in binary format. This calls for a custom pipeline component.
What you can do is develop a custom BizTalk adapter to interact with the file system and to implement the listening and looping logic. Next you can develop a custom pipeline component to create a single BizTalk message perhaps with base64 data type in it for binary data. Additionally you could also promote messages right in this component to enable orchestration subscriptions.
Orchestrations are more suited for implementing business work-flow scenarios where the messages are already in XML format. This do not appear to be the case. In any case I think at the very least a custom pipeline component would be needed.
David's answer is the correct answer.
Even in cases where you don't know absolutely nothing about the contents of the expected attachments, surely you know their names and locations. Therefore you can use the Flexible Correlation linked to in david's answer like this:
The key to the solution is to correlate on the builtin BTS.ReceivedFileName property.
First, create a custom receive pipeline, with a custom pipeline component that promotes the BTS.ReceivedFileName context property of the received messages. This simple custom component is fairly easy to write but you can make it straightforward by using third-party frameworks such as, (shameless plug, here) my PipelineComponentBase class or the excellent BizTalk Server Pipeline Component Wizard.
Now for the easy part:
Attachments are received in a specific location, designated by its path on the filesystem.
Create a receive location that listens to an alternate location, used only to control when files are actually swallowed by BizTalk.
In your orchestration, create a correlation type with the BTS.ReceivedFileName property and a correlation set base on this correlation type.
When you want to receive binary attachments, send a dummy message with the BTS.ReceivedFileName context property set to the filename of the binary attachment but with the path matching the alternate location ; the one used by the receive location. Initialize the correlation on the send shape.
Use an expression shape to copy the binary file from its original location to the one used by the receive location.
Finally, use a receive shape bound to the receive port that contains the receive location whose custom receive pipeline will promote the BTS.ReceivedFileName property.
Notice that you actually need to send a message in order to initialize the correlation. It does not matter what message you send actually. What I'd do is send the message through a send pipeline that contains an empty pipeline component. That is a pipeline component that reads the message but return null (so that the message vanishes into thin air before it reaches the adapter). A more elaborate solution would be to use a null adapter. That is an adapter that reads the message but does not do anything about it.
These two solutions avoid having many files accumulate in a temporary location somewhere, just for the sake of initializing a correlation!
Can a message select between an 'older' or 'latest' version of the orchestration he'd like to be prosessed by ?
thanks
If you're talking about the version fo the DLL in the GAC, I don't think this is possible. But if you maintain two seperate Orchestrations, you can use a promoted property to route the message to the appropriate orchestration. If it's more complicated than that, you can have a single receiving orchestration for themessage type and it can call the appropriate orchestration based on whatever criteria you can code into it. This is still the send port groups deciding which messages they want to run. Another approach would be Dynamic Send Ports. This really gives you the freedom to move direction of the message into the orchestration/app itself.
The Microsoft ESB 2.0 Guidance has some extensive thoughts on Itineraries which as I understand it, is the concept of the message containing specific processing steps on board. I am still digesting this, but it may be something to look at.