SAP CRM – SPROXY – test with XML variant

How to test Enterprise Services via Transaction code SPROXY.

We would like, for example, to test the functionality of sending a SalesOrder to SAP CRM, which was created via a front-end (Java) portal.

Step 1: Start transaction SPROXY
Search for the Service Interface for which you want to test and load a XML file. For example the standard SAP SalesOrderCRMCreateRequest_In.

Step 2: Double-click on the SalesOrderCRMCreateRequest_In to load the details and choose Execute (F8).

sproxy1

Step 3: In the next pop-up screen check if ‘Generate Request Template’ is selected and choose Execute (F8).

Step 4: In the following screen you will see the ‘Test Service Provider: Display Request’ with a example request.

There are different option in this step:
1. Choose an already defined variant via the variants button to directly test with already set-up test data
2. Load a XML file from your local computer.

sproxy2

Step 5: Choose Execute (F8) and you will get a success message ‘Succesful with empty result – commit may be required’

sproxy3

Step 6: Commit work is required to save the Sales Order in the database. Choose ‘Extra > Trigger COMMIT WORK’

sproxy5

Step 7: You will get a success message ‘COMMIT WORK triggered’

sproxy4

Step 8: Check for example via CRMD_ORDER the salesorder that has been created. Please note that you will have to search for the creation date/time that was put into the XML within <CreationDateTime> to find the specific order. Or use a reference ID (put in field BuyerID for example) to find the order via this value/field.

——————————————

Remco Jansen is working as a SAP CRM professional for various clients in the Netherlands.

SAP CRM: How to manage queues in Integration Engine (2)

In my previous post I already mentioned some (tuning) parameters for your the Configuration Engine. In this blog post I will address some interesting monitor, runtine, deletion and tuning parameters which are very usefull when using the CRM Intergration Engine.

Parameter EO_INBOUND_PARALLEL

Meaning

The parameter EO_INBOUND_PARALLEL is evaluated in the Integration Server inbound channel and in the sender and receiver Integration Engines. It determines the level of parallel processing for messages with the quality of service Service Exactly Once (EO). If the parameter in the central Integration Server has the value n, then the inbound EO message is put in a queue named <prefix><number>, where <number> is a four-digit random number between 0 and n-1 that is determined at runtime and <prefix> is the corresponding four-character queue prefix. The same applies to the Integration Engine. If both the central Integration Server and local sender and receiver clients are installed in various clients in a system, then you can set the parallel processing level for the sender, central, and receiver queues separately by using the subparameters SENDER, CENTRAL, RECEIVER, SENDER_BACK, and RECEIVER_BACK.

It is recommended that you set the parallel processing level on the central Integration Server so that it roughly corresponds to the arrival rate of messages with quality of service Exactly Once (EO).

Possible Values

1 – 10.000

 

Parameter EO_INBOUND_PARALLEL_HIGH_PRIO

Meaning

The parameter EO_INBOUND_PARALLEL_HIGH_PRIO is evaluated in the Integration Server inbound channel and in the sender and receiver Integration Engines. It determines the level of parallel processing for high priority messages with the quality of service Service Exactly Once (EO). If the parameter has the value n, then the inbound EO message is put in a queue named <prefix><number>, where <number> is a four-digit random number between 0 and n-1 that is determined at runtime and <prefix> is the corresponding four-character queue prefix. It overrides the parameters EO_INBOUND_PARALLEL and EO_INBOUND_PARALLEL_SENDER in this case.

The default value for the parameter is 0 (inactive).

Possible values

0 – 10.000

 

Parameter EO_INBOUND_PARALLEL_SENDER

Meaning

The parameter EO_INBOUND_PARALLEL_SENDER is evaluated in the Integration Server and in the sender and receiver Integration Engines. It makes it possible for messages with quality-of-service Exactly Once (EO) that were sent from a specific sender system to be processed in parallel on the Integration Server and to be scheduled in its own sender-specific queues in the sender and receiver system. When configuring the sender/receiver IDs (transaction SXMSIF), you must create an entry that specifies the identification scheme, party, and the service of the sender (normalized on the Integration Server). The interface name and namespace must have the value ‘*’. This sender ID is specified as a subparameter of this parameter.

If the parameter has the subparameter s and the value n, then the following example queue name is produced for the messages for an inbound EO message with the combination of agency, party, and service specified by s:

  • Central Integration Server: XBTI<sender abbreviation><number>
  • Receiver System: XBTR<sender abbreviation><number> or XBTB<sender abbreviation><number> for acknowledgments Sender System:
  • Sending System: XBTR<sender abbreviation><number> or XBTB<sender abbreviation><number> for acknowledgments Sender System:

<number> is a random four-digit number between 0 and n-1 that is determined at runtime. <sender abbreviation> is a four-digit value of the sender system s.

The parameter EO_INBOUND_PARALLEL_SENDER enables you to prioritize messages from particular sender systems by using separate queues for processing.

Possible values

1 – 10.000

 

Parameter EO_OUTBOUND_PARALLEL

Meaning

