Forum Replies Created
-
Posts
-
I have never seen this used inside a BizTalk Map. Not sure if it’s supported or not…
You’d want to pass the message into BizTalk and then do a multi message mapping inside an Orchestration. It would get a little messy.
Now you could be able to have a .net component that you call from the map that reads your file and returns your value. I know that works.
The BizTalking Cat talks about the error here: http://biztalkblogs.com/fairycat/archive/2006/09/11/1505.aspx
Although I’m not thinking that’s the problem. Are you sure the Orchestration is returning a message? It almost sounds like it is not returning data or not return data in a timely manner.
Can you post an example of your flat file data, there are a few potential traps with trailer records and pipeline debatching
I guess you could delete from the cube directly, or, use bm.exe to remove the view/activity and then add it back. That would delete the cube and recreate it. That's a fairly heavy-handed solution.
When a client sending file to a schema request only web service, and the format is wrong, will the client get rejected?
Or i have to create and Request/Response web service to reject those invalid files?
Thanks
Yes you need to use the FF disassembler. This component parses the flat file into Xml, which is nescessary if you wish to map it.
If your input flat file schema has a record maxOccurs = 1 (default) then the flat file disassembler will break the file into individual records.
If you wish to process as a whole file then you need to set the record maxOccurs = unbounded.
You may also neede to use a looping functoid in your map, but this would depend on the structure of input and output. Sometimes the mapper will automatically loop if input and out records are both maxOccurs = unbounded.
Subject line should read "XML file" Just wanted to make sure people didn't think I needed Excel help.
First of all, I'd kick your batch size (in the receive location for HTTP) down to 1. The documentation states:
Batching Support for the HTTP Receive Adapter
The HTTP receive adapter submits messages to the server in batches. The size of the batch used to submit messages to the server can be configured on the HTTP adapter receive handler.
Thanks a lot, that sounds coherent!
When using an Orchestration with a web-service I have another question. I´ve been trying to do some performance tuning and found out that the BTSHTTPrecieve.dll takes approx. 2 seconds to pass my message to the pipeline. Since the entire response-time (client->webserver->biztalk->client) takes 4-5 seconds, I think that almost 50% of the time is not representative for just passing my message to the pipeline. Are there any ways to get it done faster? Does the BTSHTTPrecieve.dll check in an interval for new messages?
Here´s how it looks like:
client—>Web Service(0.5 Sec)
Web Service–>BTSHTTPrecieve.dll(0 Sec.)
BTSHTTPrecieve.dll–>PipelineIN(2 Sec)
PipelineIN–>Orchestration(0 Sec)Orchestration–>PipelineOut(1 Sec)
PipelineOut–>BTSHTTPrecieve.dll(0 Sec.)
BTSHTTPrecieve.dll->Webservice(1 Sec.)
Webservice->Cleint(0.5 Sec)
To your question, yes, an orchestration can consist of a single step, but in your case, the extra overhead makes it unnecesary. I'd just go ahead and write the web service as you currently discussed. Where BizTalk, and orchestration may add value is when you want to aggregate functions and expose a single interface. For instance, let's say that in order to do "GetInformationForEmployee()" you actually had to call three different systems (couple databases, maybe another web service that's already out there). In that case, might be a good idea to have an orchestration that calls all three systems for you, and exposes the single "GetInformationForEmployee()" interface to the caller. Given that there is naturally a latency and processing cost for calling into the BizTalk bus, I like to BizTalk to expose (synchronous) web services only when I'm doing some sort of business processing, multi-system coordination, rules, decisions, graceful exception handling, etc.
Hope that helps.
Creating the views using bm.exe creates the tables, triggers, jobs and cubes necessary to surface your data up. Until you apply the mapping from message/orchestration to activity, nothing will get stored in the BAM tables.
You'll notice after running bm.exe that you've got 2 SSIS (or DTS if you're on SQL 2000) jobs that move data over to the analysis cubes (assuming you're not doing real time aggregation). What you want to do is to schedule those jobs (BAM_AN_* populates the cube, BAM_DM_* does maintenance) to run on say, 5 minute intervals. That's what you 'run' to get the cubes, and thus BAM Portal updated.
Actually I'm using the ErrorReport.ErrorDescription to get the description of the error, but I was expecting that some of the message-properties from the suspended message give the name of the App but no luck with that approach.
That's why I'm listening directly on the MessageBox… :S
So what's the reason for the dynamic mapping? Do you only have a single end point? Since you can apply a map(s) at a send port level, in a basic scenario, you do dynamic routing and whichever send point has the necessary subscription (e.g. Quantity > 100 AND VendorID == 1234) will be used and the appropriate maps applied. Also note that a send port can have multiple maps and the matching inbound root node will be used to pick which map to use.
To your other point, reading the file in repeatedly is indeed poor for performance, and, would require that file to be sitting on each machine in the BizTalk farm (unless you are using UNC paths). So, you could put those values in the btsntsvc.exe.config file (which is read upon host start up), but then you still have to keep those config files in sync on each machine.
The best choice for reading those types of constantly used (yet static) values is to use either the BRE, or SSO. For the SSO option check out the code samples online (http://msdn.microsoft.com/biztalk/downloads/samples/default.aspx), the one called SSO as Configuration Store.
