Has anybody integrated APIGEE and EMVO successfully? I am trying to connect with EMVO HUB with straight pass through and got below response

[latheefdudakula]

Has anybody integrated APIGEE and EMVO successfully?

I am trying to connect with EMVO HUB with straight pass through and got below response.Can somebody help us to resolve this.

------------------

Return Code: 500

	<u:Created>2018-05-08T15:02:32.704Z</u:Created><u:Expires>2018-05-08T15:07:32.704Z</u:Expires></u:Timestamp>}]actions[32, 4, 2] May 08, 2018 10:02:34 AM com.sun.xml.internal.messaging.saaj.soap.ver1_2.Fault1_2Impl checkIfStandardFaultCode <u:Created>2018-05-08T15:02:32.704Z</u:Created><u:Expires>2018-05-08T15:07:32.704Z</u:Expires></u:Timestamp>}]actions[32, 4, 2] May 08, 2018 10:02:34 AM com.sun.xml.internal.messaging.saaj.soap.ver1_2.Fault1_2Impl checkIfStandardFaultCode SEVERE: SAAJ0435: Sender is not a standard Code value May 08, 2018 10:02:34 AM com.sun.xml.internal.messaging.saaj.soap.impl.FaultImpl setFaultCode SEVERE: SAAJ0140: Empty/Null NamespaceURI specified for faultCode fc1:Sender May 08, 2018 10:02:34 AM DemoOrganisation.emvs.client.ProductServiceMAHClient main SEVERE: null java.lang.reflect.UndeclaredThrowableException at com.sun.proxy.$Proxy54.processProductMasterData(Unknown Source) at DemoOrganisation.emvs.client.ProductServiceMAHTester.sendProcessProductMasterDataMessage(ProductServiceMAHTester.java:238) at DemoOrganisation.emvs.client.ProductServiceMAHClient.main(ProductServiceMAHClient.java:103) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:291) at java.lang.Thread.run(Thread.java:745) Caused by: com.sun.xml.internal.messaging.saaj.SOAPExceptionImpl: Empty/Null NamespaceURI specified for faultCode "fc1:Sender" at com.sun.xml.internal.messaging.saaj.soap.impl.FaultImpl.setFaultCode(FaultImpl.java:119) at com.sun.xml.internal.messaging.saaj.soap.impl.FaultImpl.setFaultCode(FaultImpl.java:87) at org.apache.cxf.binding.soap.saaj.SAAJUtils.setFaultCode(SAAJUtils.java:65) at org.apache.cxf.jaxws.JaxWsClientProxy.createSoapFault(JaxWsClientProxy.java:226) at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:154) ... 9 more DemoOrganisation.emvs.client.ProductServiceMAHClient main SEVERE: null java.lang.reflect.UndeclaredThrowableException at com.sun.proxy.$Proxy54.processProductMasterData(Unknown Source) at DemoOrganisation.emvs.client.ProductServiceMAHTester.sendProcessProductMasterDataMessage(ProductServiceMAHTester.java:238) at DemoOrganisation.emvs.client.ProductServiceMAHClient.main(ProductServiceMAHClient.java:103) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:291) at java.lang.Thread.run(Thread.java:745) Caused by: com.sun.xml.internal.messaging.saaj.SOAPExceptionImpl: Empty/Null NamespaceURI specified for faultCode "fc1:Sender" at com.sun.xml.internal.messaging.saaj.soap.impl.FaultImpl.setFaultCode(FaultImpl.java:119) at com.sun.xml.internal.messaging.saaj.soap.impl.FaultImpl.setFaultCode(FaultImpl.java:87) at org.apache.cxf.binding.soap.saaj.SAAJUtils.setFaultCode(SAAJUtils.java:65) at org.apache.cxf.jaxws.JaxWsClientProxy.createSoapFault(JaxWsClientProxy.java:226) at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:154) ... 9 more

[dchiesa1]

I think the error you are showing me is from a SOAP client running in Java, that depends on CXF.

This part of the error message:

SEVERE: SAAJ0435: Sender is not a standard Code

...is apparently due to a bug in CXF that was present prior to version 3.1.7.

It happens when there is any fault on the backend (for example, the signature cannot be verified), and a SOAP fault is sent back. The CXF client can then incorrectly handle that SOAP Fault.

So actually there are two problems:

• problem 1: something is causing the backend to return a SOAP Fault
• problem 2: the CXF runtime is incorrectly processing the SOAP Fault , resulting in "SAAJ0435"

Problem #2 is obscuring problem #1. First solve Problem #2, then you will have some better insight into Problem #1 (you will correctly see the SOAP fault). Then you can try solving Problem #1.

[rmishra]

In regards to Problem 2, check the namespace for the prefix "fc1", it should belong to the Soap Envelop Namespace. I think either the server sent Soap Message is invalid (lacking namespaces) or your client library is not populating the namespace prefix-url mapping correctly.

A quick way to diagnose this (server issue or client issue) could be by calling the Soap API directly using Soap UI and verifying if you can replicate the Soap Fault

[latheefdudakula]

Thanks @Dino-at-Google for response.

We use apache-cxf-3.1.8 and not 3.1.7 or below , so there is no bug and no issue coming out of CXF version.

When we hit target EMVO directly , there is no issue and we receive success HTTP status code as 200.

However, when we proxy through APIGEE that is when we ran to the error mentioned in earlier thread