July 12, 2006 at 2:37 PM #15042
Hello and thanks for any assistance.
Here is my situation.
– I have an Orchestration, (that is called from another Orchestration, and to which accepts a parameter).
– One of the first thing that the Orchestration needs to do is read in an XML file from a directory (this xml file contains product mapping data) and then loads the information from the file into a Message for further processing.
– This file can not be deleted.
(- At first i was calling a .net component which would open and read the file and load it into an XMLDocument and pass it back up to the orchestration and into the Message. )
I tried to change that method (calling a .Net component), so that the orchestration uses a Receive Port to access the file, however i receive a couple of errors:
‘you must specify at least one already-initialized correlation set for a non-activation receive that is on a non-selfcorrelating port’
And when i changed the port to activate=true i received the following error:
‘a schedule ‘myOrchestrationName(message myMessage)’ with parameters cannot have an activatable receive’
As mentioned in a message from the following group, it does not look like it is possible to have a receive port on a Orchestration that is initialized using parameters: (Is this true?)
My Question: What would be the best way to accomplish this task, I would really like to use a receive port, as that way i can dynamically configure the location of the productMappings file and won’t have to carry around an extra .net component.
July 13, 2006 at 5:05 PM #15043
Hey, Thanks all for your replies.
This is a great message board for BizTalk assistance.
– In the meantime, I implemented the .net approach with the file location being an appsetting value in the biztalk config file.
– I will probably be updating this in the next iteration to extract the values from the database as this way it is more scalable and easier to manipule.
Thanks all for your help.
July 12, 2006 at 4:21 PM #15044
Well, you can’t have an activateable receive on a called Orchestration because when it’s called it will always be active. Make sense?
BizTalk is a pub sub system. So, if you use a receive port to read in your file it will just be published to the message box as soon as there is a file in that location. In this case, you will need some type of correlation to get that file into your already running Orchestration and it will need to arrive at the correct time in your business process. Plus, the file will be deleted.
If you know the file name and location at run time, I’d just use .net code to read the file and not delete it. I think it’s as simple as Xml.Load(“filename”). Not really ideal – but straight forward and simple.
Hope this helps.
July 12, 2006 at 7:44 PM #15045
I was recently faced with a similar problem, except using FTP.
The only options I could think of were a .Net class or writing my own FTP request/response adapter.
The .Net class took about 10 lines of code.
I started investigating the FTP request/response adapter. After a day I decided the .Net class while not ideal was good enough.
I may get back to the FTP request/response adapter one day.
July 12, 2006 at 9:14 PM #15046
Just to sum all this up – an orchestration \”receive port\” is not a \”read file\”. A receive is a subscription to a message from the message box.
(Is that the right wording?).
Also, the way Biztalk physical \”Receive Ports/Locations\” work, if the file was not deleted, how would it know not to keep reading (and publishing) the same file over and over again. [This goes back to an issue of which I have heard conflicting stories – does Biztlak poll the directory or is it NTFS event driven. ]
It might be cool feature to have a \”read\” file \”port\”.
The point would be to configure the filename etc… externally using the Admin Hub. But then would it do pipelines, and mapping and all that cool stuff???
If you go back to the .NET method, maybe you just parameterize the name of the file you want to read (you could do this with an app/config variable in the BTSNTSvc.exe.config file – or there is a now a sample in 2006 of how to store parms in SSO).
- The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.