Skip to Content
Author's profile photo Arthur Wurth

How to register an external program on Gateway?


My name is Arthur from the SAP Product Support team.

As an expert of Gateway and RFC areas, I have observed that many times these teams are wrongly contacted to instruct or clarify how to register external programs to Gateway, specially when issue “Program <Program ID> not registered” appears.

This Blog was created to clarify what needs to be checked and how find out registration steps of an external program.

After reading this Blog, the following skills will be acquired:

  • Definition of a Registered Program.
  • Identify Program ID and Gateway from of a destination.
  • Find the appropriate team to provide programs registration steps.
  • Understand Gateway security rules.
  • Test and validate if a program is able to be registered.

Registered Programs Definition

RFC server programs can be registered with the Gateway and wait for incoming RFC call requests.

The programs are created and registered by applications (SAP standard/ third party/ custom) to process their business requests between external systems and SAP system.

Destinations of Connection type T are created on SM59 with program ID and the target Gateway.

Getting Program and Gateway details on SM59

  1. Open transaction SM59
  2. Expand “Connection Type T”
  3. Double click the destination name.
  4. Program ID
    Destination Gateway

    Check the “Technical Settings” tab of the destination in use. The Program ID field has the program name.

    Example of Program ID called: TP_PROGRAM_NAME

    Check the “Technical Settings” tab of the destination in use. The Gateway Options field has the program name.

    Example of Gateway options, as there is no specific Gateway host/service, destination consider that program must be registered in all Gateways of this system.


Registering a program on Gateway

As per SAP note “353597 – Registration of RFC server programs”,  to register a program on Gateway you need to follow the relevant program documentation.

There are thousands of programs (SAP standard/third-party/custom) compatible with SAP systems and RFC mechanisms, each program has particular ways to get registered on the Gateway.

The steps to perform this registration must be provided by the application team responsible for the specific program.

  • SAP Standard programs: Find for relevant documentation in our Channels (Launchpad search / Wikis / SAP Help). If further assistance is required, a new incident can be created to get assistance from the responsible team.
  • Third-Party programs: Find for relevant documentation on third-party channels. If this third-party is a SAP partner, further assistance can be provided via incident.
  • Custom programs: Contact the development team responsible for this custom program for details.

Once the steps are provided, remember to use the right <Program ID> and the right Gateway to register this program.

To verify if the external program is already registered:

  • ABAP Gateway: Run the transaction SMGW (Goto – Logged on clients) and verify if  the “TP Name” column.
  • Standalone Gateway: Use the gwmon program to list this information.

Gateway authorization checks

Does Gateway allow program registration? Sometimes is possible that the Gateway Security Features of this Gateway are not allowing this program or this server to be registered.

Understanding Gateway security features:

  • Read Wiki article Gateway Access Control Lists to understand how the security rules and behaviors can be adjusted for these scenarios.
  • The KBA 1850230 has example of how to solve “Not allowed” issues.
  • If even after reading this documentation an information is not clear, either comment in this Blog or get full specialized support with (BC-CST-GW) team.

Testing if Gateway will allow the registration:

  • SAP have an auxiliary test program called “rfcexec” to test if programs could be registered on Gateway.


rfcexec -a<Program ID> -g<Gateway Host> -x<Gateway Service>

If the registration test runs successfully, the program will be visible on Gateway, the “Connection Test” should work.

This information guarantees that Gateway security features are allowing this program to be registered from this server.

ATTENTION: After the test, un-register this program (Ctrl +C) on rfcexec side, as this registration is only used for testing purpose, it will not work from business perspective.


In summary, even the layer of this registration is provided by RFC and Gateway mechanisms, the application team of the program used is responsible to provide the program Registration steps.

The Gateway (BC-CST-GW) and RFC (BC-MID-RFC) team can still helping if the registration of the program is failing.

For example:

  • Checking the Gateway traces to see if the security are allowing this registration.
  • Checking if the program is registered in the right Gateway.

