Problem with Direct Input in a Web Service

[Former Member]

Hi colleagues,

I have used the function call HR_MAINTAIN_MASTERDATA in an own RFC which is used as a Web Service. This Function Call processes the Dynpros which would be used in case of manual input. (I think the name of this system is "Direct Input"). When an Error Message is invoked in one of this Dynpros the FC delivers this Message in an Exporting Parameter RETURN1.

When the FC is invoked by the RFC via Web Service it runs into an error message and the control is given to the caller of the Web Service and not to the calling method. When I use the (my) RFC in ABAP the behaviour is correct and I get the error message with the parameter RETURN1.

Do you know a solution to fix this problem?

Thanks in advance

Manfred Homm (SAP Austria, +43/664/6207516)

[Former Member]

hi Manfred,

I do not fully understand your description of the problem.

<i>...the control is given to the caller of the Web Service and not to the calling method...</i>

do you mean it is throwing a SOAP error or how does it 'give the control to the caller of the WebService'?

with "calling method" you probably mean your own wrapper function module, right?

anyway, IMHO you either did not set the dialog mode to '0' (which you certainly have) or there is a bug in HR_MAINTAIN_MASTERDATA, which does not catch all exceptions and stuff them into return1 but tries to raise an exception or set sy-subrc. In latter case I think you have to file an OSS message since the documentation of that function modules clearly states that all errors are passed along in return1.

I think such things currently occur quiet frequently since you have to code your calls for dark processing which is easy for the actual function module as well as all function modules the first function module relies on but it gets more and more complicated the deeper the calling chain is. also certain badi implementations or user-exits in one of the function module's chain of calls might not properly handle the fact of dark processing an raise an exception which is not handled properly.

my 2 cents,

anton

[Former Member]

Hi,

@Dieter: I didn't have time to concentrate on solving this problem. We can temporarily live with it. But I will go on with solution finding in some weeks. If I find a solution I’ll post it on this place.

@Karim: In the meantime many thanks for your suggestion.

Cheers,

Manfred

[former_member515616]

Hi,

we have exactly the same problem - is there a solution available yet?

thanx for all infos!!!

br

Dieter from Linz

[Former Member]

Hi colleagues,

there is now a solution for this problem. It was an error in the kernel.

You can fix it with a kernel upgrade.

Best regards

Manfred

[former_member515616]

Hi Manfred,

thanks for your information regarding this problem!

Do you have detailed informations about the kernel update? Is this Update included in Kernel 6.40?

Thanks for any info on this!

best regards

Dieter

[Former Member]

hi dieter,

i think the corresponding SAP note is [1110209|https://service.sap.com/sap/support/notes/1110209].

and yes, it's updated in 6.40 as far as I can see.

regards,

anton

[Former Member]

Hi,

if this is working as expected when you test the RFC, but not when you run it from the service, this will be a problem:

- Either in the service definition

- or in the test data you use when testing the service

You should try to modify a bit your RFC in order to store the incoming data somewhere (table or file), then call them from the service and see what data are really passed to the RFC

Rgds,

Karim