Unable to add std PR approval service multiple times from diff systems

[Former Member]

hi,

I have added the PR approval service GBAPP_PRAPPROVAL from system A. Now i am trying to activate the same service from system B on the same gateway system but i do not see the service at all after i click on Get Service button. I can see the rest of the services in system A. I presume the service is ignored because the system reads the same service exist already.

When i call the same service of system B on to a different gateway, i can see the service and it works fine.

Any suggestions to resolve will be appreciated ?

[Former Member · Accepted solution]

Hi Ameekar charan,

I think you are trying to use one Gateway system for Multiple servers like as you said SystemA and SystemB from Different clients in gateway.

If it is the case then services are not going to add for the every system alias or for every client,sisnce they are system specific.If you confusing how to add the system alias for the that service then go to tcode /IWFND/MAINT_SERVICE there you can see the your service(your case gbapp_prapproval) select that service then u cans ee in the bottom of the right hand corner for Add system alias and delete systemalias tabs there you have to maintain the SystemB systemalias.

I hope it is help for you. If not please specify what is your case.

Regards,

Praveen.

[Former Member · Accepted solution]

Thanks Tejas, Praveen for your replies.

I have added as you suggested the additional system alias for system B (with system A as default). I tested by logging in with user on g/w which existed in System A and tests were ok.

However when i logged in the g/w with user for system B, it gave me RFC userid /pwd error. When i checked the logs, it showed that g/w was still calling the default system (this user does not exist in System A hence the error).

[former_member182874 · Accepted solution]

Ensure username exist in all the systems.

Rfc destination shd be trusted

Current user should be checked

[Vasilis]

HI Ameekar,

please see my answer here

to understand how aliases work with roles

regards,

Vasilis

[Former Member]

Thanks Guys, after i saw Vasilios post i understood that because i had left the default system role as blank, routing was not happening correctly. Have corrected that now and atleast the PR app is not giving error however i still dont see any PR count (coming as zero).

Figuring it out... any suggestions will be appreciated.

[Former Member]

Ok, just did some deeper analysis and found that routing is still not happening

I will retrace the steps ... added the two system Aliases along with roles

Still when i test using the different users with respective roles in GW_CLIENT (checking URL - /sap/opu/odata/sap/GBAPP_PRAPPROVAL/WorkflowTaskCollection), i still see the same URL being hit which points to the default system irrespective of the user with which i login.

Any suggestions ?

[Former Member]

Hi Ekansh, Krishna

Even after assigning role to the user, system did not route for the non-default system. Do not know if i missed anything but still getting the same error.

Shall try the BADI as mentioned by Krishna and report back.

[kammaje_cis]

You need to enter Roles in Gateway System aliases, and assign two different users different roles to test this out. BADI is useful if you want to do it dynamically. Currently your scenario sounds simple to handle with Roles @ system aliases itself.

[Former Member]

Probably i did not explain myself clearly enough.

I have two users - userA which exists on g/w and system A (marked as default) and userB which exists on g/w and system B. When i login with userA, I am able to execute GBAPP.. service whereas when i login with userB i am not able to.

Reason being system still routes to only the default system whereas i expected it to check the service in both the systems. If it would have routed to systemB, the service will execute but that is not happening.

Something that i am missing ?

[EkanshCapgemini]

You can control this routing by assigning 2 different roles to USER A & B and add those roles in system alias assignment table. So it will route user A to system A and B to system B based on their roles.

Regards,
Ekansh

[kammaje_cis]

I think Ekansh has got the right approach. There is one more option of coding where to go (which system alias to use). Check this.

Dynamic System Alias Calculation Via /IWFND/ES_MGW_DEST_FINDER - SAP NetWeaver Gateway - SAP Library

[Former Member]

Are you using same client for  both systems(SystemA and SystemB) or Different clients.

If the client is different for two systems then keep only one Systemalias name(either SystemA or systemB).

Regards,

Praveen.

[former_member182874]

Hi Ameekar,

When you say system A and system B, and then you again say same gateway system. I am confused here.

If you are talking about same system and 2 different clients. Then let me tell you, the RFC destination which is created, may be that is created to interact between specific clients.

Like GW_100 is connected to BE_100 right now (100 is client here)

When you login to GW - 200 client, the system alias which you use is the previous one, but for this rfc might not be created.

So you have to create rfc destination for your another client too. like GW_200 is connected to BE_100

Then you would be seeing your service in get service in tcode : IWFND/MAINT_SERVICE.

Regards,

Tejas

[Former Member]

Thanks for replying Tejas.

No i did not mean same system different clients but two totally different ERP systems connected to the same gateway. Both have their respective trusted RFCs & aliases created (like i mentioned i can see rest of the services for system B).  

[former_member182874]

If you are connecting 2 different ERP, with same gateway. You don't have to add the services twice. You can manage it using multiple origin concept.

Create a system alias for ERP 2

Click the service name which is already added, and assign system alias for ERP2

Check the service in gateway client using moc.

Also please check this thread, where the same issue is solved.

Regards,

Tejas