Configuring the IDOC Adapter in SAP XI

 

STEP 1 : Use transaction SM59 on the Integration Server to establish communication with the SAP backend system.

 1. Using transaction SM59, create an RFC destination of connection type 3.

2.

Enter the logon information:

The logon language must be the same as the language of the payload content, for example, for Japanese payload the language must be JA. Otherwise, the content will be corrupted in the target system.

3. Test the connection by choosing Test connection and Remote logon. Both tests must be successful.

If the user in the target system is a background user or does not have sufficient authorization no logon screen will be displayed.

 

STEP 2 : On the Integration Server, configure the port for IDoc communication.

Call transaction IDX1 to create a port.

The Port name must have the format SAPxxx, where xxx is the system ID of the SAP backend system.

The

Client must be the client number of the SAP backend system. Select the RFC Destination that was created in the previous step.

IDoc metadata is client-independent. Therefore, only the smallest client is used.

The fields

Partner No. and Partn. Type are not used; leave them empty.

 

STEP 3 : Create or verify the logical system name on the SAP backend system.

1. Either call transaction SALE on the SAP backend system and choose Define Logical System or call transaction BD54 directly without going through the Implementation Guide (IMG).

 2. Create or verify the logical system name.

 

STEP 4 : Create or verify the business system in the SLD.

The business system name for the SAP backend system must contain a valid

Logical System Name. This Logical System Name is the one that was verified or created in the previous step.

In the SLD, select the SAP backend business system, or create one if none exist. Verify the

Logical System Name.

1. In the Integration Directory, choose the business system
In the menu, choose Service • Adapter-Specific Identifiers.
If the information is empty or incorrect,you have to synchronize it with the content of the SLD. Follow the steps
below for synchronization.

2. (Optional): Synchronization of the business system in the Integration Directory with the business system in the SLD.
Choose the business system in the Integration Directory. Switch to Edit mode.
In the menu, choose Service • Adapter-Specific Identifiers.

3. (Optional): In the dialog box, choose Compare with System Landscape Directory to re-synchronize.

4. (Optional): If the data expected from the SLD is not updated, the SLD cache may need to be cleared first.

 

STEP 5 : Verify or add the logical system name for the sender business system.

If the sender system is a third-party business system, repeat above 2 steps.

for the sender system. The sender business system must have a logical system name. Otherwise, the IDoc cannot be delivered.

If the sender business system already exists, but does not have a logical system name, the name can be added using the SLD.

1.

In the SLD, navigate to the business system and choose Change.

2.

Enter the Logical System Name and choose Save.

3. Re-synchronize the Integration Directory by following the synchronization instructions in above section .

 

STEP 6 : Create/configure the communication channel for the receiver IDoc adapter.

In the Integration Directory, create an IDoc receiver communication channel.

The

RFC Destination is the one from Step 1.

The

Port is the one from section  Step 2.

The

Segment Version is either empty or smaller than the SAP Release.

If you want to use IDoc parties as senders or receivers with a party type other than LS, select the check box

Apply Control Record Values from Payload.

 

NOTE:

There is no need to create a communication channel for the IDoc sender. Instead, the SAP backend system must be configured to send the IDoc to the Integration Server.

 

Problems with RFC Resource Assignment

 

You have defined your parameters so  that resource bottle necks will not arise. Your applications make RFC calls of the permitted types only. Yet you have realized that more work processes than allowed are occupied with RFC calls.

This can happen in the following circumstances:

1. An asynchronous RFC transmits a synchronous RFC

The asynchronous RFC transmits one or more synchronous RFC calls in the destination system. For these the profile parameters are only valid if rdisp/rfc_check is set to 3 in the target system.

2. SAPLARFC occupies all work processes

In the Work Process Overview of an instance (transaction SM50), you can see that many dialog work processes are occupied with the program SAPLARFC. You might also see update or batch processes with the status stopped RFC.

This is because in transaction SMQS as many tRFCs were started at the same time as the parameter settings allow and this has resulted in the user contexts losing their rollability.  This situation arises for instance when mass data is processed. See SAP note 726148 for more information and possible solutions.

 

Dynamically Configuring RFC Quotas in SAP System

 

