how does TN find the Sender and Receive of a document submitted to it from the IS on XML documents?

I’ve used the wm.tn.doc.xml.recordToBizdoc to turn the document into a bizdoc, then I use wm.tn.submit and the transaction goes to TN and the content looks fine, but the sender and receiver are both unknown, so my processing rule doesn’t apply.

TIA.

Hello,
I think that you have to use the tn.recognize service to get the sender and receiver of the bizdoc. After that if you call submit, all should be well. Please step through your service to see things as the progess.
Good day.

Yemi Bedu

my problem is I don’t know where to set the sender and receiver INTO the bizdoc for when it goes out to TN. the only thing I do is pass a document into the recordToBizdoc service, then that service puts the bizdoc and the TN_parms onto the pipeline. my next service is tn.submit which just takes the bizdoc and submits it.

I’ve tried specifying the values of
/bizdoc/SenderID
and
/bizdoc/ReceiverID
on the pipeline out of the recordToBizdoc service, but I get a SQL exception:

INSERT statement conflicted with COLUMN FOREIGN KEY constraint ‘fk_ActLog_RelatedPtnrId_Ptnr’. The conflict occurred in database ‘wm6dev’, table ‘Partner’, column ‘PartnerID’.

do I specify something in the TN_parms input of the recordToBizdoc that will put the correct SenderID and ReceiverID into the bizdoc?

What you’re doing should work. From the TN BIS Reference description of recordToBizdoc:

“Transforms an IS document (IData object) into an XML document and sends the resulting XML document into the document recognition engine to translate the XML document into a business document.”

Later in the description:

“This service performs a function analogous to pub.xml:documentToXMLString.”

Based on this, this service converts your record to an XML string (are you providing the recordName parm) and then submits that string to the TN recognition engine–which will determine the doc type and do the extracts as indicated by the doc type.

Two possibilities come to mind: 1) the record isn’t complete, so the XML string doesn’t have the sender/receiver info for the doc type to extract; 2) the TN doc type isn’t configured to extract the sender/receiver. If the doc contains the sender/receiver info, you shouldn’t need to set them in the bizdoc–and I’m not sure doing so will do any good anyway as updating the bizdoc in the pipeline doesn’t update the TN db.

Can you confirm that these two items are okay?

If the doc doesn’t contain the sender/receiver, then you will indeed need to set the TN_parms parameter to set them. The TN User’s Guide has info on doing this.

everyone was probably under-estimating my n00bness. I had not even yet specified a Document Type in TN for this XML format. after poking around with that, I’m able to get TN to recognize the Document Type and the Receiver, but still need to find out how to match an element in the XML to the SenderID.

the xml is like so:

<Invoice>
<InvoiceHeader>
<InvoiceParty>
<Role>B</Role>
<Name1>[our customer’s name here]</Name1>
.
.
.
</InvoiceParty>
<InvoiceParty>
<Role>I</Role>
<Name1>RED MAN PIPE AND SUPPLY</Name1>
.
.
.
.

so there are multiple InvoiceParty elements, and the ‘Name1’ element under the InvoiceParty that has a child element ‘Role’ with a value of ‘I’ is the SenderID.

so, in the Extract I set the attribute to extract SenderID using this query:

/Invoice/InvoiceHeader/InvoiceParty[role=I]/Name1

to the build-in User Defined 1 which I now have set as the same as what was in Name1. but I get a query failed error:

Envelope query for SenderID of doctype XignInvoice failed to produce a result.

this is a valid XPath query, I think. is the TN xml querying language not XPath?!

note: I accidently had a lowercase ‘r’ on the role in the query, but after fixing that it still didn’t work. same error message.

The extraction mechanisms use XQL not XPath. Although they are close to equivalent, there are some differences (e.g. XQL uses 0-based array references while XPath is 1-based).

Put quotes around the I and it should work.

/Invoice/InvoiceHeader/InvoiceParty[Role=“I”]/Name1

You can try the query within TN Console to make sure it works. Edit your doc type in Console. Load a file containing XML conforming to your doc type. Put the query in the Query field, press the Test Query button and you should see the proper result in the Value field.

the quotes fixed it up, thanks! and actually, for strings, quotes are required in XPath as well.

but what is webMethods’s position on XQL? is it not the same as XQuery? and I know it’s not XPath…so that means it’s a proprietary, vendor-specific XML-querying language?!

WHEN are they going to get rid of it and use XPath or XQuery?

