ABAP Clean Core for Unreleased Function Module

[Ben_Lim]

Dear Expert, 

I've a requirement to expose FM CREATE_RFC_REENTRANCE_TICKET as an oData Service. Conventional method was using SEGW to expose as an oData service to return the value I need. However for S/4 HANA 2023 Private Edition, how could I achieve it via Clean-Core approach?

Reference from https://github.com/SAP-samples/tier2-rfc-proxy

Are we able to wrap unreleased non-RFC FM using transaction ACO_PROXY? 

If can, after wrapping the FM, how could we expose it as consumable oData service that visible in transaction /iwfnd/maint_service?

#s4hana, #abapcleancore, #odata, #cleancoreguideline

Regards,

Ben

[Sijin_Chandran]

Please be informed that 'ACO_PROXY' works only for RFC enabled FMs.

[Ulrich_Schmidt · Accepted solution]

If you are logged on via HTTP, there is no need to use function module CREATE_RFC_REENTRANCE_TICKET, you can simply make a GET request to the ICF service /sap/public/myssocntl.

Note that in older systems for this to work, the above ICF service needs to be active (I think, since Kernel 6.40 it is by default) and the profile parameter login/create_sso2_ticket needs to have the appropriate value. See documentation of that profile parameter in RZ11.

In newer systems (7.54 and newer) it should work out of the box. See note 2822156 for details.

[Ben_Lim · Accepted solution]

I would need to further output additional field to the response: Ticket, System ID, User ID, Client ID. Is there a way to return response with these data?

[Ulrich_Schmidt · Accepted solution]

I don't understand the question?! The ticket is returned by the above ICF service, and System ID, User ID and Client should be known, *before* you even log in!??

[Ben_Lim · Accepted solution]

The requirement is a CAP service application to consume "CREATE_RFC_REENTRANCE_TICKET" with additional fields as an oData service, the response will be used to generate an output file

[Ben_Lim · Accepted solution]

to add on, the user has access to multiple different backend system, hence calling via each destination of the odata service to return the required ticket with additional fields response

[Ulrich_Schmidt · Accepted solution]

Well, if you ask me, that requirement is nonsense...

• as already said, a CAP service can simply consume /sap/public/myssocntl -- no need to implement some complicated workaround for consuming a function module
• The three fields are already known at that point (otherwise you wouldn't be able to obtain a ticket in the first place... 🙂 )
  So just add them to your output. No need to call an API for things that you already know.
• And finally, from a security point of view, it doesn't sound like a smart idea to save a re-entrance ticket into a file...! (Unless you really want to get hacked...)
  You should definitely re-think your design and what you really want to achieve here.

(A re-entrance ticket should be obtained at the point, where it is needed, and not at some other place and then get passed around or even saved into a file -- that only increases the risk that it falls into the wrong hands and opens the door for malicious attackers to gain access to the backend system.)