Forum Replies Created
-
Posts
-
This issue is now resolved. The orchestration was the problem. I have approached my process in a different way and all works as it should.
Cheers
Hi
I have now resolved my problem.
Within my component I defined my process within a System.Diagnostics.ProcessStartInfo object. The function that contained this code returns true or false depending on whether the process ran. From within my orchestration (message assignment shape) I created an instance of my process object, set an orchestration defined variable to the return value of my process (true or false) and assigned that value to a node within my outgoing message. So my orchestration completed, messages were sent and the process (an exe) was executed on the server successfully (writing content to a text file in this case).
Cheers
It sounds like what you want is to have a single orchestration instance that processes all incoming messages from a given set (for example all messages received from a specified port, or all messages sent by a specific partner). If so, then it sure sounds like what you're looking for is what's called a Convoy. Here's a good article on the topic: Convoy Deep Dive
Joel,
I'm not aware of any such property, at least that I can remember. My guess is that it's not there because that would mean the disassembler would need to hold on to all generated messages from the debatching until it read them all before it could return them (i.e. it would need to break the entire message and read it all the way though before returning a single message from GetNext()), which would completely hose up the streaming [goodness] nature of the debatching process.
[quote user="myPFerreira"]Read the Microsoft article!!! 🙂
It's not an SQL table, it's a simple MS Access database table.
It's location by default is:
C:\\Program Files\\Microsoft BizTalk Server 2006\\EDI\\Adapter\\CodeLists\\EDICodeLists.mdbI forgot to mention that on the schema file you have to configure it and say that the codelist database is located at the path I referred.
To do this click on the <Schema> node and on the properties under Biztalk you have a field named \"codelist database\".[/quote]Great! Now it works with any custom schema 🙂
Sajid,
Instead of XmlDoc.InnerXml use OuterXml which will contain a more complete message. Just a thought.
Thanx for the reply,
I now understand that it has to do with the way I write the message to the queue. I make an XMLDocument and then use the queue objects WriteString(xmldoc.InnerXml) method to write my xml to the queue.
I tried the same thing using the MSMQ, it didn't work. But when I used its send method to pass on the entire XmlDocument object it worked alright.
like MessageQueue.Send(XmlDoc). The send method takes an argument of type of 'object', It worked alright without any errors.
But when I try passing xmldocument using the WebSphere MQ object.
MQMessage.WriteObject(xmldoc) or even tried explictly by casting it MQMessage.WriteObject((object)xmldoc), it gives me this error.
Type 'System.Xml.XmlDocument' in Assembly 'System.Xml, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' is not marked as serializable.
I just cant understand why writting a same XmlDocument object to an MSMQ send method didn't gave any error, while this is giving it.
Both take object type as their argument.
Any help, would be really appreciated.
Regards,
Sajid.
While BizTalk can be tuned for low latency the asyncronous nature of BizTalk's architecture typically cannot promise those rates. Read this for more information. In my experience a system like Tibco might be suited for those rates since it handles the messaging at much lower (tcp, etc..) levels. Most of the financial systems on Wall St run Tibco.
Typically when this message occurs BizTalk cannot recognize what message type the message belows to. I typically attempt to write a pipeline component to debug the message going thru the pipeline by writing the message to the event log. I almost always find that the messages I'm comparing are 'slightly' off, either missing a namespace or BOM's are different.
There are a number of options here:
Rather than suspending messages, you can use the a new feature of Biztalk 2006, that allows you to route failed messages. Rather than suspending failed messages, the message context properties are changed and then published to the messagebox. You can have an orchestration or send port subscribe to these messages and take whatever action is required.
Similarly use of scopes and exception handlers in orchestrations allow you to catch errors and take action rather than letting Biztalk suspend the process.
You can also use MOM, to listen for the WMI Events that are fired when Biztalk detects an error. MOM will alow you to send an email in response to an error.
Biggest problem I ran into was I was using Atomic Scope with Web Service. The WS only accepted data to start, and was changed to issue a response. The response cause the Orchestration to fail because you can not have a request/response action with a WS in an Atomic Scope.
downloaded SP3 from this Location
http://www.downloaddatabase.com/databasesoftware/microsoft-sql-server-2000-service-pack-3a.htm
down loaded SP3 from this Location
http://www.downloaddatabase.com/databasesoftware/microsoft-sql-server-2000-service-pack-3a.htm
