Forum Replies Created
-
Posts
-
You will only get a file with the part marked as ""body", as the previous post said, you will need a custom send pipeline with MIME, then if you use the file adapter with the mask set to the extension ".eml" you will be able to open it with you email client (outlook for example) and you’ll see the all the parts as email attachments (or the body part as email body and then all the other as attachments depending on how you configured the MIME component.
Enrique
http://www.BiztalkAnd.Net/blog
In this Scneraio …wont u need to to GAC the helper class dll in all Biztalk Application Servers.If you are using NLB then any Server may access the incoming request.So wht do u say…writing one line of code is better using BTSntSvc.exe.config or calling the helper class and using BRE.
I think you have the answer…..BtsntSvc.exe.config.
See the only disadvantage of using BTSntSVc is the URL is exposed to one and all….and one should be careful while updating it.
Other then that I dont see any pitfalls.
I am trying to avoid the BtsntSvc.exe.config file due to the issues that I may experience when we deploy the solution on a cluster. I believe that this would require having the value stored in the BtsntSvc.exe.config file on each server.
I am looking at a method suggested in chapter 5 of BizTalk 2006 Recipes where I create the value within a vocabulary in BRE and code a .Net helper class to allow Biztalk to access that value within an expression. This means that the value can be easily updated. Can you see any downsides to this approach?
In this instance, I have a URL value that I will need to use in multiple orchestrations. I would rather have this URL stored in one place rather than hard code it into each orchestration.
I guess that security isn't an issue and it is not a value that will be changed all that often but it would be good to have it defined in only one place.
I guess it depends a lot on what your configuration is for and what technical restrictions you have in place.
Personally, I try to avoid using .config files, as they are a pain to update on a multi-server environment. For technical component configuration, I tend to favor using the SSO: It's easy to use and works great for across a biztalk group. Either that, or some other central-database oriented schema.
For business level configuration, though it makes a lot of sense to encapsulate that in rules in the Business Rules Engine, though.
The FILE adapter doesn't know how to deal with multi-part messages natively, since a single file would naturally only know how to deal with a single message part. The SMTP adapter, by contrast, knows how to do it since multi-part messages are very normal in email (think attachments).
That said, you can use the MIME/SMIME encoding component on a send pipeline with the FILE adapter and it will output a single file that contains all message parts encoded using MIME, I think.
These might be helpful,
http://webservices.sys-con.com/read/90092.htm
http://dotnet.sys-con.com/read/121831_1.htm
The Sales application, and the development team/sales team owns the data in question from the subscriber. When the finalize a sale, a contract and wrapped up into an XML feed and fired off to a remote private MSMQ that I monitor. I have had too many issues with web services themselves so I only enforce MSMQ as the pick up/delivery standard.
The problem isn't necessarily with the data from the publisher being 'bad', but something not working 100% at the subscriber. Even with the situation you offered, at the end of the day, don't I end up taking on MORE responsibility of being the God of support for the actual application and then extending that and being responsible for reporting back to the original publisher just because a subscriber had a problem that really has nothing to do with the data being sent to it? It would be an issue with the application that failed on the data feed, not the publisher as all other subscribers handled the data just fine and as expected.
Here's an idea of what I'm doing
Sales Application ——–> BizTalk —————> FPO Application
|
———————–> ERP
|
———————–> ODSIn the above situation, the ERP and ODS consumption feeds into their databases are successful, but the FPO app, although my message delivery is successful, fails on the data for any reason. If it's an error in the FPO application, and NOT the integration, who's responsibility is it to be 'aware' of the issue with the app? Should I proactively be responsible for letting the app admin know, or should they have their own hooks in place to monitor for issues? How am I responsible if I simply play the post master role and I have successfully delivered the message? Hence, "Don't shoot the messenger." 🙂
I can see where the situation you offer can be helpful, but in the world of EAI, at least from what I've read and done in the past few years, and forgive me, I'm not knocking your idea at all, but all this does as I see it, is extend the connection of the publisher by using Biztalk as a glorified adapter with direct point-to-point between two applications. Isn't the 'technical' definition of EAI encapsulated by the whole loosely coupled solution by utilizing a message broker to distribute published data to multiple subscribers? The application involved shouldn't know anything about each other, nor should the integration know anything about the applications other than the format of the data it needs to accept and send out.
Again, I'm only putting out what I got out of the whole deal of EAI/SOA. I'm not challenging anybody's knowledge, just putting mine out to be tested.
-Rich
More than envelope processing, in this scenario, assembling the output is the key as Nishil mentioned. With envelope processing you'll have difficulty in correlating each of the records once you split them and update your DB.
You need not use a .NET component as well. You can do it with biztalk components itself. Refer to example "Looping through each employee record" at this link: http://msdn2.microsoft.com/en-us/library/ms935658.aspx.
You can slightly modify the looping process to assemble the output from your DB.
You may already know, but these two articles are good from Jeff and Stephen Thonas:
http://codebetter.com/blogs/jeff.lynch/articles/128664.aspx
http://geekswithblogs.net/sthomas/archive/2004/10/25/13269.aspx
And here are many other solutions:
http://biztalkland.blogspot.com/2005_03_06_biztalkland_archive.html
Who is the originator of the data here? If it is you then messages getting pushed back to you have some reasoning. If you are not, then push back all of the rejected messages (or subscriber exceptions) back to the originator (If it is a web application, then some how to that app) and keep quiet. Just like an honest post master.
In your scenario, "loose coupling" is what the cause of the problem is. You said, you are using Posting for subscribers. In such cases, if I were you, I'll hold the client (customer) until I post the data to subscriber, get a sync response from subscriber and post the same response back to customer so that he knows what the problem is and can take corrective action or re-send the data with correct information. Note that, customer is still waiting until you do all this in between. Meanwhile, you can simply note down which message came in and which message went out, just for the sake of reporting purposes.
data data
Customer ——–> You ———–> Subscriber
<——– You <———-
Sync Response Sync Response
You don’t need loosely coupled Integration, but a simple point-to-point synchronous integration. This will work only if the size of the data is not very big since you'll have to hold the customer's connection open until subscriber sends you exception response.
Technically, I'll create an orchestration (and publish it as a web-service) which does nothing but to receive data and send it to subscriber, receives response from subscriber and sends this response back to customer without bothering about what data is getting exchanged and there by leaving the onus of answering the exception to customer and not you.
Who is the originator of the data here? If it is you then messages getting pushed back to you have some reasoning. If you are not, then push back all of the rejected messages (or subscriber exceptions) back to the originator (If it is a web application, then some how to that app) and keep quiet. Just like an honest post master.
In your scenario, "loose coupling" is what the cause of the problem is. You said, you are using Posting for subscribers. In such cases, if I were you, I'll hold the client (customer) until I post the data to subscriber, get a sync response from subscriber and post the same response back to customer so that he knows what the problem is and can take corrective action or re-send the data with correct information. Note that, customer is still waiting until you do all this in between. Meanwhile, you can simply note down which message came in and which message went out, just for the sake of reporting purposes.
data data
Customer ——–> You ———–> Subscriber
<——– You <———-
Sync Response Sync Response
You don’t need loosely coupled Integration, but a simple point-to-point synchronous integration. This will work only if the size of the data is not very big since you'll have to hold the customer's connection open until subscriber sends you exception response.
Technically, I'll create an orchestration (and publish it as a web-service) which does nothing but to receive data and send it to subscriber, receives response from subscriber and sends this response back to customer without bothering about what data is getting exchanged and there by leaving the onus of answering the exception to customer and not you.
Thanks for the response. Here's my argument, I should have been clearer on this to begin with now that I reread my original post.
My customers are all internal…different development teams, so one application (sales system) feeds an ERP, an ODS, a Data Warehouse and a Field Purchase Ordering system, for one example and all of these solutions are owned by their development teams, not by me. My EAI solution sits in the middle of it all as the message broker to distribute published messages from the sales system to the others I mentioned. Any exceptions that I run into are managed within Biztalk but that only covers my arena of message delivery (i.e.: msmq on remote server not available, web service is down, etc…).
The data, as far as schema and usability is good, so it's not a matter of the XML or schema being bad, more a matter of a subscribed application not being able to handle a feed for the following scenario:
1) A sales feed is published to the framework and Biztalk is responsible for picking up the message, formatting the message if need be, and pushing it along to the subscribed solutions. I have internal logging to a database that taps data from the running orchestrations simply to log what I've done and if I run into any issues. The feed is distributed to the downstream systems and as it sits now, I receive a notification from each subscriber after they process the data feed, ONLY as a logging solution…or that was my goal.
2) All other subscribed applications accept the feed and process the data correctly, except for one, we'll say the Field Purchasing Order app. For whatever reason, again this is not my application, the feed fails due to a business rule violation on the side of the subscribed application, not the integration. I receive an exception message and I log it on my end just so I am aware there was an issue and can reference the health of my integration layer.
3) The message from the published application is resent, and of course, the feed is again dispersed to all subscribed applications as I do not have any hooks in place to say, "this has been sent already and last time it was, only feed the application that failed last time.
Here's my argument on the scenario.
My responsibility is to deliver the messages correctly, and in sequential order, which I do now with a sequential convoy, once the message is essentially delivered, I should be the one washing my hands of the transaction. If step two occurs, although I receive notification of an issue, today, I am currently the one 'assumed' responsible for notifying the administrators of the application that failed, where an issue arose, so as the EAI developer, my role is now stretched into a babysitting role for the other developers and their applications. Again, my understanding is that, my role should end strictly at the point of data delivery to the subscribed solution's adapters and that's it, and I should not be accountable if their applications run into a data exception solely based on their processing logic. Sure, if the physical data is bad, I take responsibility, but only at the level of a message broker, after all…garbage in, garbage out…I should not build the EAI to be smarter than the business process and if there is bad data, then the external user community needs to realize there is a broken process and fix the root of the failed process, but not rely on the integration layer to just 'know' how to handle a user's boo-boo. Lastly, if a feed is sent through the integration more than once, again, the integration layer should be not responsible for tracking every single feed and contain logic to know, "Oh, someone sent this before, I need to dynamically adjust my output to support the fault of one application". Again, that puts the responsibility of support into the integration and a fully disconnected, "loosely coupled" integration layer should NEVER be that intimate to the subscribed applications.Whew….hopefully you're not asleep by the end of this 🙂
Please, anybody who may have an opinion as well, join in. I'm really struggling with this as I've read in several articles the exact opposite that ALL EAI solutions should be fully aware of the subscribed solutions and assume full responsibility of them by extending the umbrella of exception handling beyond the delivery port.
-Rich
