We have a partner that up until now has used only one DUNS. The certificate we imported into ISadmin is mapped to the original DUNS (ex. 111111111). The partner wants to use an additional DUNS to transmit RN messages (222222222). The RN transaction passes the SSL, and a process model kicks off but fails at the ‘Wait for External Request Document’ . The following error is written to the server log :
User 111111111 (partnerID=50021k0011a2cfb700000021) is not an administrator and attempted to retrieve a document (docID=50021k0022t9hr2g00003tdn) that does not belong to him.
Apparently since the same client cert is being used, the partner (transaction using the new DUNS will still be logged in under the DUNS mapped to the certificate. webMethods support has indicated that each DUNS will need a separate certificate.
Has anyone had to resolve a similar situation, and can suggest a work around?
I don’t know your context or what an RN is, but since certificates are used for authentication, each can only map to one DUNS at a time. Another workaround is be having the second set of message transmissions authenticate with HTTP Basic Authentication (username: 222222222/password: xxxx) instead of certificates.
Or perhaps this: store the document when it is first received, then initiate the process flow as Administrator. I have no idea how this can be done though, and it’s quite insecure.
We faced same issues dealing with a trading partner who was using two separate DUNS but the same certificate for the RN (RosettaNet) PIPS. Since in our case, the TP needed to handle the data differently based on the DUNS, I ended up devising a work around in which we always used same DUNS (say 111111111) in the header, but in the contents (i.e. toRole) we used different DUNS (111111111 or 222222222) based on who the data was intended for. This way, in our TN we use only one profile for the TP (the one with DUNS 111111111) but map the toRole differently and the TP’s services handle the data appropriately.
Your scenario may be different and the above solution may not be applicable… but just in case…
Thank you…I think your workaround is ideal. Yes, I believe as long as the DUNS in the DeliveryHeader of the RN PIP remains the same as mapped on the Cert…it should be okay. The fromRole, can be any DUNS, as it is referenced in mapping/flows.
