Forum Replies Created
-
AuthorPosts
-
Hi,
I want to convert an incoming xml file to an EDI file ie to CODECO D95 EDI format. As CODECO message format is not provided in Biztalk server 2006, i have created my own schema using the same rules and structure specified in http://www.stylusstudio.com/edifact/ and mapping with the incoming schema.
I m not getting the output. In the event viewer i am the below error. Pls can u tell me what this error means, i am not able to understand what is the error:
Error encountered: ERROR (36), docnr 10002 :
A required segment is not included in the document. Contact the sender.source format: [101 0 ,XML 1.0]
source document: [CODECOD 95BDEFAULT UN,Container gate-in/gate-out report m]
source segment: [data#3,def#1,name=EFACT_d95b_CODECO]
source element: [def#1,elm#0,comp#0,name=NADLoop1], (msgnr:1 segnr:3)(line:1 pos:40 filepos:320)Thanks
My email id is [email protected]
Gaurav Garg
A brief update. After allowing a database exception to suspend several records, I found that eventually I did see the exception logged correctly when handled within the Scope shape exception handler. Since I can detect an Error, now I can at least inform someone there was a generic DB error so that the message(s) can be reprocessed later. I just need to find a way to cleanly handle each specific situation based on the exception message contents or exception type.
BizTron.
November 30, 2006 at 7:38 AM in reply to: SQL Adapter calling stored procedure that returns a number via a SELECT statement #16633Hey, is there a FOR XML AUTO, <ELEMENTS> at the end of the SELECT statement? Otherwise, BizTalk can't read it. For what you're doing, assuming you aren't passing too much into the proc, I'd just write a .NET component that calls the proc and returns the "int" back to the orchestration. For me personally, unless I'm returning a block of data from a stored proc, I prefer helper components that I can call from the orchestration.
Thanks for the reply!
When I use a message that have the namespace defined the mesage is processed:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE cXML SYSTEM "http://xml.cxml.org/schemas/cXML/1.1.008/cXML.dtd"[]>
<cXML version="1.0" timestamp="2006-11-28T17:59" payloadID="2006-11-28T17:[email protected]" xmlns="http://www.iba.ch/cxml">
<Header>In the schema I have defined a targetnamespace so BizTalk can process the schema:
<?xml version="1.0" encoding="utf-16"?>
<xs:schema xmlns:ns0="http://www.iba.ch/cxml" xmlns:b="http://schemas.microsoft.com/BizTalk/2003" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.iba.ch/cxml" elementFormDefault="qualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="xml.xsd"/>
<xs:annotation>
<xs:appinfo>
<references xmlns="http://schemas.microsoft.com/BizTalk/2003">
<reference targetNamespace="http://www.w3.org/XML/1998/namespace"/>
</references>
</xs:appinfo>
</xs:annotation>
<xs:element name="Name">…The message with the defined namespace maps to the message type http://www.iba.ch/cxml#cXML. The message without the namespace definition maps to the message type cXML.
So my question: is it possible to define a schema and a mesage based on this schama tha has no targetnamespace? What I have to define so that a message without a namespace can be processed by an orchestration?
Thanks Tom
Thanks for the reply
When I test the orchestration using an order that has the default namespace declared the message is processed.
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE cXML SYSTEM "http://xml.cxml.org/schemas/cXML/1.1.008/cXML.dtd"[]>
<cXML version="1.0" timestamp="2006-11-28T17:59" payloadID="2006-11-28T17:[email protected]" xmlns="http://www.iba.ch/cxml">
<Header> …In the cXML schema I have defined a target namespace because I think the schema has to have a targetnamespace for working properly in BizTalk:
<?xml version="1.0" encoding="utf-16"?>
<xs:schema xmlns:ns0="http://www.iba.ch/cxml" xmlns:b="http://schemas.microsoft.com/BizTalk/2003" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.iba.ch/cxml" elementFormDefault="qualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="xml.xsd"/>
<xs:annotation>
<xs:appinfo>
<references xmlns="http://schemas.microsoft.com/BizTalk/2003">
<reference targetNamespace="http://www.w3.org/XML/1998/namespace"/>
</references>
</xs:appinfo>
</xs:annotation>
<xs:element name="Name">So the message with the namespace is mapped to the message of type http://www.iba.ch/cxml#cXML which is processed by the orcetration.
The message without the namespace is mapped to the message of type cXML which is not processed.
So my question. How has the schema an the BizTalk message to be defined to be able to process a message without the namespace declaration?
Thanks Tom
November 30, 2006 at 5:26 AM in reply to: Using SQL Server 2005 Schemas With BizTalk 2006 SQL Send Adapter #16627I have the same problem. Anybody knows the answer or workaround of this problem?
November 30, 2006 at 4:40 AM in reply to: Call Receive pipeline in orchestration to debatch a flat file #16625Thanks, for your reply
The trailer contains the number of data lines and the source system. For example
Trailer, Sys1, 25
As a matter of fact the above line is from my data file.
November 30, 2006 at 1:47 AM in reply to: Where to implement functionality: Webservice or Orchestration? #16622If latency is a problem, then publishing your orchestration as a web service would cut out one step. The client would call the Biztalk web service directly, rather than going through a double hop
The error message indicates that the message has arrived at the message box, where there are no send ports or orchestrations subscribing to this message.
The pipeline has been completed, so the Xml Disassembler would have found a matching schema and assigned a message type to the message. This is where the namespace is used. It is quite valid to have a schema without a target namespace. And the fact that you are past the Xml Disassembler means it is not the lack of a namespace that is causing the problem
Are you able to view the subscriptions and also the message context of the failing message.
Are you routing on something other than message type and receive port. i.e. do you promote data from the cXml Header and use filters on an orchestration receive shape or send port?Is your orchestration/send port enlisted and started.
An easy test is to create a send port using the file adapter and set a filter of BTS.ReceivePortName = "your receive port name". Do you get a file created in the ouput directory
Hm, interesting. I will test this case this evening and will post the result tomorrow. If found a solution.
Does the namespace has to do something with the subscribers? Hm
The Web Service facade with an MSMQ backend to Biztalk would not be my first choice. If you decide to replace the Biztalk server you will need to re-engineer your facade to use a different back-end connection mechanism.
I would think about hosting the web services on the Biztalk server. If you changed Biztalk you would simply provide the same web service from the replacement system. The web service consumers would need know that the service provider had moved. This could be done with a manual update, or better still the use a directory of services, UDDI perhaps.
If you do use a facade, then I would use web services out the back as well. Use of the proprietary MSMQ will limit your future options or incur a major change to the facade. Have you investigated the WS-Addressing capabilities of WCF, which could make your facade basically a service router.Your generic orchestration concept seems to be reinventing the content based routing already available within Biztalk.
It would appear you have a generic service header containing a service tag. You could define a schema to just match this service header, promote the service tag and route using the pub/sub mechanism in Biztalk. Your service header would basically be an envelope around a message payload.
e.g.
<xs:element name=serviceHeader>
<xs:complexType>
<xs:attribute name="serviceTag"/>
<xs:any>
</xs:complexType>
</xs:element>If you put the routing functionality in the facade, then you are replacing existing functionalty in Biztalk, every new Biztalk application would require that you configure Biztalk and then the facade. You maintenance/support/operational costs will be higher
The request/response queues would work fine for a synchronous messaging model, how would handle an asynchronous model?
Hi!
Thanks for your input!
I need to route EDI files based on the SenderID and on the ReceiverID. First I tried with just two filters on the send port SenderID + ReceiverID, for some reason it didn't work (it should because both of these properties are promoted… but the base EDI adapter is full of surprises, for example routing failed messages doesn't work either : ( ), I could only route on either the sendID or the recID…
Unother advantage is that with dynamic ports I only have to use one receive port + locations for all the Partys and one dynamic send port … instead of having hundreds of receive and send ports …
Actually we are doing it in a generic catch all orchestration, we dont know the schema at all, because it is recieving messages on behalf of all the biztalk projects deployed. So we'd have a pass thru pipeline, with XmlDocument as the data type of the incoming message. My question was can we parse such a message inside the generic orchestration, we dont its schema, dont know how many tags are in there, what we know is the root node name, and that there is a service tag name in there, whose value we need to decide further processing?
Also I'd like to know from experts out there, that how if we not go for this generic orchestration, but rather deal this routing to right orchestration in the facade web service, in which we have service based queue pairs for each biztalk project, web service routes to appropriate queue after examining the service name passed to it. As the projects in biztalk grow the queue pairs would also grow, and perhaps would be difficult to manage. I'd like to see your thoughts on it…
Regards,
Sajid.
It could be your connections or a size limit. I think these are settings inside the Machine Config file or additional settings you need to add to the BizTalk Config file.
Not real sure if these would work for you.
Could also be a timeout or something wrong with the HTTP Address on the send port? Have you tried changing the timeout? I think that’s a property… it’s been a while since I looked at an HTTP Send.
You don’t have anything inside the message itself that can be used for routing? This would be a content based routing scenario. Typically, the message type (root node and namespace) are used for this purpose. But you can use any property you want to promote for message routing or use extended properties from the adapter like File Name or SOAP Headers.
If there is nothing inside the message then I’m not sure how either place would really be able to determine were the message goes.
Hope this helps.
-
AuthorPosts