Incorrect handling of partner ID's ?!

Hello everyone! :slight_smile:

I’m currently having a test on webMethods (v6.1) to learn the main concepts.
And there seems to be a bug in handling of partner IDs which is quite annoying.

I’ve got two trading partners:

  • the “Enterprise” called “NewCo” - has an “External ID” of type “DUNS” and value “11-111-1111”;
  • the trading partner called “NewCo ClientA” - has an “External ID” of type “DUNS” and value “88-888-8888”;

Well, I’ve also created a Document Type entitled “PORequest” from an test XML file, which represents communication file from a “sender” to a “receiver”.
I extract three attributes with following XQL queries:

  • /PurchaseOrderRequest[0]/fromRole[0]/PartnerRoleDescription[0]/DUNS[0] which gives me 88-888-8888 with my test XML file - I associated it with system variable “SenderID”;
  • /PurchaseOrderRequest[0]/toRole[0]/PartnerRoleDescription[0]/DUNS[0] which gives me 11-111-1111 with my test XML file - I associated it with system variable “ReceiverID”;
  • /PurchaseOrderRequest[0]/thisDocumentIdentifier[0]/ProprietaryDocumentIdentifier[0] which gives me 000012569 with my test file - provided just for information here.

Then, I create a Processing Rule to handle this document and call a service of mine;

  • Rule name: HandlePO
  • Sender (selected): NewCo ClientA
  • Receiver: Enterprise (NewCo)
  • Document Type (selected): PORequest
  • Actions:
  • Execute a service:
  • Change User Status: PROCESSED

Finally, I test my rule, either by the green test mark in the TN Console, or via the TN Web Manager ([URL=“http://localhost:5555/WmTNWeb/”]http://localhost:5555/WmTNWeb/[/URL]): it doesn’t work, the document is correctly recognized as a PORequest, but sender & receiver are not recognized, although the values are correctly extracted from the (test) XML file (i.e. 88-888-8888 for the sender, and 11-111-1111 for the receiver) but the Default rule is used (Sender: Any/ Receiver: Any) and User Status is set to “IGNORED”.

After submitting through the TNWeb interface, I checked in the Transaction Analysis View in TN Console and the Activity Log for the corresponding transaction says:

  • for column “Class”: value = Sender
    => The value originally supplied as sender ID for this document was not a valid partner ID. The value was 88-888-8888.
  • for column “Class”: value = Receiver
    => The value originally supplied as receiver ID for this document was not a valid partner ID. The value was 11-111-1111.
    Well, the “DUNS” external ID are extracted but TN does not match them as “Partner ID” of any of the trading partners (“NewCo” or “NewCo ClientA”).

I finally had a look in the database where webMethods saves all its data, and particularly at the table PARTNERID. I have two records:
PARTNERIDID = kvtqaj002ip0gp8s0000000f
INTERNALID = kvtqaj002ip0gnv80000000a
EXTERNALID = 11-111-1111
PARTNERIDID = kvtqaj002iqu38ej0000002i
INTERNALID = kvtqaj002iqu38720000002e
EXTERNALID = 88-888-8888

I tried to use the corresponding value of “INTERNALID” to replace the value 11-111-1111 (resp. 88-888-8888) in my test XML file… and IT WORKED!!! The partners are correctly recognized.
I still can’t understand why it’s not the External ID that is used, but it’s obviously a bug or… I missed some config somewhere I wasn’t advised to !!! :sad:

Did someone already encounter this? Do you know how to fix this? :o

Note: it seems someone in my training class had success with all this, and without changing values, but I still don’t know why/how!!?

Thanks for your attention!

“And there seems to be a bug in handling of partner IDs which is quite annoying.”

Be careful about claiming to have found a “bug”–especially when you point out your own noobiness!

When defining the attributes to extract, what transformation did you specify for the sender and receiver? Based on what you’ve posted, it should be DUNS. If it isn’t, that’s why there isn’t a match. It uses the number extracted from the doc, the type you’re saying that it is in the “transformation” setting and compares that with the external IDs of the same time in the profiles. Thus, if the transformation indicates DUNS+4, it will never, ever match external IDs in profiles that are DUNS.

If your transformation is DUNS, then we need to investigate further.

Thanks for your answer. :slight_smile:

When you first talked about “transformation”, I didn’t really understand what you mean. So I looked again at the Document Type definition, especially in the details of the Attribute extraction, and then found this so-called “Transformation”.

Effectively nothing was specified here, while I should probably have selected the External ID type from the drop-down list. But in my training document (which deals with the previous version… webMethods 6.0 :frowning: ) the term “Transformation” was not used… just “Detail” and the value was “DUNS”, and I didn’t imagine some kind of “transformation” was needed for the extracted value. We all learn from errors.

You pointed out that I should not allege some “bug” so quickly, but it seems there is effectively one, when testing Document Types and Processing Rules using XML test file through the TN Console.
While using the TN Web ([URL=“http://localhost:5555/WmTNWeb/”]http://localhost:5555/WmTNWeb/[/URL]) there is no problem, the document is recognized

which processing rule is it getting selected when you go for “green test mark” in “Processing rules”? - I believe you have done this for document type recognition only!
If it’s the default rule(it should be) which gets selected, then it’s clearly a problem in combination of sender/receiver/documenttype selection!
Since the combination of this is already given(by the details in the query), I believe it’s the data[SenderID and receiverID in the document] which may be a problem!

Change “should probably have” to “must” and you’re on the right track. :slight_smile:

“Transformation” is indeed an odd term.

Can you elaborate?

Check my answer here: :wink:


I am facing a similar issue. I am getting the below error while trying to recognize the senderID and receiver ID. The external IDs are getting picked up successfully from xml.

The value originally supplied as sender ID for this document was not a valid partner ID. The value was .

I checked the TN db and the values are intact in the partner and partnerId tables. The internal id is valid.

This issue happened only while deploying to production (4 nodes) and no issues while promoting to Test (1 node).