XQL isn’t wM-specific, though it has never been adopted as a standard by W3C either. WQL was the proprietary, wM-specific XML-querying language (and is still supported in the product). XQL is the predecessor to XQuery. XPath is a component of XQuery. A good reference for history is at [url=“IBM Developer”]IBM Developer. I’ve read elsewhere that XQL is essentially a subset of XPath.

Perhaps Advantage has some info on wM plans in this area?

Now I need to check for the SenderID and the ReceiveID in different places and match up to different ID types in TN.

specifically, I get…

9999999

or I might get

99999999999

this is on a PIDX Invoice. so if I set up a “PIDX Invoice” document type, I want it to first try to extract the SenderID with this query:

/pidx:Invoice/pidx:InvoiceProperties
/pidx:PartnerInformation[@partnerRoleIndicator=“Seller”]
/pidx:PartnerIdentifier[@partnerIdentifierIndicator=“DUNSNumber”]
matched to the “DUNS” built-in TN identifier. but if that doesn’t match anything, I want it to try this query:

/pidx:Invoice/pidx:InvoiceProperties /pidx:PartnerInformation[@partnerRoleIndicator=“RemitTo”] /pidx:PartnerIdentifier[@partnerIdentifierIndicator=“DUNSNumber”]
match to the “DUNS+4” built-in TN identifier.

how do I go about having it check multiple places for SenderID extraction from a document type? I tried adding a second “SenderID” attribute in the “Extract” tab, but it won’t let me add another one.

AFAIK, using the out-of-the-box facilities you can’t. You basically get one shot at extraction using the supplied doc attribute extraction facilities. (Someone please jump in here if I’m wrong).

What you could do is in your service that submits the doc to TN:

• Get the boundNode/xmlNode (or do xmlStringToXMLNode if needed)
• Use the queryXMLNode and wm.tn.profile:getInternalID to identify the partner as desired (look for “Seller” and if not found, look for “RemitTo”)
• Set the appropriate parms in the TN_parms structure to indicate which sender TN is to use.

This should do the trick.

that will work well on things I’m sending to TN from webMethods, but I’m also dealing with messages that will be sent to TN from trading partners, and a couple will use the same document type - PIDX Invoices.

if they send a PDIX invoice to our TN, some will give a DUNS number under RemitTo, or some may give a DUNS+4Number under Seller…I need to know which partner I’m dealing with to know which service to send the message off to, so I need to check multiple places for the sender before I send the message to a service.

Take a look at Sonam Chauhan’s e-Zine article [url=“wmusers.com”]wmusers.com for information on front-ending wm.tn:receive with your own entry service.

Having partners submit directly to wm.tn:receive has some issues. Have them submit to your receive service instead, then you can do what you need.

Rob,

Sounds like an XML gateway service in the same sense as a Flat File gateway service?

Would this service do it’s own authentication and call routeXML or would it call tn:receive?

Regards

Mark:

You’re exactly right that it the same sort of thing as what the FF adapter refers to as a gateway service.

The service can do its own authentication if desired or defer to wm.tn:receive. It all depends on the need. In Luke’s case, he’ll either need to trust that the log-in used to submit the doc is authorized to do so, or he can check it himself (does the logged-in user account match the sender indicated in the doc) or have wm.tn:receive do that.

Hi,
I want to use a FF gateway service. What should the varaibles be called under the TN_params record when using the routeFlatFile service if I need to extract the senderID, receiverID, documentID and also need to identify the document? Futhermore in which variable should I put the name of the gateway service as mentioned in the user guide?

Thanks in advance!

under TN_parms, I had to specify…

TN_parms/SenderID
TN_parms/ReceiverID
TN_parms/DoctypeName

only after I specified DoctypeName did it successfully get the SenderID and ReceiverID. I don’t quite understand everything about it yet, but I needed to get it done, so that’s how I did it.

Hi,

I have a similar problem. I have a gateway service trying to send xmls to TN by using the service RouteXML service. I cannot send the senderId and the receiverID as part of the xml document itself as my DTDs do not support these tags. Hence I have to send these as part of the TN_parms. When I try to send these as TN_parms/SenderID and TN_parms/ReceiverID, the document identification fails in the TN. I tried to extract these paramters in the attributestoExtract in the extract tab but the problem still persists.
Has anybody faced a similar problem?
Is there another way in which I can send the senderID and the receiverId to the TN and identify a document against these paramters?

thanks in advance,

TNParams/with sender/receiver/doctype info works only when you use routeFlatFile service…routeXML works litt differently it takes only node object.

But somehow you have to include sender/receiver place holders in your xml structure before you route it to TN for recognizing.

HTH,
RMG