The report RSARFCLD is used to dynamically configure the RFC quotas on the server to which you are logged on.

Unlike parameter changes in the profile, these settings are lost when you next restart the computer.

Procedure

Execute the transaction SARFC.

You are then shown which servers are currently available in the system, and how the system is handling resources for asynchronous RFCs on the servers

If you double-click on a server name, a dialog box appears in which you can change the values for your server.

If you have the necessary authorization, you can enter change mode and change the values.

The values that you set here overwrite (until the next restart) the following parameter values (in the same order):

rdisp/rfc_use_quotas

rdisp/rfc_max_queue

rdisp/rfc_max_login

rdisp/rfc_max_own_login

rdisp/rfc_max_own_used_wp

rdisp/rfc_min_wait_dia_wp

rdisp/rfc_max_comm_entries

rdisp/rfc_max_wait_time

Choose  Save to activate the new values.

Note that the settings you make using the report only apply to the instance to which you are currently logged on, and are lost when the instance is next restarted. The parameter settings in the profile file then apply again.

 

Note the following points when configuring the system:

i.The number of available resources in the system is a snapshot relating to the current workload in the system. No program can assume that these resources will also be available long term.

ii.If one of the quotas is exceeded, no resources are returned to the caller.

iii.The calculated resources are not reserved for the caller. Thus it could happen that competing programs are calculating resources at the same time, and are occupying more dialog work processes than has been set in the quota.  A program therefore cannot assume that the resources calculated are actually also available.

 

Configuring the SAP System for Parallel RFCs

 

You can optimize the configuration of your SAP system for the purposes of working with parallel RFCs.

To use parallel RFCs effeciently, your system has to be configured accordingly and must meet the following prerequisites.

More dialog work processes than non-dialog work processes have to be configured on every server that is available for processing parallel RFCs.

The profile parameter rdisp/wp_no_<wptyp>uses <wptyp> = dia, spo, upd, up2, btc to determine the number of work processes of one type. This number is not, however, necessarily the most up-to-date number, as the work process types can be changed while the server is in operation (by means of operation mode switching, for example). You can find out the current number of work processes in the Process Overview

A range of profile parameters is available for resource distribution during the processing of parallel RFCs.

rdisp/rfc_check

rdisp/rfc_use_quotas

rdisp/rfc_max_queue

rdisp/rfc_max_login

rdisp/rfc_max_own_login

rdisp/rfc_min_wait_dia_wp

rdisp/rfc_max_own_used_wp

rdisp/rfc_max_comm_entries

rdisp/rfc_max_wait_time

For more parameters to do with RFC, open transaction RZ11 and search for isp/rfc*.

Note that the parameters rdisp/rfc* only apply to the above-mentioned RFC types, and not to any other types, such as synchronous RFC or asynchronous RFC without a group.

In other words, the parameters only apply to qRFC and parallel RFC.

The standard values for the quotas are restrictive, since you must assume that dialog users are also active in the system and they are given priority. You can set the maximum resources for RFC users as follows.

rdisp/rfc_max_login        = 100

rdisp/rfc_max_own_login    = 100

rdisp/rfc_max_own_used_wp  = 100

rdisp/rfc_max_comm_entries = 100

These can of course affect the response time for dialog users.

 

Monitoring RFC Resources on the Application Server

 

Execute the transaction SARFC.

You then see a list of all SAP servers with information for each server, stating whether resources for asynchronous RFCs are available at the time you executed the transaction (text Resources ok) . If no resources are available, a short text explaining the reason is displayed.

Note that this list only represents the situation at the exact moment that you executed the transaction. Choose Refresh to update the display.

This is a list of the possible results of the resource check with return values and meanings.                                                 

0: resources are available on the server. The text 'Resources ok' is displayed.                                               

1:The resource check is deactivated (parameter rdisp/rfc_use_quotas is set to 0).                                                    

The other return values indicate that the server currently has no available resources for asynchronous RFCs.                              

The server may have no resources for one of the following reasons:

·        The server is not running.

·        The server has been wrongly configured.

·        An unexpected error has occurred.

In these cases, the text appears on a red background. You can find out the exact cause of the problem (for example, where exactly the incorrect configuration is located) by briefly activating and deactivating the trace for the server (see below). See the dispatcher trace file dev_disp of the server for the required information.

