Forum Replies Created
-
Posts
-
as a followup – BizTalk is forcing you to throw these 15meg blobs through the database, when really all you want to do is move them on the file system. That is why I wonder why not write the thing in vb.net and skip the BizTalk message box convention.
-wa
I want to be clear that I'm still receiving the message that No Disassemble stage components can recognize the data.
Thanks again
The SQL Receive adapter is a polling adapter, it will execute the configured query or stored procedure at an interval you specify and return some records as an Xml message, or possibly no message if there are no records that meet the criteria.
e.g
Create PROCEDURE bts_PollTable AS
SELECT * FROM myTable WHERE Status='New' FOR XML AUTO, ELEMENTS
UPDATE myTable SET Status='Processed' WHERE Status='New'
GO
Hi,>>One thing you don't mention is whether high priority items can interrupt already running low priority orchestrations. Anyway, assuming not, why >>not have a component which orchestrations ask "Can I go ahead?" Then it's very easy to tune the behaviour.What do you mean by a component? Can you please explain it?Regards,-Baskar-thank you very much for your reply. The actual orchestration is miminal. It calls a sproc to update a table based upon the file's name. It calls a simple custom assembly to kick off another small process. We've verifed that once the .tif files are in the orchestration, everything runs beautifully. The bottleneck is definately loading multiple larger files (200+mb) .pgp/.tar files in at the same time and processing them through custom pipeline components. I can't give you specifics, but my gut instinct tells me there's a memory leak in our untar component.
If we decrypt and untar manually and just throw a ton of .tifs at it, there is no problem. I think the problem is coming in by reading several 200mb+ files into the message box at the same time? We've considered breaking this process out, however, that is what we're currently doing w/ a windows service, so why migrate the process to biztalk at all?
My main question is: I'm wondering if anyone else is using biztalk for the purpose of really just waiting for large files to be FTPed to us then moving them from one place to another. We've found great uses for biztalks on more system integration tasks and it almost seems to me that in this one case, we're trying to make BizTalk a file mover, when it really wasn't designed for that.
I will tell you that today we've found a way to "work around" the issue. I will post that later, but it is really just a work around and I'd like to get some other people's thoughts first, w/o "tainting the jury 😉
- Go to any file folder but preferably the one containing your mapping project/files.
- Create a text file and name it "DBConnection.udl". (The important part is the extension .udl)
- Double click the file.
- On the Provider Tab, select SQL Native Client (this assumes it is installed), then Next
- For Data Source, enter yours: HPSQL05T
- Initial Catalog, TESTDB
- Either use integrated security or click allow saving password
- Test Connection…OK
- In your map, either drop a String Concatenate functoid or add the following to the Database Lookup functoid as the second paramter.
- File Name=<replace this with the path to the .udl file you created>
- example: File Name=C:\Project\Database\DBConnection.udl
- Configure the rest of the Database functoid(s) input(s), but at least a Value Extractor, and connect it to output so you can see the results.
- Test your map.
Does this make sense…and did it work?
JohnD that's what I'm trying to understand because when BizTalk suspends a message I've noticed that when you enter to the Administration Console and ask for BizTalk to give you the list of suspended message there's a column that has the name of the app that suspends the message.
Maybe there's a way to obtain that info as Admin Console does it.
- Configure your Receive port to use PassThroughReceive
- Configure your send port to PassThroughTransmit
- Configure your send port to listen to (filter on) BTS.ReceivePortName == <Actual ReceivePort Name>
- Start the Application
- Restart the Host Instance.
- Drop your file in the receive location and watch it appear in the send port location.
This will bypass the need for an Orchestration. Save this sample by simply right-clicking on the Application, select Export…Bindings… and save it where you want. Now, if you want to add the Orchestration just to do it, or even to look at the message itself:
- Remove the Filter from the send port
- Change to XMLReceive and XMLTransmit.
- …ask if you need help with the Orchestration.
I've just verified that my "Input Instance Filename" is pointing to my test XML file and "Validate Input Instance Type" is XML.
I've also played around with the type of the attributes. My schema validates successfully when the Date attribute is a date type as well as a string type.
Thanks for all your time and effort.
Can you say what your Orchestration is doing? I'm wondering what you're putting through it. It may be that you can break this process up into component processes, but this is coming from standard development best practices.
Can you find a way to break the .tif files out and process them separately? You can receive the .tar file, break it out and send the "parts" to another port. I guess it depends on what data you need from the original file(s) and at what time.
Another simple suggestion is to see how you would implement it "without" BizTalk and verify if either way makes more sense, as well as making it easier to see how to implement a solution with BizTalk.
Using: <xs:attribute name="Date" type="xs:date" />, I received a validation error…
Header.xml: error BEC2004: The 'Date' attribute is invalid – The value '20060122' is invalid according to its datatype 'http://www.w3.org/2001/XMLSchema:date' – The string '20060122' is not a valid XsdDateTime value.
When I used xs:string, it validated fine.
xs:string, it validated fine.
Can you confirm you're not having the same problem by just using your sample xml file as your "Input Instance Filename" and that "Validate Input Instance Type" is XML?
Hi John
Thanks 🙂 I added a dummy second child record and in the top node i gave Child order as Postfix and child delimiter as 0x0d 0x0a ..
it worked
– Wincy
Anonymous,
lets see if I understood. You have one queue with messages having (let's keep it simple) two different priorities. Let's say high and low. You have two orchestrations which subscribe for messages on the queue and filter high and low messages as appropriate.
Now, your problem is to arrange that the high priority orchestrations get processed as quickly as possible, at the expense of the low priority items.
Is this correct?
One thing you don't mention is whether high priority items can interrupt already running low priority orchestrations. Anyway, assuming not, why not have a component which orchestrations ask "Can I go ahead?" Then it's very easy to tune the behaviour.
But I think the problem is that you don't really want the 'queue' behaviour – first-in, first-out. Perhaps if you have a component which is peeking at the head of the queue – if it's not high priority, then check if there is a high priority coming along and take that instead and drop that for an orchestration. Then just choke the number of orchestration instances.
I bet there's a ton of academic literature about modified queue behaviour with different priority messages!
John D.
