Sap Sm59 Registered Program

Skip to end of metadataGo to start of metadata

The Purpose of this wiki is to rovide details on the Return code 679 which indicates a 'Program not registered' error.

Overview

This wiki provides details on how to determine the RFC destination that is reporting the error, explains how a test program can be registered the gateway and also provide details on who is responsible for registering the server program.

An RFC server program registers itself under a programID at an SAP gateway and not for a specific SAP system. In an SAP system, the destination must be defined with transaction SM59, using connection type T and Register Mode. Moreover, this entry must contain information about the SAP gateway at which the RFC server program is registered.

Identifying the issue

Communication error 679 is reported in the system log (SM21):

All CPIC return codes are mentioned in note 63347. Return code 679 means 'Transaction Program is not registered':
TP_NOTREGISTERED 679 TP not registered

To find out more detail on which program is causing the error the corresponding rfc trace file must be checked.

Determining the failing RFC destination

In the example above, the work process number (Nr) is 01 so the dev_rfc1 (St11) will contain more details. Search this file for the timestamp reported in sm21, in this case it is 171012.
You will see something like the following:
This shows that the problem is related to RFC destination REGTEST and program 'Program1'. If you
go to transaction SM59 and test the destination REGTEST the 'program not registered' error will
be returned:

Example of registering test program rfcexec

Note 353597 provides details on how to register a server program:
<program name> -a<program ID> -g<SAP gateway hostname> -x<gatewayservice>
So, for our example above 'Program1 'needs to be registered:
<program name> -aProgram1 -gy52tdc00 -xsapgw52
<program name> is the name of the program you are trying to run.
Program1 is the name given in SM59 (ProgramId).
Y52tdc52 is the gateway host (from the dev_rfc1 trace above) and sapgw52 is the gateway service (from the dev_rfc1 trace).
If the program has been registered on the local gateway you should see an entry for it in
SMGW > 'Logged on Clients', it will be shown as a REGISTERED_TP / REGISTERED SERVER.
The example given in note 353597 is:
rfcexec -atest -gHOST -xsapgw00
Please note that 'rfcexec' is a sample program delivered with the RFCSDK. If you do the following:
rfcexec -aProgram1 -gy52tdc00 -xsapgw52
This means that you are trying to register the sample program 'rfcexec' with ID 'Program1' on the gateway.
If you are not trying to connect to program rfcexec, the developer of the program you are trying to run should be contacted to advise how to correctly register their program.
In some cases, a particular service may need to be started.

You should know the name of the program you are trying to register. There is no direct possibility to find out the name of the backend program which is associated with the Program ID used for a registered connection in SM59. The only possibility is to do a level 3 trace of the gateway to get the IP and remote number of the program that registers.
With this information you need to remotely execute a netstat and search for the pid of the program that is running on that port. With this pid you goto the ps command to get the name and location.

Checklist

For a checklist of what to do in case of Program not registered error (RC 679) see the following note:

2104408 - Checklist for 'program not registered' errors

Related SAP Notes/KBAs

353597 Registration of RFC server programs

1408081 Basic settings for reg_info and sec_info

1305851 Overview note: 'reg_info' and 'sec_info'

Skip to end of metadataGo to start of metadata

Purpose

When connecting BI4.0 through the Information Design Tool a relational connection is created with a Java Connector (JCO) to the SAP Netweaver Business Warehouse (BW.) When a connection is created in IDT it automatically generates an RFC connection. The connection has limitations and a manual configuration can be implemented.

Overview

This is a review of what is needed to configure an RFC connection and the issues that may be considered.

Why Should a change occur in the Auto-Generated RFC connection?

Issue 1: Connection limits

In BI a JCO connection is created through the client tool Information Design Tool (IDT) to connect to the SAP Netweaver BW data. Once a connection is created BI can auto-generate an RFC destination on the BW side. This feature allows a user to connect and read data for reporting. The RFC is generated with the name of BI CMS and an unique number o through 9. With each connectionit incrementally increases by one until it reaches 10. The RFC destinations should then be cleared out and deleted and the process starts over. However, sometimes on the tenth connection the request for connection is refused with an error such as

“BI server cannot reach a callback Server on this host. Make sure that the resource property 'callbackServerProgramID' is correctly set.”