The individual return values are described below. Each value has a text (appears on a yellow background).                         

2: The server has too few free dialog work processes.                    

 3: The quota for the RFC communication channels is too small. Increase the parameter rdisp/rfc_max_comm_entries or change the value dynamically.                  

4: the quota for the RFC communication channels (rdisp/rfc_max_comm_entries) has reached its maximum.                            

5: The local queue for asynchronous RFC responses is full. This queue retains the responses to asynchronous RFCs until they are sent back to the caller. You can increase the size of the queue by increasing the value of the parameter rdisp/max_arq.            

6: The quota for a dialog work process occupied by an RFC user is too small. Increase the size of the parameter rdisp/rfc_max_own_used_wp or change the value dynamically.                                             

7: the quota for a dialog work process occupied by an RFC user (rdisp/rfc_max_own_used_wp) is too small.                            

8: The quota for the RFC requests in the dialog queue is too small. Increase the size of the parameter rdisp/rfc_max_queue or change the value dynamically.                                                                                

9: the quota for the RFC requests in the dialog queue (rdisp/rfc_max_queue) has reached its maximum.                                  

10: An error occurred when the request queue length was being determined.

11: The quota for RFC logons to the server is too small. Increase the size of the value of the parameter rdisp/rfc_max_login.              

12: the quota for RFC logons to the server (rdisp/rfc_max_login) has reached its maximum.                                  

13: The quota for "own" RFC logons to the server is too small. Increase the size of the parameter rdisp/rfc_max_own_login or change the value dynamically.          

14: the quota for own RFC logons to the server (rdisp/rfc_max_own_login) has reached its maximum.                              

15: The server has been deactivated and cannot process any requests.

16: The server is being stopped.                             

17: The server has been stopped.                                   

18: The server is being started.

19: The server has just been started and is in the initialization phase.                                           

20: The server is in an unknown state.       

 

Activating the Trace

Choose Goto ® Activate Trace. The system then writes the detailed result of the check to the trace file of the dispatcher on the server in question. To read the file, you have to log on to the server in question. To do this, open transaction SM51, double-click on the server name, then choose Process ® Trace ® Dispatcher ® Display File).

It may make sense to do this if, for example, a server constantly has too few resources, and you want to find out the exact cause.

 

Configuring HTTP and RFC Connections in SAP XI / PI

 

Local RFC Connections

For local RFC connections between AS ABAP and AS Java (that is, for RFC connections within the same instance), the variable $$ is used for local addressing.

1. Specify the following parameters:

   • hostname: localhost

   • gwservice: 'sapgw$$'

   • instno: '$$'

   At runtime, rfcengine substitutes '$$' with the local instance number.

 

RFC and HTTP Destinations on the Integration Server

AS ABAP

1. Call transaction SM59.

2. Choose the HTTP destination INTEGRATION_DIRECTORY_HMI.

3. Set the HTTP connect data to <virtual host>:<httpport>.

4. Choose the RFC destination AI_RUNTIME_JCOSERVER.

5. Delete the gateway settings.

6. Repeat step 5 for the following RFC destinations:

   • LCRSAPRFC

   • SAPSLDAPI

AS Java

1. Start the SAP NetWeaver Administrator.

2. Choose  Configuration Management Infrastructure Management Jco RFC Destinations .

3. Select the RFC destination AI_RUNTIME_JCOSERVER.

4. Change the gateway connection data to localhost, sapgw$$.

5. Change the repository connection data to localhost, $$.

6. Repeat steps 4 and 5 for the following RFC destinations:

   • LCRSAPRFC

   • SAPSLDAPI

7. Choose  Configuration Management Security Management Destinations .

8. Select the HTTP destination pmistore.

9. Set the HTTP connect data to <virtual host>:<httpport>.

 

External RFC and HTTP Destinations

RFC and HTTP destinations to the Integration Server should address the load balanced components Message Server and Web Dispatcher.

 

Important Tcodes in SAP XI

