Hi,

I am getting below error processing the X12 Envelope.

“The user that posted this document (Default) could not be associated with a partner to check their identity.”

Even though the X12 Group and the transaction set is processed successfully. but X12 Envelope Aborts.

When I resubmits it from the TN, it works, only fails if submitted from the client.

How is the partner getting it posted via https to your gateway service?

Also did you set rule for Envelope level processing?

HTH,
RMG

Partner does http post to the gateway service, which submits EDI to TN using wm.tn:receive.

Yes there are rules for all other EDI
-Process X12Envelop ( Action: change User Status) - Fails
-Proces X12Group ( Action: change User Status) - Works fine.

• Custom Processing rule (Action: invokes service and change status) - Works fine.

Does the TP associated did submit credentials with the request?

See below:
[url]http://advantage.webmethods.com/article/?id=SR-1-48800711[/url]
webMethods Closure Summary:

Trading Networks does require partners to have a B2B user account that is a member of the TNPartners group. Before exchanging documents, the B2B user account does have to match with the DUNS value of the External ID in TN in order to recognize its partners. Also we need to keep in mind, the user name and password are case sensitive. Therefore, if your customer is RichProd, and the B2B user account is username = RICHPROD & password = popo, the SenderID and DUNS cannot be something else.

In short, the DUNS and SenderID has to match with the B2B user account to give partner authority.

If we invoke wm.tn:receive service as part of your EDIINT transaction. This receive service calls submit which calls checkUser. This checkUser service was causing the problem.
Either you can disable the checkUser call within submit service in order to have your transaction to go through. For a cleaner and recommended solution it is recommended to use routeXML instead of receive.

The request comes from our Portal, so there can be multiple Users. The EDI did not contain any useID or password.

In my TN we have defined the TP with only Mutually Defined ID. and that is there in the EDI Request as a senderID.

In that case of not external TP,you may have to try alternatives to use routeXML or set the receive to Anonymous or disable checkUser suggested above and either of these changes should help:

HTH,
RMG

look into your error:
“The user that posted this document (Default) could not be associated with a partner to check their identity.”

The user “Default” is used when the client is not doing proper authentication. To avoid going to the business of create your own service, you can create a username that matches with one of the TN ID of this sender (DUNS number for example), then ask the client try to authenticate with this user.

I agree with tongwang and another possible solution: