RFC call seems to be OK but nothing reaches ECC

[Former Member]

Hi there experts!

I'm facing some issue and would like to know if someone could shed some light here. I'm using PI 7.31 single stack in order to collect some messages (contracts) from SRM and deliver them to ECC via RFC.

As far as I know, SRM generetes the message, it is flagged ok at SXI_MONITOR at SRM system. Once I open PIMON at PI I see the message and eventually it places at 'delivered' status.

At the ECC side, they don't receive any message. They're checking via SXI_MONITOR there, and also the SM58 in order to see if something has tried to enter ECC via RFC.

Is there anyway to check what is going wrong with these messages?

cheers,

Edu

[giridhar_vegi · Accepted solution]

Hi Edu,

          what is the status in sxmb_moni.if it is sucess then go for the receiver rfc communication channel and check the option advanced mode and select the option "Commit Handiling for Single BAPI Calls".and select all the check boxes except the last one i.e bapi advanced mode

Thanks

Giridhar

[Former Member · Accepted solution]

Hi Giridhar,

I don't have sxmb_moni since it's PI 7.31 single stack, but at PIMON it says 'delivered'. I'm trying to deliver the message to a RFC not exactly a BAPI. what would that option of 'Commit Handling for single BAPI calls' do?

cheers,

Edu

[giridhar_vegi · Accepted solution]

Hi Edu,

          it would commit your transaction externally.Please check the option and it will work because i have also faced this issue in earlier

Thanks

Giridhar

[giridhar_vegi · Accepted solution]

Hi Edu,

          In your Scenario the transaction is not getting committed in the RFC module at ECC. so inorder to commit the transaction you need to select the option which i have specified.

Thanks

Giridhar

[Former Member · Accepted solution]

Hi Giridhar,

this is what the RFC adapter is answering me right now, altough it's a RFC nor a BAPI what I'm calling:

cheers,

Edu

[che_eky · Accepted solution]

Hi Eduardo,

Sorry I did not see this post of yours. Take a look at the following thread it should help you resolve your issue:

Quoting Manish from the above thread: "You have COMMIT enabled in your RFC receiver comm channel. Check that and deselect option for "Commit Handling for SIngle BAPI Calls".

Basically when you have that option enabled it looks for a BAPIRET2 paramateter in the response back, and if it is not there you will see that error."

Che

[Former Member]

Hi all,

just wanted to update this thread and close it.

Finally I was able to get this interface to work. Basically, I reached this project late, and it was implemented a Standard solution to connect SRM and ECC, but as SRM and ECC versions were not alligned, it was not working because of the hierarchy at contracts and was stucking the queue.

I proposed to redirect the flow to a ZPROXY and ammend the functionality at code level, but the ABAP team told me they cannot generate the proxy since it was asking for an activation keys as when you're trying to modify some standard objects.

I trusted them and try make some workaround in order to push the info to ECC (via RFC or webservice even).

One night while I was leaving my job, I had an idea and the day after asked ABAP team to try to generate the proxy changing the prefix they were using and magic happened! they were trying to generate the proxy under a standard prefix.

Now, I've got the interface working, since SRM sends contracts via SOAP from a standard transaction, and at PI I redirect the contract to our own proxy. That's what I've proposed at the first time. A 'keep it simple' solution.

Obviously as the proxy works as I thought at first, no problem is raising now.

Thanks a lot to everyone that helped me to 'reinvent the wheel' while I was trying to make a workaround!! now I know that I have to give some more info to the team that is going to generate the proxy.

cheers to all, and again THANKS a lot!

Edu

[Former Member]

Hi all,

I've cancelled failed messages and it worked. Problem now is that since the SPROXY did not generate CONSTRUCTOR when generating the proxy, once the message reaches ECC it gets green flagged at the SXI_MONITOR but does not reaches the class where the logic relays and nothing gets processed. It will keep on green flag forever, ABAPer says.

Could it be bad generated? I've developed the Service Interface and the other objects as I usually do, I don't see how can I help if the SPROXY doesn't generate that CONSTRUCTOR class automatically...

any hint?

cheers,

Edu

[engswee]

Hi Edu

There won't be any constructor method generated and that is fine.

For your green flag issue, it might be because the queues are not registered yet.

SXMB_ADM -> Integration Engine -> Administration -> Manage Queues

Select all queues

- click Register queues

- then click Activate queues

- then click QRFC Monitor and make sure there are queues in the list as shown below.

Rgds

Eng Swee

[Former Member]

Hi Bertoni,

Get the traget payload and execute the function module in ECC by puting the same payload data and see if it is updating the table contents.

Normally in custome RFC's , if exception handling is not done properly then excution will happen with out any proper logs.

Regards

Prasanna

[Former Member]

Hi there experts,

finally I've been able to generate a Z Proxy instead of the standard one, in order to bypass the standard process via a Z program that fit the requirements of the client (and so I don't need the RFC bridge).

Now the thing is that the ABAP guy told me that at the proxy generation time, the CONSTRUCTOR class has been not generated, and he's doubtful about if this is going to work without it.

Does anyone knows something about this? any help would be highly appreciated!

cheers,

Edu

[former_member182412]

Hi Edu,

After generating the proxy the proxy class will be like below with one method, with in this method you need to implement your code. 

Regards,

Praveen.

[che_eky]

Hi Eduadro,

If you created a Service Interface (SI) in the ESR and the "ABAP guy" generated a proxy based on the SI in the backend then why would it not work?

Che

[Former Member]

Hi Che,

I don't know, just asking as he told me it was strange that he could not see that class.

Also, now he's telling me that some data types doesn't fit what he expected, but I've generated the proxy as a ZSI that point to a standard MT. I cannot change nothing there, maybe he must map the type to some user-defined type he must define there at ECC...

Cheers,

Edu

[che_eky]

Hi Eduardo,

As you have exposed the Service Interface and the proxy has been generated great. Just sit down with the ABAPer and work things out together

Che

[Former Member]

Hi Che,

bad luck here. As soon as I tried to process some message from SRM, the user at the SOAP Receiver channel was locked:

but as soon as Basis changed the password at the SOAP Receiver Channel, it keeps holding the message and setting it at HOLD status:

any help??

cheers, and thanks a lot in advance!

Edu

[JaySchwendemann]

Did you (by chance or accident) configure your receiver proxy channel to be of exactly once in order? If so, and if EOIO is necessary, please try to process or cancel (if on DEV or QAS system) the erroneous message that keeps others from flowing through.

If you are not on EOIO, please report back

Cheers

Jens

Message was edited by: Jens Schwendemann - Sorry missunderstanding that proxy sender would request EOIO in proxy scenario

[che_eky]

Hi Eduardo,

Jens may be right, there could be a message already waiting to be processed in the queue. Not sure if that would cause a status of Hold or Scheduled. Can you see if you have any messages stuck in SMQ2?

It could also be that you have no queues defined in ECC?

Che

[che_eky]

PurchasingContractSRMReplication is part of standard delivered content in SAP PI. When using PI both sender and receiver adapters are normally of type Proxy.

Are you using point-to-point communication? I don't thinks so as you have an Operation Mapping being called.

Che

[Former Member]

Hi Che,

I know, but we are trying to redirect the proxy receiver to a RFC receiver because we need some other functionality...

cheers,

Edu

[che_eky]

What is your RFC receiver based on ? A function module or BAPI? Can you add a code loop in your RFC receiver like this:

data: l_debug type c length 1.

while l_debug is initial.

if 1 = 2. endif.

endwhile.

Then rerun the test again and see if you can see the RFC executing in SM50. This will at least tell you if the RFC code is being called but not doing what you expect.

Che

[Former Member]

Hi Che,

we are trying to put a break-point at the program and it seems (or at least we have that feeling, since a Basis guy have seen something related to breakpoints at some trace at the ST11)... but still no luck here.

cheers,

Edu

[che_eky]

Hi Edu,

