Is it possible to pass some parameters to xslt map? Let's say I have the usual btm and xslt maps and going to use it with usual receive/send ports. And I want my xslt map to depend on some external flags - if when map is starting it receives flag1=1, one transformation is performed, if it receives flag1=0, another one is performed. Is it possible?
Of course, I can simply create two different maps. I also understand that if I put my map inside an orchestration, somehow I can pass variables when orchestration is calling map. But is it possible to have a sort of choose-when that depends on external flags within one map and, the most important thing, to set up these flags in BizTalk Server Administration Console, when I set up ports and maps binding, NOT to hardcode it in orchestration?
I would appreciate any advice.
You can use external data(maybe a sys var or table data) by calling a c# heper, but there is no way to setup a flag from Biztalk Console Admin
Related
I am learning pureMVC and trying to implement the framework into one of my application. I have follwing case:
My main application has Canvas which is used to add different kind of custom components. One of the custom component is a "Search Component" (multiple instances are created on page). My search component has a textfiled and a search button and initiate search in following steps:
1-Clicking search button dispatches a custom event, that custom event keeps reference of search component as a property.
2-My AppMediator listens the custom event and get the reference of current search component along with search text.
3-Mediator send a notification (sentNotification(AppConstants.SEARCH_CLICKED, component)).
4-I have registered a command with SEARCH_CLICKED notification.
5-Command retrieve a WebserviceProxy and invokes its Search(text) method.
6-WebserviceProxy talks to remote webservice and uses asyncToken to get results.
My Questions is:
My Command has the reference to the custom search component when it start search but search webservice takes some time and get the result. How can i handle the results back to custom search component that initiated the search. Since i have multiple instances of search component. What is the best place to keep the reference of that component, should i add a variables in WebserviceProxy to keep that reference and hand the results over to it, or i have to create a Global Proxy to keep references of such components?
Thanks
I have been using PureMVC for some years and I like it!
I think you have not yet understood roles and collaboration of main components.
You should not have any dependencies between Commands and UI-elements. Your Mediator has to get the concrete value from your UI-component and send it through the Notification. In this case the Command and the Proxy will get only a text value and it is no matter, what is the source of it! Suppose you will change your UI after some time and you will have another components on the user side to determine the search value. In your case you would have to change the Proxy and the Command. It would be bad.
Proxy may not have any information about Commands and Mediators. It can only offer its functions to let another components interact with it AND it sends Notifications with new information after getting it without knowing who is interesting in it.
Read the description of the framework once more and write your questions.
I had some problems with understanding the stuff too, I see your problem.
Based on Anton's answer, i re-think and tried to separate dependencis. As a result, i tried to mediate each instance of Search Widget with "SearchMediator" separately by providing different ID to the constructor of Mediator. Now, when search widget intiates a new search, it's mediator invokes the Command, Command invokes a method of Proxy to do actual search and fetch results from DB and sends a Notification. SearchMediator takes care about that notification and hands over the results to appropriate UI.
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.
I have one table which has 2 IDs.
Now I have to check id1 value of table1 and if it is equal to id of the destination schema
then i have to take the id2 from the table1 and assign it into second element in the destination schema..
How to do this using database lookup table functoid.
I believe Microsoft made a big mistake to include the database functoid. The reasons for this are:
The SQL code generated under the hood is not performant (run a sql trace and you will see). In fact more than one connection is sometimes created.
The request/response to SQL server will not be handled via the send port/adapter framework. So no enterprise-level servicing is available for the call (failure handling, retries, load balancing, etc).
From a design perspective, it obfuscates the db calling functionality inside of a xslt which is nasty.
However, you can achieve the same ends by making the call to the database outside of the map, and then passing the response message from the DB call into the map alongside your source message you want to transform. You can add as many input messages as needed in this way.
If you want details on how to create a multi input map: https://stackoverflow.com/a/7902710/569662
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.
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.