If further assistance is required, check the limitations of each layer and find the proper team to clarify the doubts.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Paul Hardy
      Paul Hardy


      Mere words cannot describe how happy I am to hear you (a) work for SAP and (b) are an expert on both Gateway in particular and RFC in general. Have I got a question for you!

      We have a customer portal where the user enters a sales order on their phone or laptop or whatever, and the JavaScript code on the device does a call to a Gateway service I wrote in SAP. It all works just fine, and we are on top of the indirect licencing thingy, so everything in the garden was rosy.

      Now we have a proposal for a generic middleware layer, all Microsoft based, taking in the HTTP call from the mobile device, in whatever country, working out dynamically the correct source system and connecting to it. All lovely and object oriented, several layers all abstracted from each other.

      The problem is the architecture calls for assorted Microsoft integration services connecting to the source systems. the one chosen to connect to SAP is from a company called Theobald software, which works by connecting to custom RFC function modules inside SAP.

      Now I don;t want to give up Gateway. The arguments I am facing in favour of RFC function modules instead of Gateway are as follows:-

      • it (RFC) works and it is easy
      • all the other source systems are contacted directly and contacting Gateway is contacting "middleware" instead of the actual source system, thus giving one source system special treatment instead of treating all source systems the same
      • the call to Gateway will introduce two more HTTP calls in addition to the original one from the device, thus negatively effecting performance, and making t more difficult to pinpoint any point of failure
      • Gateway cannot do an asynchronous call

      Now, I would like to tell me that these arguments are nonsense, and give me some cast iron reasons I can use to knock holes in the proposed plans. However if the above are valid arguments, please tell me that as well.I try to keep an open mind, and I have a lot of respect for the architect of the middle ware framework and how well designed it is from an abstract OO perspective. It is just this one little technical part of the pie I am concerned with.

      I have talked to lots of my fellow SAP Mentors about this, and the only argument I have thus far is a philosophical one in that Gateway is SAP's future direction. Whilst I agree with this 100% it is not getting me very far at work as an argument. I need something more concrete.

      BTW I am making the - perhaps incorrect - assumption that when you use the term "Gateway" above you are talking about the same Gateway I use via transaction SEGW to define my services. If you mean something different then maybe my questions become nonsense!

      Cheersy Cheers





      Author's profile photo Arthur Wurth
      Arthur Wurth
      Blog Post Author

      Hello Paul,

      The Gateway of transaction SEGW, also called as Gateway 2.0, is a different area from the component Gateway described in this Blog.

      To find answer and arguments of this scenario, I suggest using the Question&Answer area under Tags SAP Gateway and NW ABAP Gateway (OData)

      Thanks for your comment.

      Arthur Würth


      Author's profile photo Paul Hardy
      Paul Hardy


      Sorry about that. It only occurred to me right at the end of writing my question that SAP like to have five or six totally disparate components, all doing utterly different things, all with the exact same name.

      It is like Heathrow airport in the UK where there are two hotels nearby, both in the same street, both having the exact same name, and they cannot for the life of them work out why they keep getting each others mail, or having each others guests turn up.

      I know you do not decide what names components are called, so I am not having a go at you, but you have to admit it is rather silly to call lots of different things the same name and then not expect people to get confused. As Einstein once said "there are only two things that are infinite - the universe, and human stupidity. And I am not sure about the universe".

      Cheersy Cheers


      Author's profile photo Satish Juluri
      Satish Juluri


      We have multiple application servers on SAP .Normally we define TCP RFC connection with Gateway host name and gateway service name using one of the Application server.The only issue is that if the server mentioned in the Gateway Host goes down for reasons like Rolling kernel Switch etc,The external application wil not be able to connect.

      Is there an option we can have program registered on multiple application servers instead of specifying gateway host name/service in RFC destination.



      Author's profile photo Arthur Wurth
      Arthur Wurth
      Blog Post Author

      Hello Sam,

      Thanks for your question.

      Yes, on section "Getting Program and Gateway details on SM59" if you see exactly this example on item 4 picture, there is no Gateway defined on "Gateway Options" .

      When this information is blank, this destination can use any Gateway from system to communicate with the program.

      The pre-requisite is registering the program in all Gateways of the system.

      So, even if one instance is down, the rest of the instances will keep online and having the TP program registered.

      So, the TCP/IP destination will keep usable.


      Author's profile photo Satish Juluri
      Satish Juluri

      Thanks for the reply.

      Any steps in registarting the program on all gateway instances .




      Author's profile photo Isaias Freitas
      Isaias Freitas

      Hello Sam,

      That will depend on the system performing the registration.

      Such system could provide a way to register the program on a list of instances, but this is not mandatory.

      It depends entirely on how that system was programmed.

      If we are talking about a third-party (non-SAP) system, then you should contact the support team of the system.

      If it is an SAP system, you can search for documentation (, SAP Notes / KBAs), and even post a question on the SAP Community, under the appropriate tag.



      Author's profile photo Tran Thanh Quynh
      Tran Thanh Quynh

      Dear Arthur Wurt

      Nice article on this.

      We have followed your advice and already test successfully connection between SAP S/4 HANA with Mulesoft via external gateway program on S/4 server ( using command rfcexe ), but you also recommend that "as this registration is only used for testing purpose, it will not work from business perspective", so could you please advise how to register an external program on gateway for production system?

      Looking forward to hearing from you soon.

      Thank you for your sharing and have nice weekend ahead!

      Best regards,


      Author's profile photo Arthur Wurth
      Arthur Wurth
      Blog Post Author

      Hi Quynh,

      This is exactly the purpose of this blog. As documented on SAP note 353597 

      The software solution vendor/provider should provide the steps to register the program to the Gateway.

      Author's profile photo Alexandru Nicolae Necula
      Alexandru Nicolae Necula

      Hello Arthur


      Thank you for the article

      I have a question

      I closed the rfcexec program with Ctrl+C as you suggested that it's only for testing purposes, and now the RFC connection tests fail.

      rfcexec -a<Program ID> -g<Gateway Host> -x<Gateway Service>

      The RFC connection tests were successful only while rfcexec process was running.
      Otherwise, the RFC tests fail with error "program not registered"
      If the rfcexec is only for testing purposes, then I'm a bit confused.
      What does "program registration" actually mean ? can you clarify please?

      Thank you

      Author's profile photo Jozef Hudcovic
      Jozef Hudcovic


      In this testing scenario rfcexec has role of RFC server. It is registered at particular gateway, it technically means that network socket connection was created between RFC server (actively running rfcexec) and the gateway. After stopping rfcexec by Ctrl+C you break network socket connection, so the registration in the gateway is lost and logically RFC connection test fails.

      So Arthur's ATTENTION note by the other words might be: In real world do not fix the problem “program not registered” by dummy execution of rfcexec, because the remote RFC application has to register by itself with own RFC mechanism.