help: how to fetch exception with malicious asynch calls?

This space is dedicated to SAP users - administrators and programmers who want to integrate PTV Developer (native), the PTV xServers or the SAP Hana Spatial Services (HSS). Topics which require specific SAP based knowhow or which deal with SAP based mechanisms will be collected here.
Post Reply
User avatar
Bernd Welter
Site Admin
Posts: 3014
Joined: Mon Apr 14, 2014 10:28 am
Contact:

help: how to fetch exception with malicious asynch calls?

Post by Bernd Welter »

Hi there SAP fans,

one of my partners wants to use the asynchron protocol. Of course the regular workflow of an optimization call returns a proper result with a HTTP-200 status code.

The asynch process requires a user to call the fetchXXX-operation once the status of a Job is SUCCEEDED or FAILED.

Of course he also wants to implement the malicious path which is supposed to tell the user about the cause of an issue. Now here's the problem (not even sure whether this only occurs in the asynch case):
Looks like SAP environment does not retrieve the body if the HTTP 500 is raised. Anyone here who can help? At least return some feedback?
Example from the raw request runner (xTour1): The response contains the required information but the status code HTTP-500 causes the client to drop the response body.
Example from the raw request runner (xTour1): The response contains the required information but the status code HTTP-500 causes the client to drop the response body.
I have no sufficient knowledge about SAP to deal with it's strength and weaknesses ;-)

Best regards,
Bernd
Bernd Welter
Technical Partner Manager Developer Components
PTV Logistics - Germany

Bernd at... The Forum,LinkedIn, Youtube, StackOverflow
I like the smell of PTV Developer in the morning... :twisted:
jasci01
Posts: 9
Joined: Mon Feb 12, 2018 3:49 pm

Re: help: how to fetch exception with malicious asynch calls

Post by jasci01 »

Hi Bernd,

I am wondering if the proxy call in ABAP does not return any error message in the occurring SAP exceptions. But I assume your client has already checked this.

If not, maybe it could be a workaround not to call the xServer by the proxy class, but with a regular HTTP call. Function module HTTP_GET and/or class cl_http_client seem to be able to return a http body. Unfortunately, I can not test myself in my environment. Payload for the request in the fetchXXX methods is not too big and could therefore built up easily even in an ABAP environment.

Regards,
Frederik
User avatar
MISTERX
Posts: 59
Joined: Mon Jun 02, 2014 11:50 am

Re: help: how to fetch exception with malicious asynch calls

Post by MISTERX »

Hi Bernd,

I suggest to request xServer by Service Consumer (SAP Enterprise Services) instead of using CL_HTTP_CLIENT. Service Consumer uses SAP SRT (SAP SoapRunTime).

With CL_HTTP_CLIENT you have to handle response, request and headers by yourself. With Service Consumer you can use transaction SRT_LOG to have a lookup to status codes not equal HTTP-200. It bases on table SRT_UTIL_ERRLOG. From that table you may read entries selected by e.g. TIMESTAMP, USER, IF-NAME or TRANSACTION-ID. With method GET_FORMATTED_DATA in CL_SOAP_XML_PARSER you can transform content of field ERROR_CONTENT to SAP STANDARD TABLE (SRT_XML_FDATA_TAB).
Transaction SRT_LOG
Transaction SRT_LOG
But how to get/create the Service Consumer? You may take the xServer-WSDL and create Enterprise Service with SAP Wizzard, but this is not simple, according to my experience. But there is the possibility to get the Service Consumers from PTV (have a look to the use cases of your xServer).

Hint: all operations START[], FETCH[], WATCH, STOP and DELETE will be send synchronous. Only the started operation is asynchronous. By this TX SRT_LOG marks the request as SYNCHRON!
Attachments
Use cases from xServer
Use cases from xServer
Error content from table after transformation
Error content from table after transformation
Mr. X
  • Integration PTV <> SAP
  • Senior Consultant

________________________________________________

Optimism is only a lack of data!
Post Reply