Question
JPMC
US
Last activity: 24 Sep 2019 15:48 EDT
Connect SOAP calls are failing after the service provider migrated to cloud
Hello,
Our service provider migrated to cloud and the only change on our application end is updating service end-point urls. This change did not work for us initially but after the service provider fixed all their issues with external doc references in the WSDL URL, we were able to invoke all the services.
A week later, they applied a fix to send attachments as URLs instead of binary data to all the clients.For this, they enabled MTOM as a result of which the message headers were changed. Post this fix, we were getting the exceptions that we initially got on invoking the services. One is a null pointer exception with no response in the soap envelope. And no other additional details in the log even after enabling debug mode for the 5 loggers. Second is a prolog error on one of the service and this service response is captured in our logs. But, there are no additional details on what could be causing the issue. We are on PEGA 6.1 SP2. Could you please give us clues or ideas on why the services would fail if the service provider enabled MTOM?
We also tried to consume the WSDLs instead of directly updating the end-point urls but this failed with a null pointer exception in GenerateconnectorRules for all the existing methods. On further research, we found that it is an existing issue.The root cause of this problem is a defect in Pegasystems’ code/rules. The issue occurs when the system is attempting to locate an output operation element in the WSDL which, in the case of a one-way WSDL, does not exist.
Hello,
Our service provider migrated to cloud and the only change on our application end is updating service end-point urls. This change did not work for us initially but after the service provider fixed all their issues with external doc references in the WSDL URL, we were able to invoke all the services.
A week later, they applied a fix to send attachments as URLs instead of binary data to all the clients.For this, they enabled MTOM as a result of which the message headers were changed. Post this fix, we were getting the exceptions that we initially got on invoking the services. One is a null pointer exception with no response in the soap envelope. And no other additional details in the log even after enabling debug mode for the 5 loggers. Second is a prolog error on one of the service and this service response is captured in our logs. But, there are no additional details on what could be causing the issue. We are on PEGA 6.1 SP2. Could you please give us clues or ideas on why the services would fail if the service provider enabled MTOM?
We also tried to consume the WSDLs instead of directly updating the end-point urls but this failed with a null pointer exception in GenerateconnectorRules for all the existing methods. On further research, we found that it is an existing issue.The root cause of this problem is a defect in Pegasystems’ code/rules. The issue occurs when the system is attempting to locate an output operation element in the WSDL which, in the case of a one-way WSDL, does not exist.
***Edited by Moderator Marissa to update SR Details***
Accepted Solution
Pegasystems Inc.
US
Upon reviewing the associated Support Request, the resolution found was:
Perform the following local-change:
1. Remove the new endpoind to old and run the connector activity.
2. Switch back to new end point and save the connector rule.
JPMC
US
Hello,
We are on PEGA 6.1 SP2. And, i am getting the correct response in SOAP UI. For that matter, i am getting the response if i call from PEGA too, but invokeaxis2 is failing at invoke web service step as PEGA is not able to read the SOAP response.
If the service provider disabled MTOM, Connect calls are working without any exception. But, when they enable MTOM, PEGA is failing. Since the SOAP response for both the services is exactly the same, we are suspecting that something in the message headers is preventing PEGA from parsing the response. But, we are not able to identify that something so far. PEGA support has also been working on it from couple of weeks.
Regards,
Sravya
Pegasystems Inc.
IN
Hi Sravya,
Please let us know the SR# on which this is being worked upon by the Pega Support team. This will help us tag the 2 troubleshooting items and continue tracking.
Regards,
JPMC
US
Hello,
After extensive research, i was able to determine the root cause but i do not have a solution yet. I probed into the raw response and realized that PEGA is treating everything starting from MIME boundary(------=Part_4543654435) as content. But, this should rather fall under http header. The content should actually start with <SOAP-ENV:Envelope......> . This is why i get the error unexpected char '-' at ro[1] col[1], expected '<'. On the old services, the boundary format was like --MimeBoundary_45435435 and it was being considered as header itself. I have no clues on why PEGA is treating this new part boundary as content. I opened SR-D32328 .
Regards,
Sravya
Accepted Solution
Pegasystems Inc.
US
Upon reviewing the associated Support Request, the resolution found was:
Perform the following local-change:
1. Remove the new endpoind to old and run the connector activity.
2. Switch back to new end point and save the connector rule.