I am trying to correlate an orchestration based on part of a received file location name and the date received. I have the receive port with an inbound map that assigns the date, but I cannot figure out out to access the promoted property for the receive location (which I have promoted).
Is there any way to access this info? Xpath? C# functoid?
Thanks!
Literally answering your question, yes, there is a C# functoid that allows access to the context properties from within a map.
However, if I understand your question correctly, you have an orchestration that sends a request message and is asynchronously waiting for a correlated response. I also understand that you would like all messages received from a specific Receive Location at a certain date to be routed back to the appropriate orchestration.
For this, you do not need to access promoted properties from within a map. All you have to do is initialize an appropriate Correlation when sending the message and have the properties specified in the Correlation Set promoted by the incoming Receive Pipeline.
For this to make sense, obviously, you would need to restrict the date to an acceptable range, with precision to a day, a hour-range or even a minute-range. Anything below that would run the risk of not being able to correlate the response to the appropriate time.
If you have some degree of control on the particular system that produces the response, using a GUID for the correlated property is probably the simplest approach.
Related
I have an object:
Account
{
Id,
Name,
CurrentBalance
}
Id is an immutable key, Name is a mutable string, and CurrentBalance is calculated from all of the transactions associated with the account.
I am stuck on the fact that GET \Accounts\{Id} will not be idempotent because changes to a transaction will cause a change in CurrentBalance. Should I remove this field from the object and make a request like
POST \Accounts\{Id}\CurrentBalance
But now I have to make multiple calls to the server to get the CurrentBalance of all objects:
GET \Accounts
POST \Accounts\{Id1}\CurrentBalance
POST \Accounts\{Id2}\CurrentBalance
POST \Accounts\{Id3}\CurrentBalance
....
I guess I am just looking to see if there is already a standard way to handle this that I am missing?
UPDATE
Part 2 if the original object is ok via GET. My only way to update the Account.Name is via a PATCH as I cannot allow an update to CurrentBalance, correct?
NOTE
I realize I could put this on the client to have to get all transactions and calculate it, but I would prefer to do this on the server for multiple reasons
Idempotency does not mean that you must always get the same response back.
Consider the resource /TodaysWeather. It would be pretty useless if it always returned the same value.
Idempotency simply states that if a client makes the same request multiple times instead of just once, the impact on the system (from the client's perspective) will be the same.
I just re-read the HTTP specs and realized that if I want to be truly RESTful I have to make multiple calls because GET has to be safe.
In particular, the convention has been established that the GET and
HEAD methods SHOULD NOT have the significance of taking an action
other than retrieval.
I am not deleting this question because I think it could help others in the future, but if the majority disagree I will delete it
If it's important that you're able to PUT some data, then immediately retrieve the same data via GET, then you could simply treat it as a different resource entirely, e.g.:
# Change an account name
PUT \Accounts\{id}
# Get accounts/names/balances
GET \AccountDetails
# Get balance of an account
GET \AccountDetails\{id}\CurrentBalance
However, there's really no good reason to go through the trouble of doing that. Your PUT is idempotent as long as making the same request multiple times doesn't change the state of the system. Not changing the system's state if some spurious value is submitted is the correct behavior. In fact, if someone does try a PUT including CurrentBalance, you might want to return a 400 (Bad Request) status explaining that CurrentBalance can't be updated.
I have an orchestration which is receiving messages from the message box of type XmlDocument. The messages have promoted properties and I am including the property schema in my project so that I may filter on them (a separate application is creating these messages). I am then assigning the untyped message to a typed message (I am not altering the name space) via a standard message assignment shape e.g.
MsgAgressoNewStarters = MsgXmldoc;
I am then outputting the message to a file location. However when I do this the property schema is also outputted.
How can I prevent this? I have tried filters etc.
Thanks
10th May 2012
I think I am possibly going about this the wrong way perhaps if I describe the full scenario you may be able to spot my deliberate mistake ;)
We are using BizTalk 2010.
I have a BizTalk application which talks to a 3rd party generic webservice that returns reports from one of our systems. This application is activated via the scheduled adapter which sends an XML document containing two values, the report name and the interface it is for. The web service returns the report as a string on a single XML node, this string in its self is an XML document. I then load this string into a message of type System.Xml.XmlDocument. There is no way of telling from the format of the data what report or for what interface this message is for. I need to send this message to the messagebox for it to be picked up by any number of related biztalk applications. So far I have tried creating a correlation set with the two values (from a property schema) & used that as the initialising correlation set on the send shape. I have then used the same property schema on another BT application to filter the message. This works but for some reason I get two messages, one being the XML which activities the orchestration which has the same fields as the property schema & correlation set. BizTalk doesn't seem to be able to tell the difference between them although they are structurally different and this is where my problem starts.
I am now thinking of creating a multipart message in the report application one part being the XmlDocument and the other being a header with the values I wish to route on.
Hope that makes some kind of sense.
I've actually now answered my own question, because both messages have the same properties I am inadvertently subscribing to both, d'oh!
After moving away from Biztalk since BT2006, we're looking at bringing it back into the organization. One of the frustrations I had early on was when dealing wht HL7 and orchestrations, we needed to have a seperate orchestration for each ADT message type, even though the schema for each type is essentially the same, and each orchestration did exactly the same thing. Moving forward into the world of BizTalk 2010, has anything improved here? Is there a pattern I can utilize to use a single orchestration for all ADT types?
HL7 messaging in BizTalk has remained roughly unchanged since the 2006 release. Because BizTalk defines a schema for each message and event type (e.g. ADT^A01, ADT^A03, ADT^A08) and not just for each message type (e.g. ADT, BAR, MDM), your mapping and orchestrations quickly become a mess.
Here is what I have done in the past to get around this limitation:
Allow messages to come in untyped to the orchestration. That is set the MessageType = System.Xml.XmlDocument. I found that generally, I am only interested in parsing out or updating a few elements, so I would just write a helper library with a few generic linq statements to get to the data that I needed. This way, I could write a linq statement that gets to PID-3 (Patient Id Number) and I would be able to use it consistently over any message or event type because PID remains the same. Likewise, I would use the same technique to update the message as well. This technique does not work great if there are large structural differences in the fields that you are looking to update or if you are looking to read/update a large amount of data.
Create master/canonical HL7 message type schemas. This takes a bit more work, but depending on how many message types you are looking to process, this can really pay off and is more consistent with how healthcare organizations think of their HL7 interfaces. In order to do this, you would need to define a new schema for a message type and include all possible segments for this message. So, instead of having multiple ADT types defined, you would roll all the possible variations for A01, A03, A04, etc. under one master schema. This will allow you greatly reduce the amount of mapping and parsing logic needed. Unfortunately, since this is not the HL7 accelerator's default behavior and will require some custom pipelines and orchestration logic to achieve. Basically, you will need to modify some properties to get the Accelerator to think that your new master message is valid.
For mostly pass-through interfaces, I would recommend technique #1. Otherwise, if you will be generating or needing to consume basically any message event in a canonical fashion, technique #2 can pay off in the long run.
As I see it you have two possibilities here.
Treat the message as anonymous. This means your message is "un-typed" (you declare it as a System.Xml.XmlDocument type). Then your orchestration can interrogate the message to decide what type it is.
Create an envelope message whose body can be all of your possible message types (using the xsd choice group selector). Your orchestration then handles the envelope message type. With this approach you can declare the type contained in the body of the envelope by setting a value in the envelope header.
I would prefer the second one; while it is certainly more work (you need to wrap all your inbound messages in an envelope) it allows you to understand the what the message is by just looking at the envelope header. This means you can still route by message type if you need to.
Let's say I have a flat file containing incoming messages. Where would the appropriate place be to inject the logic that takes identifying information from the message and sets primary key properties to link it to internal record IDs. For example, to map a customer's version of order ID into our internal order ID.
Sounds like you are looking to do a conversion of the incoming id to the internal id before sending the further along.
There are multiple places to do this.
You could do it in a pipeline component that either reads directly from its run-time configuration or from a database. You could also do it in a orchestration.
The easiest and most suitable place to do is probably however in a transformation map. Just make sure not to hard-code the transformation table (what id maps to one of you internal ids) as these usually change a lot. Have the map do a lookup ion a database for example to find the matching id.
Doing these kind of tasks in a map compared to the other options gives you a bit more flexibility as you can then apply the map directly in receive or send port. So if you don't need to do any workflow based logic you can use a messaging pattern and skip any orchestrations (always preferable).
I would consider doing this type of conversion in a map.
I have found some broken threads across the web where people claim to be able to use receive shapes in an orchestration with XLANGMessage types to receive flat file schema files that could not be assembled into a specific xsd.
I've attempted to set the messagetype in the receive shape as Microsoft.XLANGS.BaseTypes.XLANGMessage, but this basetype is not serializable. This then causes a build error.
Is there an object type that can capture both XmlDocuments of well formed xml messages as well as malformed xml and non-assembled flat files?
In answer to your direct question in bold - yes, the type you are after is System.Xml.XmlDocument.
What you need to do is create a new message and when selecting its type, select the above type from the .NET Classes section.
This message when assigned to a receive shape can then receive any payload, for example, I've often used this to pass formats such as .pdf files through BizTalk where I had no need to parse them. Do be aware, however, that despite the name, what you have here is not Xml and will cause you all sorts of issues if you try and treat is as such.
To dig a little further into your question - are you trying to make some sort of error handling orchestration?
If you are then in your error handling code you can just have a recieve shape that receives a message of type XmlDocument with its filter expression set to ErrorReport.ErrorType == "FailedMessage" that is bound to a direct bound port attached to the Message Box.
I've often found it handy to have two receive shapes, one to catch routing failures, when we have any possible payload, and another to subscribe to a strongly types fault wrapper envelope that you define and pass out of your other orchestrations from their CatchException shapes.
This means that you can then build one centralised place to handle all exceptions.
If you haven't seen it, there is a nice post by Charles Young that may describe something similar to what you are trying to do.