SXMB_IFR -> Start Integration Builder
SXMB_MONI -> Integration Engine - Monitoring
SXI_MONITOR -> XI: Message Monitoring
SXI_CACHE -> To Access IS runtime cache
SLDCHECK -> Test SLD Connection
SLDAPICUST-> SLD API Customizing
SXMB_ADM -> Integration Engine - Administration
SXMB_MONI_BPE -> Process Engine - Monitoring
SPROXY-> ABAP Proxy Generation
IDX1-> Port Maintenance in IDoc Adapter
IDX2-> Meta Data Overview in IDoc Adapter
IDX5 -> monitocr idoc adapter
IDXP - > to monitor the message packages
SMICM -> J2EE administration
SICF -> http server configuration
SMGW -> trace, alzare livello di trace
SMQ1-> qRFC Monitor (Outbound Queue)
SMQ2-> qRFC Monitor (Inbound Queue)
SMQS - > to register the destination in QOUT scheduler
SMQR - > to register the queue
RZ70-> SLD Administration
SM58-> Asynchronous RFC Error Log
SM59-> RFC Destinations (Display/Maintain)
BD64 -> modelli di distribuzione
BD87-> Status Monitor for ALE Messages
WE02-> Display IDoc
WE05-> IDoc Lists
WE19-> Test tool
WE09-> Search for IDocs by Content
WE20-> Partner Profiles
WE21-> Port definition in XI
WE60-> Documentation for IDoc types
SWXF_PBUILDER -> for Detail BPM Process
DXPW - > to activate the IDOC message package
WEOUTQUEUE - > to start the queue processing

Deleting the SLD Cache in SAP XI

 

Many actions require to access System Landscape Directory content from the Integration Builder. To optimize performance, this content is loaded into a cache so that the System Landscape Directory does not have to be accessed directly each time that System Landscape Directory content is required.

However, this cache is not automatically updated if changes are made to the content of the System Landscape Directory. For this reason, SAP recommends that you delete the System Landscape Directory cache if changes have been made to content in the System Landscape Directory. The cache is then filled each time that the System Landscape Directory is accessed. If you log on to the Integration Builder after you have made a change in the SLD, you do not need to delete the SLD cache.

To clear the SLD cache, from the Integration Builder main menu, choose Environment  ®  Delete Cache for SLD Data.

* Once you have deleted the cache for SLD data, accessing objects in the SLD may take longer than usual initially.

In the case of input helps for business systems in the Integration Directory (for example, when defining a business system service), the Integration Builder accesses the SLD cache and does not access the SLD directly. When you create a new business system in the SLD, the information about this business system is not automatically added to the SLD cache. For this reason, this business system is not displayed when the input help is called. The new business system is only displayed in the input help once the SLD cache has been deleted.

 

System Landscape Directory(SLD) in SAP Exchange Infrastructure

 

The SAP System Landscape Directory (SLD) is the central information provider in a system landscape.

The SLD contains two types of information:

·        Component Information: This is information about all available SAP products and components, including their versions. If there are any third-party products in the system landscape, they are also registered here.

At design time of the integration objects, the component information is extracted from the SLD to define integration scenarios.

·        Landscape Description: This contains all installed systems in a system landscape.

When a collaborative business process is configured, the landscape descriptions are needed to determine the system information of the business partners involved.

SAP recommends that you use one SLD.

If you have more than one SLD instance, you must ensure that all content is synchronized. The SLD has export and import functions for this purpose.

 

 

Integration

To be able to address business systems as senders or receivers of messages during configuration, you must first have defined them as services in the Integration Directory.

The runtime environment of SAP Exchange Infrastructure sends the address of the Integration Server of a business system to the SLD.

·        Business systems are logical systems that communicate with each other within SAP Exchange Infrastructure by sending and receiving messages. They can be SAP or third-party systems.

¡        An SAP system has one or more clients that function independently of each other as logical units at runtime. Each of these clients represents a business system in SAP Exchange Infrastructure.

¡        A third-party system is also a logical unit that functions as a sender or receiver. Therefore, third-party systems are also business systems in this sense.

·        An Integration Server enables communication between business systems at runtime. It cannot execute business logic.

You can assign a group of business systems to an Integration Server. A business system group is a logical grouping of business systems that use an Integration Server to communicate with each other.

Changes in the SLD