The parameter EO_OUTBOUND_PARALLEL defines the parallel processing level of outbound processing for messages with the quality of service Exactly Once (EO) in Integration Server. An outbound EO message is, for example, placed in the central Integration Server into an internal queue called XBTO<receiver abbreviation><number> or XBTB<receiver abbreviation><number> for acknowledgments where <number> is a random four-digit number between 0 and n-1 that is produced at runtime and <receiver abbreviation> is a four-figure value of the receiver system. If the ID of a receiver combination of identification scheme, party, and service is specified in the subparameter, a separate level of parallel processing is determined specially for this combination.

It is recommended that you set the parallel processing level in the central Integration Server to correspond to the performance of, and the burden on the received systems involved.

Possible Values

1 – 10.000

Parameter EO_OUTBOUND_PARALLEL_HIGH_PRIO

Meaning

The parameter EO_OUTBOUND_PARALLEL_HIGH_PRIO determines the level of parallel processing of the outbound processing for high priority messages with the quality of service Service Exactly Once (EO). If the parameter has the value n, then the outbound EO message is put in a queue named <prefix><receiver abbreviation><number>, where <number> is a four-digit random number between 0 and n-1 that is determined at runtime, <receiver abbreviation> is a four-character value of the receiver system that is determined at runtime, and <prefix> is the corresponding four-character queue prefix. It overrides the parameter EO_OUTBOUND_PARALLEL.

The default value for the parameter is 0 (inactive).

Possible Values

0 – 10.000

Parameter EO_OUTBOUND_PARALLEL_SPLIT

Meaning

On the Integration Server, the parameter EO_OUTBOUND_PARALLEL_SPLIT determines the parallel processing level of outbound processing for messages with quality of service Exactly Once (EO) that are converted to quality of service Exactly Once In Order (EOIO) following logical routing. This occurs when a message with the quality of service EO is split into multiple messages that are sent to the same receiver system (Interface Split) and the interface sequence must be maintained. A new name for the application queue must be generated here. This queue name is XI_SERIALIZE<number>, where <number>is determined in the same way as for the parameter EO_OUTBOUND_PARALLEL (see above).

If the parameter has the value n> 1, then number is a 4 digit-random number 0 and n-1 that is determined at runtime. If the value is n <= 1, then the queue name is simply XI_SERIALIZE. If the ID of a receiver combination of identification scheme, party, and service is specified in the subparameter, a separate level of parallel processing is determined specially for this combination.

The name of the qRFC queue is then XBQO<receiver abbreviation>XI_SERIALIZE<number>.

Avoid large parameter values when performing numerous interface splits as this will affect performance due to the large number of qRFC queues being used. However, using a parameter that is too small for application errors in the receiver system can result in the processing of other messages that happen to be in the same queue being stopped.

Possible Values

1 – 10.000

 

Parameter BALANCING

Meaning

You have set the level of parallel processing for messages to quality of service Exactly Once (EO) or are using the default settings. You determine that the parallel processing level has to be changed for processing performance reasons. This change is not only effective for messages that have been newly created. You want to distribute the messages in the existing queues across the newly specified number of parallel queues. For example, you want to distribute the backlog of messages across two queues to process them.

With the BALANCING parameter you activate the even distribution across the queues. If the maximum specified number of entries is reached in one queue then the entries are distributed to one of the other queues. The entries are specified in the parameters B_EO_IN_PARALLEL_SENDER, B_EO_OUT_PARALLEL, and B_EO_IN_PARALLEL. If the queues are distributed evenly, the BALANCING parameter is deactivated so that the messages can be processed again as ‘normal’.

If you set the maximum number of entries in a queue too low, then even distribution is permanently activated. This can lead to performance losses as the Engine is then continually dealing with distribution processes rather than processing messages.

To avoid lock conflicts, leave the configuration maintenance editing mode after you have set the parameter.

Possible Values

0 (inactive), 1 (active)

 

Parameter ENGINE_TYPE

Meaning

This parameter determines the Integration Engine type of the current client.

Possible values

UNDEFINED =Client not configured as Integration Engine.
HUB =Client configured as Integration Server.
LOC = Client configured as sender/receiver system.

Parameter IS_URL

Meaning

 

This parameter defines the URL or HTTP destination for the Integration Server or Advanced Adapter Engine. This parameter is evaluated in the HTTP communication path Sender -> Integration Server/Advanced Adapter Engine.

Possible Values

You have the following options if you want to connect your business system to an ABAP-based Integration Server: Either enter a URL in the format http://<host&gt;:<port>/sap/xi/engine?type=central or an HTTP destination in the format dest://<destination name>. No logon information (client, user, password, language) is given when the Integration Server is called in the first instance. These are saved to the service to be called. In the second instance, you must save the type H destination <destination name> by using transaction SM59. You can also save logon information there (client, user, password, language).

You have fundamentally the same options if you want to connect your business system to an Advanced Adapter Engine. You can get more details on this from the SAP Adapter documentation.

Entries from transaction SXMSIF (and thereby interfaces) can be referenced here as subparameters. These are offered in the input help. In this way it is possible to define the Integration Server interface-specifically. Permitted entries for transaction SXMSIF for this application option are ‘*’ or SPACE for partners, agencies, and schema. The component is ignored and the name/namespace of the interface must not be generic.

——————————————

Remco Jansen is working as a SAP CRM professional for various clients in the Netherlands.