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.

CRM Dashboard Data That Matters Most to Executives

Manufacturing is a business similar to others in many ways. Similar financial metrics measure company performance. The same financial standards provide the basis for corporate governance across many industries.

However, manufacturing operations need constant management in ways other types of companies do not. Tweaks to the production schedule occur constantly based on changing orders and the availability of raw materials and labor. The main driver of that volatility is demand, and the best place to look at demand is the customer relationship management (CRM) system.

The CRM system, when used properly, is a forward-looking view into what will be bought and by whom. This information is critical to running a manufacturing operation. Manufacturing senior management needs these numbers to be easily and quickly accessible. The obvious solution is a dashboard.

History

The metrics used to manage manufacturing aren’t new—in fact, they have been around for decades. Technology, though, is making them easier to calculate and distribute to executive who need them.

In the past, assistants would gather data from people or printed reports, combine the data into spreadsheets, and then make the calculations. Technologically savvy executives would open their own spreadsheets to view the results; others would have their assistants print the spreadsheets and put them into the inbox on their desk. The data for sales would come from sales managers, who compiled the data from conversations and forecasts from individual salespeople.

This was a highly manual process. Now, the CRM system has all the same data (and more), accessible anytime.

Dashboard Architecture

Dashboards provide a mechanism to reduce the manpower needed to generate key metrics. Companies need to go all in with dashboards, though. If some metrics are on dashboards and some are still in spreadsheets, the dashboard is just another place among several to get critical information.

To make the dashboard a good investment for companies, it must be the go-to interface. Admittedly, most companies do not have the resources to move everything to the dashboard all at one time. It needs to be a mid-term objective.

CRM data are a key part of the numbers delivered through dashboards. For many manufacturers, it’s also the most exciting data and likely the first subject area to be covered with a dashboard.

What to Put on the Dashboard 

Dashboards are as individual as the companies that use them. Different product mixes, customer mixes, and—more importantly—different management styles mean that different metrics have different importance. This is doubly true when looking at sales, salespeople, and CRM data.

There are a few common metrics that manufacturers need from the CRM system.

Sales Performance 

First, manufacturing executives need to be able to judge the performance of their salespeople. The CRM system easily shows the numbers of sales, dates, amounts, and customers. Adding these up and tossing the one-time measurement onto a screen is fine, but it’s better to show the data as a trend. This is the heart of the data coming from the CRM system—looking at sales history. With just a bit of IT development effort, many different views of salesperson and customer performance can be created. The executive needs two starting places: the aggregated trend, viewed with the ability to drill deeper to get more granular with the data, and an exception lists that shows critical areas that require immediate attention.

Forecasting

The other big area is forecasting. Although the history of sales might be reportable from the enterprise resource planning system, future sales are only within the CRM system. The philosophy is the same as when looking at historical data with a slightly different focus. The executive needs to see the forecast trend by product more than by salesperson. Production planning is driven by sales, but planning for production is driven by the forecast.

In the same vein, material outages and other critical events need to be put on the exception report for proper executive attention.

Ongoing Efforts

As products, customers, and management personnel change, so will dashboards, although the heart of the dashboard will remain the same. Manufacturers that embrace dashboards at the primary executive reporting vehicle enjoy access to CRM data that were previously labor intensive to obtain