topic Re: Asynchronous function module - why RFC ? in Application Development and Automation Discussions

Asynchronous function module - why RFC ?

former_member182148 — Wed, 30 Nov 2011 13:24:46 GMT

Hi,

I am using CALL FUNCTION ... STARTING NEW TASK ... DESTINATION 'NONE' to start an asynchronous process.

For this to work, the called function module must be unfortunately RFC enabled.

Actually I do not want that anybody external can call this. Can I find out, if I was called from "outside"? Otherwise I create a potential security hole?

Regards,

Bruno

Re: Asynchronous function module - why RFC ?

RaymondGiuseppi — Wed, 30 Nov 2011 13:44:31 GMT

Try to use FM [RFC_GET_ATTRIBUTES|http://www.sdn.sap.com/irj/scn/advancedsearch?query=rfc_get_attributes] or [RFC_WITHIN_SAME_SYSTEM|http://www.sdn.sap.com/irj/scn/advancedsearch?query=rfc_within_same_system] at the beginning of your FM execution, exception NO_RFC_COMMUNICATION will be raised if not called via RFC.

Regards,

Raymond

Re: Asynchronous function module - why RFC ?

ThomasZloch — Wed, 30 Nov 2011 13:59:22 GMT

But when using above construct STARTING NEW TASK, then it is RFC-communication, will the exception still occur? It sounds to me as if Bruno wants to allow aRFC within the same box (for parallel processing?) but is afraid of the same function being called from outside SAP.

A sound security concept is the cure for many problems.

Thomas

Re: Asynchronous function module - why RFC ?

Former Member — Wed, 30 Nov 2011 13:59:37 GMT

Hi Bruno, what is your requirement? If you want to trigger the function module in order to execute it in a separate work process in the same client, you could call the module in update task. You have to define the function module as update module under attributes in SE37. No RFC involved in update calls.

Regards, Martin

Re: Asynchronous function module - why RFC ?

former_member182148 — Wed, 30 Nov 2011 14:06:56 GMT

Hi,

the requirement is that some other code calls my code and passes objects IDs that should be processed in the background (some kind of complex calculations).

I did not do this synchronous, since the calling code should not be slowed down by my logic and the result of the calculation is not needed in the calling program.

I will check if the IN UPDATE TASK would be more appropriate, the help confuses me currently a little.

The RFC_WITHIN_SAME_SYSTEM might also work, since it could return Y or N.

Regards,

Bruno

Re: Asynchronous function module - why RFC ?

Former Member — Wed, 30 Nov 2011 14:13:06 GMT

Hi again, then update function seems a good choice. Have a look at ABAP keyword documentation:

The function module is not executed immediately, but is scheduled for execution in a special work process... The actual execution is triggered by the statement COMMIT WORK

Martin

Re: Asynchronous function module - why RFC ?

Former Member — Wed, 30 Nov 2011 14:14:03 GMT

A sound security concept is the cure for many problems.

In this special case it is much easier said than done... ;-(

STARTING NEW TASK automatically uses DESTINATION 'NONE' even if you do not code the destination extention, therefore the FM must be RFC-enabled.

FM RFC_WITHIN_SAME_SYSTEM checks that the caller is within the same SID, which is what the internal destination NONE is.

To use security for this you must consider that internal destinations do not check object S_RFC by default. But real external callers will encounter the check. This means that to use authorizations based security you must have all your users (everything from end users to the RFC connections users into this system) as having explicit and restircted RFC authorizations which also do not include the function group which this FM belongs to.

Additionally the field is 40 char long (as are the object names) but the authority-check statement truncates the function group name at the 15th character as it can only deal with 16 char.

An finally, anyone who does not know the object is very likely to pop a * value into it when it turns up, and it will ...

In this case I also think that FM RFC_WITHIN_SAME_SYSTEM is the more reliable solution. After all, SAP also use it for exactly this purpose.

Cheers,

Julius

Re: Asynchronous function module - why RFC ?

RaymondGiuseppi — Wed, 30 Nov 2011 14:54:11 GMT

Time to perform a simple test

- when called by actual RFC -> no exception

- when STARTING NEW TASK DESTINATION 'NONE' -> none or SYSTEM_CALL_NOT_SUPPORTED (depending on WAIT management...)

- when direct call -> NO_RFC_COMMUNICATION

You could check returned values like IP address, but I agree, better use RFC_WITHIN_SAME_SYSTEM. (Easier and SAPer)

Regards,

Raymond

Re: Asynchronous function module - why RFC ?

former_member182148 — Wed, 30 Nov 2011 15:54:59 GMT

Found out that STARTING NEW TASK creates a new session and fails if there are already 6 open... not perfect also

Now looking into IN BACKGROUND TASK.. too many options here, but noone fits perfectly

Re: Asynchronous function module - why RFC ?

Former Member — Fri, 02 Dec 2011 11:30:43 GMT

Hi Bruno, what about calling the module in update task? did it work for you? Regards, Martin

Re: Asynchronous function module - why RFC ?

former_member182148 — Fri, 02 Dec 2011 12:17:53 GMT

Hi,

I changed my mind and will implement the process as a background job (scheduled or triggered by an event).

There came up additional concerns, when running out of processes that information may be lost and it is safer in this way (storing the initial info in a table and processing it separtely later). This will also solve some potential authorization issues, because we can use a special service user with appropriate authorizations.

Thanks for all the input, I gave some points for helpful answers.

Regards,

Bruno