The connections should be automatically deleted. Before considering manual configuration to one RFC destination, consider why the automatic connection removal is not being implemented. Are there authorizations to be evaluated?

These connections can be manually deleted by the following steps:

Log onto SAPGUI
Execute 'sm59' and open the 'TCP/IP connections' folder.
Observe multiple RFC connections of the form DF_JCO_<HOSTNAME>_<INTEGER> where the <HOSTNAME> represents the machine connecting to the BW system.
Delete the RFC connection that are unused

Issue 2: To Avoid setting authorizations create/change for every user.

The authorizations required for defining a connection against BW include the following:

S_RFC (Authorization Check for RFC Access)

S_RS_ADMWB (Data Warehousing Workbench - Objects)

S_RS_AUTH (BI Analysis Authorizations in Role)

S_RS_ICUBE (Data Warehousing Workbench - InfoCube)

S_RS_IOBJ (Data Warehousing Workbench - InfoObject)

S_RS_ISET (Data Warehousing Workbench - InfoSet)

S_RS_MPRO (Data Warehousing Workbench - MultiProvider)

S_RS_ODSO (Data Warehousing Workbench - DataStore Object)

To avoid giving every SAP user who will use this JCO connections the create/change authorization on S_RFC_ADM. The manual callback ID only requires the authorization S_RFC_ADM Administration for RFC-Destinations and this connection is then used for all users.

If Authorizations are not properly set you may see the error:

Issue 3: There is a message server

Issue 4: The BI environment is Clustered

Issue 5: Is there a bottleneck?

How to Manually Configuring the RFC connection

There are three parts to the manual configuration. The RFC destination is created in the BW environment. The connection is created in the IDT and the Mapping Properties are synchronized in the DFAT.

Consider the configuration environment. How many environments are being implemented?

Log into the Central Management Console (CMC) and View the Servers List.
Select Server Categories and then the Data Federation Service. This will list the BI AdaptiveProcessingServer (APS) that contains the Data Federator Service. This is the service that manages the read function from BW.
Right Click and select Properties
Collect the public 'Server Name' APS name. This is the name at the top of the dialog. If you have more than one server you will need to collect the name of each of them.
where BIPW12R2 is the host name
and AdaptiveProcessingServer is the APS namethat contains the Data Federator Service

Special Notes:

The APS name should never contain any spaces!

The BW Configuration

1. Open SAP Logon and log on to the SAP system with SAP_ALL or theS_RFC_ADM

2. Enter SE37 in the transaction text field and click execute.

3. This opens the parameter panel. Enter function module RSDRI_DF_CONFIGURE click execute.

4. Set the parameters as follows:

I_ONLY_CHECK	“(empty)
I_RFC_DESTINATION	DF_JCO_HOSTName_UniqueID
I_REMOVE_CONFIGURATION	“(empty)

For the second parameter, replace hostname with the hostname where the BOE CMS name and some unique id as a unique system identifier, to differentiate between potential multiple connections. Do not use special characters, periods or dashes. Do not use the single digit numbers 0-9.(These are reserved numbers for BI autogenerated connections and may create a conflict.)

For example, we will use DF_JCO_BIPW12R2_99 is a unique identifier that we can reuse later.

5. Execute the module.

6. Run SM59, check the TCP/IP connections, you will notice that the DF_JCO_BIPW12R2_99 has been generated.

7. Double Click on the RFC Destination and check the Technical Tab for that the gateway host and gateway service are correctly formed.

The Information Design Tool Connection

1. In IDT logon to the repository resources and create a new relational connection

2. Select SAP Netweaver BW JCO connector

3. Enter the credentials for your BW System

4. Do not test

5. Check the box under Optional Parameters for Custom Program ID Mapping.

Use the RFC destination defined above and the name of the BI AdaptiveProcessServer (that contains a Data Federation Service) The entry should look like this: BIPW12R2.AdaptiveProcessingServer=DF_JCO_BIPW08R2_99

6. Check the Box Use Custom Gateway and add the fully qualified domain name for the Gateway Host and add the Gateway Service Name

7.Select an InfoProvider and DO NOT test the connection

8. Click Finish ( You are prompted for a shortcut and you can say yes if you have a project folder ready otherwise say no)

Synchronizing the Connector Data Federator Administration Tool

