Correction to “Recreated in core” entry above….

PLSQL_REST_SENDER_API actually does exist in internal environments.  Assistance from a developer would be needed to set up such a call to attempt to recreate the result noted by the customer.

@Anne Fernando , @Sampath Sitinamaluwa, @Kasun Alahakoon and @Minura De Silva - would this matter be considered as data / workflow issue?

@Eugene Wager In REST type routing addresses, there is a field to define the ‘Http Method’. In this situation please verify the relevant routing address and check whether the Http Method is defined as ‘PATCH’. The http method defined in the routing address overrides the parameter value given to the method. 

@Anne Fernando  - I’ve logged into the mws of the affected customer (a cloud customer, fyi).  In the relevant Routing Address entry I see HTTP Method of “PATCH”.  If I understand your response of last month correctly then PATCH should be the value which is passed to this REST API call, correct?  Please confirm. 

Is there any other condition or configuration which might override this value for HTTP Method?  If not I suspect I may need to have the customer in question check the receiving end of this interface to confirm whether or not the message being sent to the 3rd party by IFS is actually passed with HTTP Method’s value as “PATCH”. 

Hi @udlelk Can you please help with this question. As @Eugene Wager has mentioned the routing address contains the Http method ‘PATCH’ but the request sent as ‘POST’. Thanks, Anne. 

HTTP Method in REST Type Routing Address can be set in two ways. One way is in Routing Address Configurations. And the other way is in Pl/SQL code when using plsql_rest_sender_api. 

If the HTTP method set in both places then the priority will be given to the value sent from PL/SQL side.

Please refer the tech doc: https://docs.ifs.com/techdocs/Foundation1/040_administration/240_integration/300_ifs_connect/010_configure_connect/060_transport_connectors/configure_rest_transport_connector.htm (Under the topic How to call a REST endpoint using REST Connector → Request Method

Thank you @UDLELK.  I’ve reviewed the document referenced in your previous reply.  In it I noted how ‘PATCH’ may be specified as a parameter - and also how ‘POST’ would be used if no value for HTTP_Method were to be specified by Routing Address or by PLSQL code.  

Is it possible that this customer’s PLSQL code is somehow not working as intended and therefore is defaulting to POST?  If so, how could we troubleshoot or monitor this process to find out.  The customer claims to have set up an Event Action for their process and has sent a screen shot for it.  They have also created some Routing Addresses.  I’ve attached each of these documents here.

A related question - is it also possible that none of the Routing Addresses attached here are being triggered or referenced by the customer’s process?  If yes, what should be checked to confirm whether or not these settings have been configured correctly and are being used by our customer’s process?  If a shared session would help please so state in the reply.  

@Anne Fernando  - This customer has been awaiting our response for this problem since November 2021.  I suspect we may have a bug here.  Could you help escalate this issue to R&D please?  Thanks - Eugene W.

Replied to @Eugene Wager on reporting this to RnD. 

Hi,

I’m almost certain in APPS10 that PATCH requests are sent as POST requests. It just includes an extra header as shown below:

x-http-method-override:PATCH

I changed my routing address to use postman echo to determine this and debug what was being send for the headers and body: 

https://postman-echo.com/post & https://postman-echo.com/patch

(patch requests from ifs only worked on the /post endpoint)

Is there any solution to sending an actual PATCH request using Plsql_Rest_Sender_API.Call_Rest_EndPoint2?

Thanks,

Brandon