I had configured a TPA for implementing PIP 3A4 V2R2. All worked well, and I could send transactions to TN, which would identify the doc, the TPA, and hand it off to the PRT to run the appropriate model. I then modified the TPA parameters, such as enabling signatures and the like, however, didn’t change the sender or receiver or Agreement ID of the TPA. Now whenever I send in a PIP 3A4 PO, it just sits in TN, with an error in the logs stating :
If I do a SavePipeline/RestorePipeline on the receive service and pull out the sender/receiver/bizDocType, and run the wm.tn.tpa:getTPA, I see the TPA just fine. Any suggestions? Deleting the TPA and recreating offers no resolution.
1.) make sure you have only 1 TPA for same sender, Receiver and document.
2.) make usre all your settings in Agreement with UserParameters are correct including TransportName and others.
3.) Make usre you have only 1 DOC type with that specific root tag.
4.) in the Model in “Wait for external Request Doc” in the properties–>Publish/subscribe filer add the sender and receive condition. (it will not cause a problem but might help you to determine the DOC for specific Partner and PRT.
Verified. Originally, I had just used the defaults from duplicating the TPA then changing the Sender/Receiver and TransportType, so I believe they are correct.
Verified.
I went ahead and added the filters, and rebuilt the model. One of the steps here seems to have resolved issue. It is now processing the documents. Thanks.
Verified.
I appreciate it. One other question, and I should probably open a new thread, but when I turn on the certificate sigs and use profile sigs, all seems to work well, however, when I send the RA back to the Buyer, Monitor shows I received an HTTP 200 and that the RA was successfully sent (and the Buyer also verifies receiving it successfully), however, my process model just hangs. I’m using the model that was provided (2 way pip) and there is an sendFailed=Yes/else transitions on the step, but I cannot seem to get the model to continue. Any suggestions.
Are you initiator or responder?
What RNIF you are using?
what version of PIP.
What version of WM?? 6.1?? or 6.0.1 or 4.6?
1.) check the conversation ID of RA in TN.
2.) Did you change anything in the SendRa step in the model when you import it?
I think you are initiator and sending the RA for PIP3A4Confirmation Document and it should be last document in the trasaction. If you turn on the auditing and look at the server logs you may get any clue on whats going on??
are you sure that the RA is not failing validation?
In this instance, we are the responder, sending the RA for PIP3A4PurchaseOrderRequest. We are using RNIF 2.0, PIP 3A4 V02.02, and using webMethods 6.0.1.
The ConversationID for the RA matches the PO:
<dunsid>-PIDRN10894017612310000429-Seller
I did make some changes (after receiving this error, however, I re-imported the provided sample, and the two sendReceiptAck services are now identical in their properties.
According to the TPA, we are not validating outbound documents, and the initiator of the PO has received the RA successfully. The activity log for the sendReceiptAck step from monitor states (actual data in <tags>):
In service wm.ip.trp:http: HTTP post to URL https://<url>[ESIPRT.000020.000016]
In service wm.ip.trp:http: Data using protocol https posted successfully. The response code was 200 [ESIPRT.000020.000018]
In service wm.ip.cm.handlers:sendReceiptAck: Receipt Acknowledgement has been sent to trading partner - <duns> [ESIPRT.000020.000024]
I will turn the server log up to a higher level, it is currently set to 4 and see if anything looks out of the ordinary.
OK I am right now doing the same process but in 6.1. Try this.
Turn the Validation ON and than send the RA to partner see if it fails or passes the validation on partner’s side. one of the problem I found in the 6.1 Documents.
This is the Email to webM
We are seeing an issue with RNIF20 when recieving a PIP3A4 from our trading partner.
Thanks for the update. I tried that, but with little success. However, I turned up the server log (to level 5) and received the following, after the other messages (previously stated):
[4682]2004-07-09 17:12:10 CDT [PRT.0101.0024V1] *** Error trying to encode the pipeline for step-level audit logging on step N8: {2}
What do you make of this one?
Thanks for offering to take this offline. I may take you up on that, especially if we have further issues.
put a SavePipeLinefromfile in the service called by N8. (not in the PRT package but in the service called by service invoked in Send Ra step. Run a test and than start the service from the developer with Restorepipline and see what do you get in the pipeline. you may have wrong pipeline or you might have an RA DOC on your webM envirnment different than what partner is having. you sure there is nothing in server logs? just a question.
Put a SavePipeLineFromFile in the wm.ip.cm.handlers:sendReceiptAck, and all looks fine. After the send, it branches on sendFailed (yes/no), and executes ‘no’, which is fine.
I turned up the server logs from 5 to 7, and it provided more information:
[19899]2004-07-12 09:39:13 CDT [PRT.0101.0057V2] *** Error encoding pipeline for transition from N8 to N10: iaik.asn1.structures.AlgorithmID
…
[19897]2004-07-12 09:39:12 CDT [PRT.0101.0024V1] *** Error trying to encode the pipeline for step-level audit logging on step N8: {2}
Did you change the transaition step in the properties where you send the RA?
Usually if you don’t have the send completed sucessfully it does not go any further and stay at send RA for sometimes. as far as this message is concerend it is complaining about the Auditing. are you dropping some TPA values in the pipeline somewhere in your mapping?
The only change to the transition steps on send RA is the one for handling exceptions (which I just added today). Not dropping any TPA values in the pipeline on any of the flow services called. Attached is what model looks like during execution. No changes were made to the send RA service except for the labels, flow service names, and the document subscription. Other than that, the services are as they were loaded from the 2 Action Pip provided by webMethods.
Just an update, an email on the Advantage site allowed us to find a work-around for this issue. Basically, on our step service which sends the RecieptAck, we performed a clearPipeline, and preserved only the necessary variables (documents, parameters, sendFailed, sendErrorMessage, TPA, userDocument, etc.). Once this was in place, the model continues without error. We have only encountered this problem when using SSL.
Thanks RosettaNetConsultant for helping troubleshoot as well.
just a question.