SOAP request issues

Further to this, did a check on 'ERROR-STATUS:NUM-MESSAGES' which came back as '1', set up a do-loop to print all error messages to the log file and the only error message it returned was the 1 above which says the 'SOAP faultstring is: Fault' (same error number).

You can use the ERROR-STATUS:ERROR-OBJECT-DETAIL and ERROR-STATUS:ERROR-OBJECT-DETAIL:SOAP-FAULT-DETAIL handles. Just note the GET-SERIALIZED() method returns a LONGCHAR.

     IF VALID-HANDLE(ERROR-STATUS:ERROR-OBJECT-DETAIL) AND VALID-HANDLE(ERROR-STATUS:ERROR-OBJECT-DETAIL:SOAP-FAULT-DETAIL) THEN

       DO:

         cSOAPResponse = ERROR-STATUS:ERROR-OBJECT-DETAIL:SOAP-FAULT-DETAIL:GET-SERIALIZED().

         ... handle the error ...

         END.

In one of our cases the actual error is within a <message> tag inside cSOAPResponse, so we simply strip that error message out and return that as an error.

Except that 'ERROR-STATUS:ERROR-OBJECT-DETAIL:SOAP-FAULT-DETAIL' for some reason is Unknown (?), and when I try and access it it comes back with:

Lead attributes in a chained-attribute expression (a:b:c) must be type HANDLE or a user-defined type and valid (not UNKNOWN). (10068)

ERROR-OBJECT-DETAIL is a valid handle

SOAP-FAULT-DETAIL for some reason is not

When I asked the 3rd party if my SOAP request was working or not, their developer went into the logfiles for the web service and came back with the following:

500 Internal Server Error

Content-Length: 433

Content-Type: text/xml; charset=utf-8

<?xml version='1.0' encoding='UTF-8'?>

<senv:Envelope xmlns:senv="schemas.xmlsoap.org/.../">

 <senv:Body>

   <senv:Fault>

     <faultcode>Error message about why my SOAP request failed.</faultcode>

     <faultstring>Fault</faultstring>

     <faultactor></faultactor>

   </senv:Fault>

 </senv:Body>

</senv:Envelope>

When I do: ERROR-STATUS:ERROR-OBJECT-DETAIL:SOAP-FAULT-CODE it comes back as 'Undefined'.

The error message for the SOAP-FAULT is

Web service operation <operation-name> generated a SOAP Fault. SOAP faultstring is: <fault-string> (11506)

And that is what you will always get from the ERROR-STATUS messages.

Your operation is “VerifyOrder”

And your string is “Fault” which matches

  <faultstring>Fault</faultstring>

In the xml you included above.

Thus, you are getting:

"Web service operation VerifyOrder generated a SOAP Fault. SOAP faultstring is: Fault (11506)"

The ERROR-OBJECT-DETAIL that you are getting back should be a SOAP-FAULT object. That you are describing as being valid. The issue that you are seeing is that there is no SOAP-FAULT-DETAIL attached to the SOAP-FAULT. Looking at what you included above it is likely because the SOAP-FAULT is very simple.

Examine the SOAP-FAULT itself and ensure that it corresponds to the details in the message provided by the 3rd party developer above.

How would I do that though? The faultcode provides me all the information I need in order to work out why my SOAP requests aren't working, however after spending hours searching the net and going through the documentation I cannot work out how to get the exact faultcode.

When I do: SOAP-FAULT-CODE it comes back as 'Undefined', which tells me nothing, The 'SOAP-TYPE' comes back 'SOAP-FAULT", faultstring comes back 'Fault', but nothing gives me the exact message that was in the logfile the 3rd party developer sent to me.

It appears to me that this is due to the limited information that is being returned to you. If that is all that the web service returns then that is all that we can give you. The SOAP-FAULT itself has very little information.

The entire message is:

<?xml version='1.0' encoding='UTF-8'?>

<senv:Envelope xmlns:senv="schemas.xmlsoap.org/.../">

 <senv:Body>

   <senv:Fault>

     <faultcode>senv:Hash Mismatch.  Hashed fields='||19.00|123456|123|R17|2016-06-09T13:28:41Z||209.00|1||162.60|1.|184.20||0.|2||23.20|2.|33.50||0.'</faultcode>

     <faultstring>Fault</faultstring>

     <faultactor></faultactor>

   </senv:Fault>

 </senv:Body>

</senv:Envelope>

Is there any way I can just access that raw xml? Because without any of this I will have to keep going back to them and asking them why it isn't working, there web service is responding with the exact information I need to be able to work out why my SOAP request itself isn't working it just appears that the 4GL code is unable for some reason to extract out the correct value from <faultcode>.

Resolved this by updating my $DLC/properties/transport.xml file so that it dumps the messages into a chttp.in and chttp.out file, I now have full access to the original messages before the ABL ever sees them.

For the record, these are the methods we recommend when using HTTP(S).

For HTTP communication:

knowledgebase.progress.com/.../P120871

For HTTPS communication:

1) Configure the OpenEdge client to dump the HTTPS messages as documented in the following KBase article:

knowledgebase.progress.com/.../P191993

2) You can use Telerik Fiddler as follows:

- Download and install Fiddler: www.fiddler2.com/.../

- Go to the Tools menu -> Fiddler Options ...

- Go to the HTTPS tab and activate both "Capture HTTPS CONNECTs" and "Decrypt HTTPS traffic ... from all processes".

- Click on the "Actions" button and select "Export Root Certificate to Desktop" button.

- If needed change the listen port in the Connections tab.

- If Fiddler is being installed on a different machine, then in the Connections tab, select "Allow remote computers to connect" (a restart of Fiddler is required).

- Import the Fiddler certificate into the OpenEdge client via a Proenv session: certutil -format DER -import <full_path>\FiddlerRoot.cer

- Start the OE client using the parameters -proxyhost <host where Fiddler is running> and -proxyport 8888 .

- Call the Web Service and review the HTTP messages within the Inspectors tab in the right panel (Raw mode).

Fiddler is no good for me in this instance as i'm working on a remote linux machine. Also have to continue to use AppBuilder (now and into the future for a long time) as we use ps:escript with webspeed and I need the AppBuilder for its remote management mode (the spiderweb looking button on it) and to access the ps:escript explorer and ps:escript editor.

Prosoapview didn't work for me for whatever reason (again probably because I was using a remote linux machine), I set up Xming on my windows computer, set up putty for x11 forwarding, told my development agent to use proxyhost and proxyport but it never received anything (for some reason it couldn't detect that prosoapview was actually spying on the traffic and so refused to even make the SOAP request).

What basically worked for me is the HTTPS communication KB article, but instead of setting it on the 'https' transport I set it on the 'http' transport since the 3rd parties webservice is over HTTP (don't ask...).