Not sure why you need to involve Basis to check a break point or in this case a while loop. I don't think you need ST11, you should be able to see the process looping in SM50.

Che

[engswee]

Another reason why I hate using RFC so much - there is just no trace in the called system.

Anyway, I digress...

Edu, another way to debug the RFC call is to login to the backend system using the same user ID as the one being configured in the RFC receiver channel. Go to SE37 and put in the RFC name and set an External Breakpoint on the first executable (not at the data definitions) ABAP statement in the function module.

After the breakpoint is set, do not exit the GUI session. Just run the interface via PI again. If the RFC is called correctly, then the GUI will pop up the ABAP debugger for you to continue debugging.

Rgds

Eng Swee

[Former Member]

Hi there,

Now I'm having a slightly different issue. I see that some queries are generating some batch sessions and data sets, but others no. Could this be related to some missmatching at the SRM-RFC data? wouldn't the RFC adapter raise an error related to this?

We are trying to determine the reason why some messages are entering and trigger the RFC and some other no. And no tracing is available, since PI says 'Delivered' as it delivers the message to the RFC.

Cheers,

Edu

[former_member182412]

Hi Edu,

That is why i dont prefer RFC because of no trace, why dont you change it to proxy, you can still call the existing RFC using proxy.

Import the RFC structure and create new service interface and refer RFC request and response message structures in the service interface, generate the proxy for service interface which you created in sproxy in SRM system.

With in the proxy method you can fill the RFC request from proxy fields and then call the RFC which you are calling currently. apply what other changes you want to do there because you mentioned last time you changed to RFC because of some additional functionality.

If you do it like this you can monitor in sxi_monitor and all the log and traces you can see. and you write the errors to application log also.

Regards,

Praveen.

[giridhar_vegi]

Hi Edu,

          define the return parameters in the advanced mode

Thanks

Giridhar

[iaki_vila]

Hi Eduardo,

May be the BAPI is not making a commit. In order to assure that the request is arriving to ECC endpoint you can set in the first instruction of the BAPI an external breakpoint with the same user that you are using in your RFC receiver channel.

Regards.

[Former Member]

Dear Eduardo,

if ur using RFC type 3 (ABAP connection) Try to check the RFC connection which you have created in SM59 and test the RFC connection both authorization and connection test both should get successful. IN both system SRM and ECC. the user which you have maintain in RFC connection check it has proper authorization or not .If the RFC connection is successful and its working fine then see system is giving any dumps or not in st22.

[Former Member]

Hi Syed,

I'm trying to send some info to ECC, do I have to create any connection at SM59? where should I place that connection at PI side, since my RFC adapter it's like this:

cheers,

Edu

[Former Member]

Dear Edu,

You need to create RFC connection HTTP connection to ABAP system and also internal connection for PI system .

[Former Member]

Hi Syed,

but this is not a new system, I assumed that as the system has proxies and rfc connections nothing has to be done.

Also, I've tried to change the password of the user used for RFC connection and the RFC channel raises an authentication error...

cheers,

Edu

[Former Member]

Check if the user is having proper roles to post data in to SAP or not?

Also try to ping the channel from communication channel monitor and see the connection.

Thanks

[Former Member]

Hi Gaurav,

thanks for the hint, I've tried and this is what I've got:

for testing purpose it's a SAP_ALL user, so I don't think it might be a problem...

Cheers,

Edu

[Former Member]

Can you please check in ST22 of ECC to find out if any dump is getting generated?

Thanks

[Former Member]

Hi Gaurav,

already done that. No dumps. 😞

cheers,

Edu

[JaySchwendemann]

Isn't Eduardo referring to a single stack system? So there's no RFC connections in a SM59 way, I'm afraid (of course there are destinations within NWA for that purpose)

[former_member182412]

Hi Edu,

You cannot monitor RFC messages in SXI_MONITOR only proxy messages you can monitor, if it is any failure you can monitor in SM58.

Regards,

Praveen.

[Former Member]

Thanks Praveen,

but still no luck, there's nothing at SM58 either!

any clue?

Cheers,

Edu