1. Open the Data Federation Administration Tool with a BI Administrator account

2. Go to the Connector Configuration tab, right click the JCO connection, select create configuration

3. These values must be identical to those entered in IDT : BIPW12R2.AdaptiveProcessingServer=DF_JCO_BIPW08R2_99

(Special Note in Version 4.0 these parameter configuration can only exist in DFAT and not IDT connection)

4. In the gatewayServiceName enter the gateway name example: sapgw00 (This is listed in the RFC destination Tachnical Tab above)

5. In the property gatewayHostname type in the Fully qualified domain name of the BW server

6. In the jcoServerProperties, assign the following value: jco.server.connection_count=10

7. In the jcoDestinationProperties, assign the following value: jco.destination.pool_capacity =10;jco.destination.expiration_time=600000;jco.destination.peak_limit=10

NOTE: The steps mentioned in Data Federation Administration Tool must be performed, otherwise connection creation is not finished, despite the connection has created in Information Design Tool. Note also, the connection test can be performed in Information Design Tool, after the steps has been performed in Data Federation Administration Tool.

8. Save the Connector Configuration (Top Right save icon)

9. Once the Configuration has been saved, click double the connection. It should retrieve the the BW, JCo versions.

How to Configure In a Clustered Environment

1. Edit the IDT relational connection to BW

2. In the Custom property programIDMapping, point the JCO connection to use the RFC destination.

4. Add the entries seperated by a semi-colon.

5. Each distinct AdaptiveProcessingServer (APS) Server must be mapped to a distinct RFC destination.

6. Synchronize the DFAT connector configuration.

For instance, (Cluster with 2 nodes), the entry for the parameter programIDMapping would be:

MySia1.AdaptiveProcessingServer1=DF_JCO_BIPW08R2_99;MySia2.AdaptiveProcessingServer2=DF_JCO_BIPW08R2_100

MySia1 is the name of the first node from the cluster and AdaptiveProcessingServer1 is the name of the AdaptiveProcessingServer running

MySia2 is the name of the second node from the cluster and AdaptiveProcessingServer2 is the name of the AdaptiveProcessingServer running on MySia2

Configuration to Eliminate the BottleNeck Created By Using Only One Connection

Set up multiple RFC destinations and assign them to each Data Federator APS server in the following manner (assuming you have 2 DF Query Servers each on 2 different processing tier nodes):

- After setting up 2 APS servers on each of the 2 processing tier nodes, note the names of each server. These names are listed in the BI CMC under the “Servers” -> “Data Federation Servers” section. For example:
SIA1.DFServerA SIA1.DFServerB SIA2.DFServerC SIA2.DFServerD

- Each RFC destination can only be used with one DF server. Create each destination according to the following naming scheme, and set the Program ID equal to the destination name: DF_JCO_<hostname>_<server_ID>

For instance:
DF_JCO_SIA1_A DF_JCO_SIA1_B DF_JCO_SIA2_C DF_JCO_SIA2_D

- For every BW datasource listed, modify the parameter “programIDMapping” to link each DF APS to its RFC destination. Refer to the Data Federation Administration Tool Guide section 4.5.1 for more details on the syntax of this field.

- In the example above with 4 DF query servers, you would set “programIDMapping” equal to the following string:
SIA1.DFServerA=DF_JCO_SIA1_A;SIA1.DFServerB=DF_JCO_SIA1_B;SIA2.DFServerC=DF_JCO_SIA2_C;SIA2.DFServerD=DF_JCO_SIA2_D

This will bind each of your four Data Federator services in each APS to their defined RFC destinations.

You should also increase the concurrency of the connector itself. The default value is 2 concurrent connections on one JCO connection to one RFC destination. You can safely increase this up to 10.

For more in depth information about scalability, Click Here

BW Configuration Notes

In BW an RFC destination of the type TCP/IP connection must exist in transaction SM59. We recommend the naming convention DF_JCO_<HOST OF DF_some sid#>, as described above. The activation type must be 'Registered Server Program', and the program ID must be the same as the RFC destination.

When the DataSource is configured in the Data Federator, the name of the gateway host is read from BW. This host name should be the fully qualified DNS name

For example: myserver.sap.com instead of just myserver