After you have made any changes in the SLD, always ensure that you clear the SLD cache in the Integration Directory/Integration Repository. Only once you have done so can you access up-to-date SLD content

Example of Changes in the SLD

Change in the SLD	Effect in the Integration Directory/Integration Repository
Create/delete a business system	Integration Directory: The input help for business systems (for example, when you define a business system service) is only updated once you clear the SLD cache.
Delete an Adapter Engine	Integration Directory: The input help for Adapter Engines in the communication channel is only updated once you clear the SLD cache.

In the following cases, ensuring that a change made in the SLD has also taken effect in the Integration Repository/Directory requires manual effort.

Changes in SLD and Additional Activities in the Integration Builder

Change in the SLD	Effect in the Integration Directory/Integration Repository
Change a product or a main instance	Integration Repository: For this change to take effect in all integration scenarios that use the product or main instance, you must update the application components.
Change a business system (registered as an SAP or Non-SAP) system	Integration Directory: For this change to take effect in the relevant business system service, you must compare the data with the SLD .
Change a business system (adapter-specific identifiers, for example, the logical system)	Integration Directory: For this change to take effect in the relevant business system service, you must compare the data with the SLD .

 

Java Proxy Generation in SAP XI

 

Using the Java proxy generation function, you can generate Java classes or Java proxy objects from the interface description in the Integration Repository. Using these objects, you can then implement sender and receiver applications in Java; the proxy objects establish the connection to the Integration Server by using the Java proxy runtime.

You can generate Java proxies for J2EE applications on the SAP Web AS. Proxy generation generates J2EE beans and proxy classes for this purpose. The generated beans satisfy the EJB 2.0 standard.

 

Java proxy generation is part of the Integration Builder and has the following functions:

·        Create an archive (as a Jar or Zip file) by using one or more message interfaces from the same software component version. The archive contains bean and proxy classes.

·        Open existing archives to regenerate proxies. Proxy generation knows the original message interfaces for which proxy objects are contained in the archive.

 

Selecting Message Interfaces

You can call Java proxy generation from the design maintenance screen of the Integration Builder in the following ways:

·        From the main menu, choose Tools ® Java Proxy Generation.

·        From the context menu, choose Java Proxy Generation... for message interfaces in the navigation tree.

The latter method has the advantage that the selected message interface and the corresponding software component version can be copied directly. You can only generate proxy classes for message interfaces and not for sub objects of message interfaces.

 

Creating New Archives and Changing Existing Archives

The first step when generating a Java proxy is to specify an archive (in Jar or Zip format). You have two alternatives:

·         You can create a new archive. If you select an archive that already exists here, it will be overwritten.

·         You can change an existing archive. Choose this option when you want to regenerate proxy objects. Java proxy generation recognizes which message interfaces already have proxies in the archive so that these proxies can be regenerated as well. You can only regenerate proxy classes for the entire message interface.

 

Activities

       1.      Navigate to the design maintenance screen of the Integration Builder.

       2.      Start proxy generation as described above and follow the instructions.

The resulting archive contains the corresponding Java source text files of the Java proxy objects.

Tips

·        Technically speaking, a Jar archive corresponds to a Zip archive. You can view the contents of the generated Jar archive in Windows, using WinZip, for example. Using the jar command, you can display the contents by using jar -tf <Filename> and read the contents by using jar -xf <Filename>.

·        To gain an overview of the generated classes, generate it with javadoc HTML documentation.

 

ABAP Proxy Generation in SAP XI

 

Using ABAP the proxy generation function you can generate ABAP proxy objects to an SAP system from an interface description in the SAP Exchange Infrastructure Integration Repository. 

ABAP proxy objects can only be generated for SAP systems that are based on SAP Web Application Server 6.40.

The proxy generation retrieves the WSDL description of the interface from the Integration Repository using HTTP. The address of the appropriate server is taken from the exchange profile (parameters 1, 2, and 3 – see below). Queries to the Repository are subject to authentication. The user and password for these queries are also taken from here (parameters 5 and 6). Information used to navigate from the ABAP Proxy Generation to the initial page of the Integration Builder is also taken from the exchange profile (parameters 1, 2, and 4).

Example configuration for accessing
interfaces in the Integration Repository (exchange profile)