If the DNS name is not fully qualified, change the parameter 'rdisp/mshost' to the fully qualified name in BW using transaction RZ11.

Connecting to a Message Server

Connecting via message server

1. Launch transaction SE37.

This protects you against doable damaging your pc. If you make even the smallest error within the Registry Editor it can result in you some serious issues that may even call for a brand new set up of Windows. Another advantage to these registry cleaners is that repaired registry errors will strengthen the speed and performance of one’s procedure drastically.Cautionary Note: Yet again, for those who are not an state-of-the-art consumer it’s very encouraged that you simply refrain from editing your Windows Registry manually. Dirt 3 skidrow xlive.dll error.

2. Run function RSDRI_DF_CONFIGURE.

3. Configure the callback (use the host name of the BI server to avoid confusion) and clear the top and bottom fields (I_ONLY_CHECK).

4. Execute and launch SM59 to verify that:

5. The right Gateway Host is selected.

6. The message server is picked up automatically since it is configured.

7. Alternative, the application server is used as the gateway host.

8. The right gateway service is selected.

9. This can be the application gateway service, which defaults to the system number e.g. sapgw02 where system number is '02'.

10. It is recommended to use the gateway service of the message server

Connecting to a message server in a deployment comprising of a message server and two or more application servers

1. Create manual callback (RFC destination) in transaction SE37

2. Confirm that it is created with the right gateway host and gateway service in SM59

3. Go to IDT and create a new connection.

4. Populate the message server

5. Populate the logon group (This is important if you are leveraging load balancing)

6. Select a table and activate it.

7. DO NOT TEST!

8. Activate the connection.

9. Go to Data Federation Administration and the configure Tab.

1. ProgramIDMapping (MYHOST.AdaptiveProcessingServer=DF_JCO_MYHOST)

2. GatewayServiceName

3. GatewayHostname

4. Save the connection

5. Restart the adaptive processing server as it may retain previous connections resulting in a “dead server state”.

Big 5 personality questionnaire pdf sample.

Connecting directly to an application server in a load balanced configuration

1. Follow the steps outlined in the manual connection

2. In IDT, use the Application server radio button to enter the application server

If you intend to have an application server for administrative purposes do not include this server in the server group. Maintain itseparately.

Note instead that the default automatic configuration mode works only with standard SAP install configurations. In some cases where a complex cluster of SAP servers is installed with load balancing capabilities, the automatic configuration mode may not identify correctly the cluster configuration or may not chose the desired or correct SAP gateway system to register the Data Federator server with. In such configurations where load balancing configuration was configured on the SAP

Potential Errors

This is an error connecting to BW credentials or authorizations are insufficient

Error when opening an RFCconnection (CPIC-CALL: ' ThSAPOCMINIT'
(Kbase 1847847 - BI 4.0 Data Federator: Error when opening an RFC connection * )

Gateway connectivity errors

Could not start JCo Server. See the trace log file 'dev_jco_rfc.trc' for more details.
dev_jbo_rfc.trc can be found in the directory
C:Program Files (x86)SAP BusinessObjectsSAP BusinessObjects Enterprise XI 4.0win64_x64
It will contain detailed information about the actual error.

dev_jco_rfc.trc errors
- message: Connect to SAP gateway failed
  error: hostname 'xxxxxx' unknown
  Kbase 1848998 - BI4.x: Error JCO server is dead / could not start JCo Server and Connect to SAP gateway failed
- message: CPIC-CALL: SAP_CMACCPTP3 on convId:
  error: registration of tp DF_JCO_{BOE-Server-Name}_{number} from host {host} not allowed
  Return code: RFCIO_ERROR_REGISTRATION_DENIED(35)
  Kbase 1806694 - BI 4.0: DF_JCO destination fails when testing relational connection in Information Design Tool (IDT)

This is basic configuration errors no gateway configured for the message erver

JCO_ERROR_ILLEGAL_STATE: Current server state dead
This is basic configuration errors

GATEWAY Wiki and how to disable https://wiki.scn.sap.com/wiki/x/4QCZFg

Wiki: Gateway security settings - extra information regarding SAP note 1444282

Wiki: Gateway Access Control Lists

Wiki: RFC Connections Mapping Scalability

Related Notes

вторник 07 апреля
28

Sap Sm59 Registered Program