No.	Section	Parameter	Value (Example)
1	Connections	com.sap.aii.connect.repository.name	pwdf0436
2	Connections	com.sap.aii.connect.repository.httpport	1080
3	Connections	com.sap.aii.connect.repository.contextRoot	rep
4	Connections	com.sap.aii.connect.integrationbuilder.startpage.url	rep/start/index.jsp
5	ApplicationSystem	com.sap.aii.applicationsystem.serviceuser.name	hugo
6	ApplicationSystem	com.sap.aii.applicationsystem.serviceuser.pwd	hugopass

These parameters are not to be set by developers but by the administrator responsible for the technical configuration of the XI system landscape.

You must also have created message interfaces in the interface maintenance of the Integration Repository before you can generate for these proxies.

Integration -

You can send and receive messages using the generated ABAP proxies.

Features

You can edit ABAP proxy objects either in the Object Navigator (transaction SE80) or in transaction SPROXY:

·        The Object Navigator displays proxy objects created in the system in the navigation tree under Enterprise Services ® Web Service Library (client proxies, server proxies, and proxy Dictionary-objects). When you create new proxy objects, the hierarchy of software component versions from the Integration Repository is displayed in a dialog box.

·        You can display the interface objects from the Integration Repository by using the navigation tree in transaction SPROXY. If no connection to the Integration Repository exists, the tree presents an overview of those interface objects for which a proxy object already exists in the system.

Both transactions show the following information on the right-hand side:

Tabs displayed when generating an ABAP proxy

Tab Page	Meaning
Properties	Generation attributes such as package, last changed by, and so on. For inbound proxies, specify the name of the implementing class here.
Name conflicts	This tab is only displayed immediately after the proxy is generated. It allows you to correct names that were truncated during generation, or that needed to be changed because a collision occurred.
Generation	A list of all the objects generated for an object
Structure	This tab is similar to the Generation tab, except that here the objects are sorted according to their use in a tree structure. Example:   Class CO_X     ->Method MYMETHOD       ->Importing OUTPUT
Documentation	The system displays the documentation from the Integration Repository for the outbound object.
Type mappings	Even if a proxy was generated successfully, there are cases when generation was only possible due to implicit acceptance (for example, restrictions to the value range are checked by the programmer). If such situations arose during generation, they are listed in an application log.

Accessing Interface Objects

Object	SE80	SPROXY
Generated Objects	Navigation tree in object navigator	Navigation tree in transaction SPROXY
Integration Repository Objects	Popup with hierarchy of software component versions	Navigation tree in transaction SPROXY

Software component versions and namespaces of the Integration Repository are only displayed if they are available locally in the system. The selection of software component versions in the navigation tree in the SPROXY or SE80 dialogs is also a subset of the software component versions of the Integration Repository.

All imported software component versions in CRM, ABA, or APO are displayed in the Integration Builder. Conversely, only the appropriate components of a particular version are installed in the SAP System (such as ABA 6.20 or CRM 3.0). Therefore, only these software component versions are offered.

Views in Transaction SPROXY

In transaction SPROXY, you access both Integration Repository objects and generated objects by using the navigation tree. If namespaces are deleted there, then they are no longer visible in the navigation tree in transaction SPROXY, however it is possible that proxy objects already exist in the system for these namespaces. For this reason, the navigation tree in transaction SPROXY has two views:

Proxy-Objects View (Menu Goto ® View)

View	Meaning
All Generated Objects	You can access all proxy objects that have ever been created in the system. You only require this view if namespaces or software component versions have been deleted in the Integration Repository. All generated objects are displayed in the navigation tree in transaction SE80.
Integration Repository Objects (Default Setting)	You can access all interface objects that are currently visible in the Integration Repository, as well as the corresponding proxy objects.

 

Activities 

       1.      Generate ABAP proxy objects for an interface or for other interface objects .

If a connection to the Integration Repository could not be established at the start of the transaction, you can ascertain more exactly what went wrong, and fix this problem (or have it fixed), by choosing Goto  ®  Connection Test.

       2.      Check whether you need to make any changes following the automatic naming of proxy objects.

       3.      If the description was changed in the Integration Repository, you must regenerate the proxy objects.