Optimierung der SAP CRM Middleware - EDV-BUCHVERSAND

15

Vorwort

Die Idee zu diesem Buch wurde in einem Meeting geboren, in demdarüber diskutiert wurde, warum wir immer wieder Kunden begeg-nen, die Schwierigkeiten mit dem Betrieb ihres CRM-Systems haben.Einer unserer Kollegen sagte, das liege insbesondere an der CRMMiddleware, deren Konzept und genaue Funktionsweise nicht ein-fach zu verstehen seien. Ein anderer antwortete daraufhin, dass dieMiddleware kein Hexenwerk sei. Man müsse nur einige grundle-gende Dinge beachten, dann ließe sich auch das CRM problemlosbetreiben. Woraufhin der erste Kollege sagte: »Wo ist denn verständ-lich und umfassend beschrieben, wie die Middleware funktioniertund auf was man hinsichtlich eines optimierten Betriebs achten soll?Man müsste mal ein Buch darüber schreiben.« Gesagt, getan – nunja, ganz so einfach war es dann nicht, aber die Idee war geboren.

Seit diesem Meeting sind inzwischen einige Monate ins Land gezo-gen, und wir haben die »eine oder andere Stunde« damit verbracht,die Idee in die Tat umzusetzen. Wir möchten an dieser Stelle zu aller-erst unseren Familien für ihr Verständnis und ihre Unterstützungdanken, wenn wir uns an den Schreibtisch zurückgezogen habenoder mal wieder ein Autorentreffen notwendig war.

Zusätzlich möchten wir uns bei unseren Kollegen und Kolleginnenbedanken, die uns auf vielfältige Weise unterstützt haben.

Ganz besonders danken wir Thomas Niemtschak für viele fruchtbareDiskussionen und inhaltliche Anregungen.

Wir möchten uns weiterhin bei Dr. Barbara Kopff, Dr. Hella Kramerund Kerstin Klemisch für ihre Ratschläge und Anmerkungen und dieFreizeit, die sie investiert haben, bedanken. Außerdem danken wirAxel Semling, Dr. Alexander Pilz und Gabriele Weyerhäuser für ihreinhaltliche Unterstützung.

Unser Dank gilt auch Florian Zimniak vom Verlag Galileo Press fürdie sehr angenehme und konstruktive Zusammenarbeit.

Wir wünschen Ihnen nun viel Freude beim Lesen dieses Buches undErfolg beim Betrieb Ihres SAP CRM-Systems.

Juliane Bode Stephan Golze Thomas Schröder

846-0.book Seite 15 Montag, 2. April 2007 12:07 12

203

Daten, die an das CRM geschickt werden, landen in der Regel zunächst in den Eingangs-Queues und werden dann von der CRM Middleware weiterverarbeitet. Es ist daher nicht überra-schend, dass die Eingangs-Queues die erste Stelle in der CRM Middleware sind, an der eine Optimierung beginnen kann.

8 Eingangs-Queues

Von den verschiedenen Systemen, die an ein CRM angeschlossenwerden können, ist es insbesondere das R/3, das durch große Daten-mengen dem CRM Probleme bereiten kann. Wird im R/3 ein Busi-ness-Objekt geändert, wird die Änderung direkt ans CRM übertragenund in einer Eingangs-Queue gespeichert. Der Eingangs-Queue-Sche-duler nimmt die Daten aus der Queue und übergibt sie dem R/3-Adapter (siehe Abbildung 8.1).

Abbildung 8.1 Eingangs-Queues in der CRM Middleware

Eingangsverarbeitung

MobileClients

Ausgangs-Queues

Ausgangsverarbeitung

Validierung

Synchronization Flow

CRM- Applikation

Mobile Bridge

Mobile-Adapter

R/3

Groupware Groupware-Adapter

R&R-Service

XML

sBDoc

mBDoc

CDB

Online-DB

CDB-Service

R/3-Adapter

Groupware-Adapter

Mobile-Adapter

BAPI R/3-AdapterR3A*

ISP*

CRM SITE*

CRM SITE*

CRM SITE*

Validierungsservice

sBDoc

Replikationsservice


MobileClients

Ausgangs-Queues


Validierung


CRM- Applikation

Mobile Bridge

Mobile-Adapter

R/3

Groupware Groupware-Adapterp

R&R-Service

XML

sBDoc

mBDoc

CDB

Online-DB

CDB-Service

R/3-Adapter

Groupware-Adapter

Mobile-Adapter


ISP*

CRM SITE*

CRM SITE*

CRM SITE*

Validierungsservice

sBDoc

Replikationsservice

Eingangs-Queues

sBDoc

XML

BAPI

mBDoc

CRM SITE*

R3A*

ISP*

CSA*

CRM SITE*

CRM SITE*MobileClients

R/3

Groupware


204

Eingangs-Queues8

Diese Deltaversorgung funktioniert im normalen Betrieb gut. Wennaber ein angeschlossenes System viele Daten schneller sendet, als dasCRM sie verarbeiten kann, stauen sich die Daten in den Eingangs-Queues, und es kann bei falschen Einstellungen zu den entsprechen-den Auswirkungen kommen, wie sie in Kapitel 7, Einführung in diePerformance-Optimierung, exemplarisch beschrieben wurden. DasZiel sollte daher sein, die Eingangs-Queue-Verarbeitung so weit wiemöglich zu optimieren.

Alle Queues in der CRM Middleware basieren auf dem RFC. Der RFCist damit von zentraler Bedeutung für die Verarbeitung in der Midd-leware. Die Eingangs- und Ausgangs-Queues sind mit Hilfe des qRFCrealisiert, die R&R-Queues basieren aber nicht auf dem qRFC, son-dern auf dem tRFC. Ferner ist es wichtig zu beachten, dass neben denR3A*-, ISP*- und CRM_SITE*-Eingangs-Queues auch die CSA*-Queues ab dem CRM-Release 4.0 als Eingangs-Queues realisiert sind.Abbildung 8.2 zeigt die CRM Middleware aus Sicht des RFC. Für alleEingangs-Queues gibt es nur einen Eingangs-Queue-Scheduler.

Abbildung 8.2 RFC in der CRM Middleware

Eine detaillierte Beschreibung der Eingangs-Queues und des qRFCfinden Sie in Kapitel 2, Eingangsverarbeitung und Validierung.

Eingangs-Queues

�


MobileClients

Ausgangs-Queues

�


Validierung


CRM-Applikation

Mobile Bridge

Mobile-Adapter

Replikationsservice

R/3


R&R-Service

XML

sBDoc

mBDoc

sBDoc

XML

BAPI

mBDoc

CDB

Online-DB

CDB-Service

CRM SITE*�

R/3 Adapter

Groupware Adapter

Mobile-Adapter

BAPI R/3-Adapter

�

R3A*

ISP*

R3A*

ISP*

CSA*

CRM SITE*

CRM SITE*

CRM SITE*

CRM SITE*

CRM SITE*

Validierungsservice

sBDoc

MobileClients

R/3

Groupware

MobileClients

Ausgangs-Queues

�


Synchronization FlowMobile Bridge

Mobile-Adapter

Replikationsservice

R/3

Groupware Groupware-Adapterp

R&R-Service

XML

sBDoc

mBDoc

CDBCDB-

Service

BAPI R/3-Adapter

�

R3A*

ISP*

CSA*

CRM SITE*

CRM SITE*

CRM SITE*

sBDoc

MobileClients

R/3

Groupware

Eingangs-Queues

�


Validierung

CRM-Applikation

mBDoc

sBDoc

XML

BAPI

Online-DB

CRM SITE*M S�

R/3 Adapter

Groupware Adapter

Mobile-Adapter

R3A*

ISP*

CRM SITE*M S

CRM SITE*M S

Validierungsservice

Ausgangs-qRFC

Eingangs-qRFC

tRFC

Eingangs-qRFC


205

Die Anzahl der Eingangs-Queues ist zu hoch 8.1

ProblemursachenEine langsame Abarbeitung der Eingangs-Queues kann verschiedeneUrsachen haben:

� Es werden so viele Eingangs-Queues erzeugt, dass der Eingangs-Queue-Scheduler Probleme mit der Queue-Verarbeitung hat(siehe Abschnitt 8.1).

� Es werden nur wenige Queues erzeugt, die aber sehr viele Daten-sätze enthalten, und die verfügbaren Ressourcen im CRM könnennicht effektiv genutzt werden (siehe Abschnitt 8.2).

� Alle Workprozesse des CRM-Systems werden von der Eingangs-Queue-Verarbeitung belegt, und es kommt zu einem Ressource-nengpass, der die Verarbeitung verlangsamt (siehe Abschnitt 8.3).

� Die Eingangsverarbeitung der einzelnen Datensätze ist langsam(siehe Abschnitt 8.4).

� Es gibt Abhängigkeiten zwischen den Eingangs-Queues (sieheAbschnitt 8.5).

In den folgenden Abschnitten werden wir auf die verschiedenenUrsachen eingehen und Lösungen vorstellen.

8.1 Die Anzahl der Eingangs-Queues ist zu hoch

Der Eingangs-Queue-Scheduler sorgt dafür, dass die Eingangs-Queues parallel abgearbeitet werden. Er belegt dazu alle Workpro-zesse, die ihm zur Verfügung stehen. Mit steigender Anzahl vonQueues nimmt aber die Performance des Schedulers ab. Ab 10000Eingangs-Queues ist eine Performance-Verschlechterung deutlichspürbar. Im schlimmsten Fall verschlechtert sich die Performance sosehr, dass es länger dauert, den nächsten Queue-Eintrag einem freienWorkprozess zuzuordnen, als den Eintrag selbst zu verbuchen. Per-formance-technisch betrachtet bedeutet dies, dass die Eingangs-Queues de facto sequenziell und nicht mehr parallel abgearbeitetwerden und die verfügbaren Hardwareressourcen nicht genutzt wer-den (siehe Beispiel). Die einzige Möglichkeit, dies zu verhindern,besteht darin, die Anzahl der Eingangs-Queues im CRM zu limitie-ren.


206

Eingangs-Queues8

Lösungsansätze Es gibt drei Ansätze, um die Anzahl der Eingangs-Queues zu verrin-gern: 1 2

� Reduktion der Einzelsätze im R/3

� Änderung der Queue-Namensgebung

� Verwendung des R/3-Parameters CRM_MAX_QUEUE_NUMBER_DELTA (was im Endeffekt auch Einfluss auf die Queue-Namensge-bung hat)

Reduktion derEinzelsätze

Der erste Ansatz besteht darin, die Einzelsätze, die das R/3 erzeugt,zu reduzieren. Die Firma BGS aus unserem Beispiel hat diese Mög-lichkeit. Die Reports im R/3 könnten dahingehend geändert werden,

Beispiel

Die Firma BodeGolzeSchröder AG (im Weiteren mit »BGS« abgekürzt) hat2,7 Millionen Kunden weltweit und davon 500000 in Deutschland, dievon 500 Außendienstmitarbeitern betreut werden. Einmal im Jahr führtBGS eine Gebietsreform im R/3 durch. Im Zuge dieser Gebietsreform wer-den die Verkaufsgebiete der Außendienstmitarbeiter neu zugeschnitten.40% der Kunden (200000) sind von dieser Reform nicht betroffen, da sietraditionell seit Jahren von ein und demselben Außendienstmitarbeiterbetreut werden und diese gewachsene Kundenbeziehung erhalten blei-ben soll. Die übrigen 60% werden den neuen Verkaufsgebieten zugeord-net.1 BGS hat dazu zwei Reports entwickelt. Report Z_DELETE_ASSIGN-MENT löscht die Zuordnung von einem Kunden zum zuständigen Mitar-beiter, und Report Z_CALCULATE_NEW_ASSIGNMENT berechnetanhand einer Reihe von Kriterien, welcher Mitarbeiter in Zukunft für denKunden zuständig sein wird. Die Reports Z_DELETE_ASSIGNMENT undZ_CALCULATE_NEW_ASSIGNMENT ändern jeweils 300000 Datensätze.Aufgrund der Deltaversorgung entstehen im CRM 300000 Eingangs-Queues mit jeweils zwei Einträgen. Die CRM Middleware muss nebendem Tagesgeschäft die 600000 Datensätze vom Typ BUPA_REL zusätzlichverarbeiten. Im CRM-System von BGS benötigen der R/3-Adapter und dieValidierung normalerweise zwei Sekunden, um ein BUPA_REL-BDoc zuverarbeiten. Aufgrund der extrem hohen Anzahl von Eingangs-Queuesbenötigt jedoch der Eingangs-Queue-Scheduler 2,2 Sekunden, um einenQueue-Eintrag einem Workprozess zuzuordnen. Damit ergibt sich einegeschätzte Eingangsverarbeitungsdauer von 600000 × 2,2 = 1,32 Millio-nen Sekunden (= 15 Tage, 6 Stunden).2

1 In den meisten Fällen ist das Ergebnis das gleiche wie vorher, d.h., der Außen-dienstmitarbeiter behält die meisten seiner Kunden.

2 Der Einfluss des Tagesgeschäfts und die Dauer der Ausgangsverarbeitung wurdenbei dieser Schätzung nicht berücksichtigt.


207


dass das COMMIT WORK nicht nach jedem einzelnen Datensatz,sondern erst nach n Datensätzen ausgeführt wird und n Objekte inein BUPA_REL-BDoc geschrieben werden. Wird für n z.B. die Zahl500 gewählt, würde der Report Z_DELETE_ASSIGNMENT nicht300000, sondern nur 600 Eingangs-Queues erzeugen. Leider bietetsich diese Möglichkeit nicht immer. Außerdem ist bei dieser Lösungzu beachten, dass aus einem R3A-Queue-Eintrag viele (500) CSA-Queue-Einträge entstehen. Da CSA-Queues im Sinne der CRM Midd-leware auch Eingangs-Queues sind, »belasten« auch sie den Ein-gangs-Queue-Scheduler.

Änderung der Queue-Namens-gebung

Der zweite Ansatz besteht darin, die Anzahl der Eingangs-Queuesüber die Änderung der Queue-Namensgebung zu limitieren. Die R/3-Queues für die Deltaversorgung im CRM haben per Default folgen-den Namen: R3AD_<Objektteil><Objekt-ID>. Für jeden Objekttypgibt es einen Eintrag in der Tabelle CRMQNAMES. Der Teil »Objekt-teil« des Queue-Namens steht im Feld QOBJPART, und aus welchemFeld die »Objekt-ID« gefüllt wird, steht im Feld BAPIFLD. In Abbil-dung 8.3 sehen Sie den Eintrag für das Objekt BUPA_REL. Die R/3-Ausgangs-Queue (und die CRM-Eingangs-Queue) hätten für dasObjekt 12345 den Queue-Namen R3AD_BUPA12345. Eine detail-lierte Beschreibung der Namenskonventionen für die verschiedenenEingangs-Queues für Delta-, Initialload usw. (R3AD*, R3AI* usw.)finden Sie in Kapitel 2, Eingangsverarbeitung und Validierung.

Abbildung 8.3 R3AD-Queue-Namensgebung (Tabelle CRMQNAMES im R/3); Transaktion SE16


208

Eingangs-Queues8

Durch die Änderung der Queue-Namensgebung werden mehrereGeschäftspartner in die gleiche Queue geschrieben und nicht mehrjeder in seine eigene. Indem Sie festlegen, welche und wie viele Stel-len aus der Objekt-ID für den Queue-Namen von Bedeutung sind,steuern Sie, wie viele Queues maximal entstehen können und wel-che Objektinstanzen in welche Queue geschrieben werden. DieAnzahl der für die Queue-Namensgebung relevanten Stellen steuernSie über das Feld LENGTH und die Auswahl der Stellen über das FeldFLDOFFSET.

Hat das Feld LENGTH beispielsweise den Wert 1 und FLDOFFSETden Wert 9, bedeutet dies, dass alle Objektinstanzen, die an derzehnten Stelle die gleiche Ziffer haben, in die gleiche Queue geschrie-ben werden. Es können also maximal zehn Queues entstehen.

Der Queue-Name wird durch die erste Objekt-ID festgelegt, für dieeine Queue erzeugt wird, und ändert sich nicht mehr, bis die Queueganz abgearbeitet ist (und verschwindet). In dem folgenden Beispielfinden Sie in der linken Spalte der Tabelle die R/3-Objekt-ID desGeschäftspartners. In allen vier Beispielen werden die gleichenGeschäftspartner verwendet, aber die Werte für die Felder LENGTHund FLDOFFSET ändern sich. In der rechten Spalte der Tabelle stehtder Name der Eingangs-Queue, in die der Geschäftspartner geschrie-ben wird. Wie Sie anhand des Beispiels sehen können, hängt dieAnzahl der Queues von den Feldwerten und den IDs der Geschäfts-partner ab.

Beispiel

1. Einstellung: Standardnamensgebung

Ergebnis: Die sechs Kunden werden in sechs Queues geschrieben.

R/3-Kundennummer CRM-Queue-Name

0000054601 R3AD_CUSTOME0000054601

0000034541 R3AD_CUSTOME0000034541

0000099421 R3AD_CUSTOME0000099421

0000028421 R3AD_CUSTOME0000028421

0000028422 R3AD_CUSTOME0000028422

0000067822 R3AD_CUSTOME0000067822


209


2. Einstellung: FLDOFFSET = 9 und LENGTH = 1

Ergebnis: Die sechs Kunden werden in zwei Queues geschrieben.


0000054601 R3AD_CUSTOME0000054601

0000034541

0000099421

0000028421

0000028422 R3AD_CUSTOME0000028422

0000067822


Ergebnis: Die sechs Kunden werden in vier Queues geschrieben.


0000054601 R3AD_CUSTOME0000054601

0000034541 R3AD_CUSTOME0000034541

0000099421 R3AD_CUSTOME0000099421

0000028421

0000028422 R3AD_CUSTOME0000028422

0000067822


Ergebnis: Die sechs Kunden werden in fünf Queues geschrieben.


0000054601 R3AD_CUSTOME0000054601

0000034541 R3AD_CUSTOME0000034541

0000099421 R3AD_CUSTOME0000099421

0000028421 R3AD_CUSTOME0000028421

0000028422

0000067822 R3AD_CUSTOME0000067822


210

Eingangs-Queues8

Queue-Namens-gebung ändern

Um die Queue-Namensgebung zu ändern, gehen Sie folgenderma-ßen vor (siehe Abbildung 8.3):

1. Suchen Sie in der Tabelle CRMQNAMES im R/3 den Eintrag mitdem Objektnamen OBJNAME, für den Sie die Queue-Namensge-bung ändern wollen (Transaktion SE16 oder alternativ Transak-tion SM30).

2. Tragen Sie die entsprechenden Werte für die Parameter Feldoffset(FLDOFFSET) und Feldlänge (LENGTH) ein.

3. Achten Sie darauf, dass die Summe der beiden Werte die maxi-male Länge der Objekt-ID nicht überschreitet. Die maximaleLänge der Objekt-ID finden Sie im Feld BAPIFLDLEN.

CSA-Queues Um die Namensgebung für die CSA-Queues zu ändern, gehen Sie fol-gendermaßen vor (siehe Abbildung 8.4):

1. Suchen Sie im CRM in der Tabelle SMOFQFIND den Eintrag mitdem Objektnamen in der Spalte BDoc-Typ, für den Sie die Queue-Namensgebung ändern wollen (Transaktion SM30 oder alternativTransaktion SE16).

2. Tragen Sie die Werte für die Parameter Feld Offset (entspricht:FLDOFFSET) und Interne Länge (entspricht: LENGTH) ein.

3. Für alle Objekte, die in die gleiche Queue geschrieben werden,müssen die Einträge geändert werden, d.h. alle Einträge, für diedie Werte in den Feldern Queue Objektteil und Segmentfeldgleich sind.

Beachten Sie, dass die Queue-Namensfindung nur geändert werdendarf, wenn die Queues leer sind.


211


Abbildung 8.4 CSA-Queue-Namensgebung (Tabelle SMOFQFIND im CRM); Transaktion SM30

Verwendung des Parameters CRM_MAX_QUEUE_NUMBER_DELTA

Der dritte Ansatz zur Reduzierung der Anzahl der Eingangs-Queuesbesteht in der Verwendung des Parameters CRM_MAX_QUEUE_NUMBER_DELTA. Der Parameter wird in der Tabelle CRMPAROLTPgepflegt und legt fest, wie viele Queues gebildet werden, unabhängigvon den Einstellungen in der Tabelle CRMQNAMES. Ist der Parame-ter gesetzt, werden die ASCII-Werte der letzten drei Stellen desQueue-Namens zusammengefasst und Modulo CRM_MAX_QUEUE_NUMBER_DELTA gerechnet. Das Ergebnis ist eine Zahl, die kleinerals 1000 und kleiner CRM_MAX_QUEUE_NUMBER_DELTA ist.Basierend auf dieser Zahl wird der neue Queue-Name gebildet.

Die Anzahl der Queues kann pro Objekttyp unterschiedlich gepflegtwerden.3

3 Ab PI_BASIS 2006.1 oder falls SAP Hinweis 944633 eingespielt wurde.


212

Eingangs-Queues8

R3AD-Queueslimitieren

Um die Anzahl der R3AD-Queues zu limitieren, gehen Sie folgender-maßen vor (siehe Abbildung 8.5):

1. Legen Sie im R/3 für Tabelle CRMPAROLTP einen neuen Datensatzan (Transaktion SM30).

2. Tragen Sie in das Feld Parameter Name (PARNAME) den Wert»CRM_MAX_QUEUE_NUMBER_DELTA« ein.

3. Tragen Sie den Namen des Objekttyps in das Feld Param. Name 2(PARNAME2) ein.

4. Tragen Sie die Bezeichnung für Ihr CRM-System in das FeldAnwender (CONSUMER) ein.

5. Die Anzahl der Queues wird in das Feld Param. Wert (PARVAL1)eingetragen.

Abbildung 8.5 Tabelle CRMPAROLTP im R/3

Vor- und Nachteile Bei der Änderung der Queue-Namensgebung lässt sich mit Hilfe desFeldes LENGTH festlegen, wie viele Queues maximal entstehen kön-nen, aber nicht, wie viele tatsächlich entstehen. Die maximaleAnzahl der Queues wird nicht nur durch den Wert des FeldesLENGTH, sondern auch durch den Typ der Objekt-ID beeinflusst.Tabelle 8.1 zeigt diese Abhängigkeit. Sie zeigt aber auch, dass sich diemaximale Anzahl der Queues nur in sehr groben Schritten einschrän-ken lässt. So ist es beispielsweise nicht möglich, die maximale Anzahlder Queues auf 25 zu beschränken.


213


Die tatsächliche Anzahl der Queues lässt sich in gewissem Umfangdurch den Wert des Feldes FLDOFFSET beeinflussen. Je nach Wahlund Stand der Nummernkreise haben bestimmte Stellen in derObjekt-ID für alle Instanzen den gleichen Wert, während bei ande-ren alle Werte vorkommen.

Im Gegensatz zur Änderung der Queue-Namen lässt sich bei der Ver-wendung des Parameters CRM_MAX_QUEUE_NUMBER_DELTA diemaximale Anzahl der Queues exakt limitieren. Auch der Typ derObjekt-ID spielt keine Rolle. Schwierigkeiten treten nur auf, wenndie letzten drei Stellen der ID nicht gleich verteilt sind. Bei der Ver-wendung der Standardnamensgebung tritt dieses Problem nicht auf(es sei denn, es gibt weniger als 1000 Objekte). Wenn Sie aber beider Namensvergabe eigene Regeln implementiert haben, kann essein, dass Sie den Parameter nicht verwenden können, wie das Bei-spiel von BGS zeigt.

Generell lässt sich sagen, dass sich der Parameter CRM_MAX_QUEUE_NUMBER_DELTA zur Limitierung der Queues besser eignetals die Änderung der Queue-Namensgebung. Für eine optimale Ver-

Typ der Objekt-ID Wert von LENGTH Max. Anzahl Queues

Numerisch 1 10

2 100

3 1000

Alphanumerisch 1 36

2 1296

3 46656

Tabelle 8.1 Maximale Anzahl von Eingangs-Queues in Abhängigkeit vom Typ der Objekt-ID und des Parameters LENGTH

Beispiel

Um anhand der Kundennummer direkt erkennen zu können, aus welchemLand ein Kunde kommt, enden alle Kundennummern bei BGS mit einemzweistelligen Länderkürzel (externe Nummernvergabe). Bei der Verwen-dung des Parameters CRM_MAX_QUEUE_NUMBER_DELTA entstehenbei der Gebietsreform in Deutschland daher maximal 10 Queues.


214

Eingangs-Queues8

arbeitung ist eine möglichst gleichmäßige Verteilung der Datensätzeüber alle Queues erstrebenswert.

Änderung der Queue-Namensgebung oder Änderungen am Parame-ter CRM_MAX_QUEUE_NUMBER_DELTA dürfen nur durchgeführtwerden, wenn alle Eingangs-Queues abgearbeitet sind. Ansonstenkann es zu Dateninkonsistenzen zwischen dem R/3 und dem CRMkommen, wie das folgende Beispiel zeigt.

R/3-Ausgangs-Queues reduzieren

Es empfiehlt sich, die Ausgangs-Queues im R/3 zunächst zu deregist-rieren und anschließend abzuwarten, bis die R3AD-Eingangs-Queuesim CRM vollständig abgearbeitet wurden. Dann führen Sie die Ände-rung der CSA-Queue-Namensgebung durch und registrieren dieQueues anschließend wieder. Die Änderung der Namensgebung derR3A-Queues ist schwieriger durchzuführen, da Sie im R/3 nicht ver-hindern können, dass Ausgangs-Queues angelegt werden. Die Ände-rung lässt sich daher nur im Rahmen eines Wartungsfensters durch-führen, wenn keine Daten im R/3 angelegt werden, die ans CRMübertragen werden.

8.2 Die Anzahl der Eingangs-Queues ist zu niedrig

In Abschnitt 8.1 wurde beschrieben, wie Sie die Anzahl der Ein-gangs-Queues limitieren können. Es wurde auch darauf hingewie-sen, dass die tatsächliche Anzahl der Eingangs-Queues sehr viel klei-ner sein kann und sich die Datensätze nicht zwangsläufig über alleQueues gleichmäßig verteilen. Das folgende Beispiel verdeutlicht dieProbleme, die auftreten können, wenn die Anzahl der Queues zustark limitiert wird.

Beispiel

Vor der Änderung werden alle Datensätze, die sich auf Kunde A beziehen,in die Queue A geschrieben, nach der Änderung in Queue X. Wird dieÄnderung durchgeführt, obwohl noch Daten in der Queue A stehen, exis-tieren für eine gewisse Zeitspanne zwei Queues im System, die Daten vonKunde A enthalten. In Queue A stehen die älteren Datensätze und inQueue X die aktuelleren. Wird Queue X vor Queue A abgearbeitet, über-holen die aktuelleren Datensätze die älteren. Die Folge ist, dass zunächstdie aktuelleren Datensätze im CRM verbucht werden und anschließend dieWerte in den älteren Datensätzen die aktuelleren Werte überschreiben.


215

Hardware-Engpässe 8.3

Das im Beispiel beschriebene Problem lässt sich unter Umständendurch eine genaue Analyse der Kundennummern und eine entspre-chende Wahl des FLDOFFSET-Parameters beheben. Diese Analyse istaber sehr aufwändig, und es ist auch nicht sichergestellt, dass eseinen idealen Wert für FLDOFFSET gibt. Alternativ kann die maxi-male Anzahl der Eingangs-Queues weiter erhöht werden. Entschei-dend ist, den richtigen Mittelweg zwischen einer zu niedrigen undeiner zu hohen Anzahl von Eingangs-Queues zu wählen.

8.3 Hardware-Engpässe

Neben der Anzahl der Eingangs-Queues gibt es weitere Parameter,die beachtet werden müssen, um eine optimale Abarbeitung der Ein-gangs-Queues zu gewährleisten, wie das folgende Beispiel zeigt.

Beispiel

Die Firma BGS hat sich gegen eine Änderung der Reports, aber für dieÄnderung der Queue-Namensgebung entschieden. Um nicht zu viel Lastauf dem CRM-System zu erzeugen, wurde für den Parameter LENGTH derWert 1 und für FLDOFFSET der Wert 7 gewählt. Das CRM-System vonBGS besteht aus einem Applikations- und einem Datenbankserver mitjeweils vier CPUs. Auf beiden Servern gibt es je 20 Dialog-Workprozesse.Das CRM-System sollte problemlos in der Lage sein, zehn Eingangs-Queues parallel abzuarbeiten. BGS erwartet, dass zehn Queues mit jeweils72000 Datensätzen entstehen und dass die Abarbeitung 72000 * 2 Sek. =144000 Sek. (= 40 Stunden) dauert. Nach dem Start der Massenänderungstellt sich heraus, dass die längste der zehn Queues 151200 Datensätzeenthält. (21% der geänderten Kunden haben eine 3 als letzte Ziffer vordem Länderkürzel in ihrer Kundennummer; 14% eine 8, 10% eine 7 und5, 9% eine 6 und 9, 8% eine 2 und 4, 7% eine 0 und 4% eine 1). DieAbarbeitung dieser Queue dauert 151200 × 2 Sek. = 302400 Sek. (= 3,5Tage).

Beispiel

Beim nächsten Test wählt BGS für den Parameter LENGTH den Wert 2und für FLDOFFSET den Wert 6. Nach dem Start der Massenänderungentstehen im CRM nicht die erwarteten 100, sondern 84 Eingangs-Queues mit durchschnittlich 8500 Einträgen. Der Eingangs-Queue-Sche-duler nutzt die verfügbaren Ressourcen, um die Queues möglichst schnellabzuarbeiten, und belegt alle Dialog-Workprozesse. Es kommt zu einerÜberlastsituation (CPU-Engpass). Das CRM-System ist nur noch mit der


216

Eingangs-Queues8

Die Probleme, die die Firma BGS im letzten Beispiel hatte, wurdennicht durch eine zu hohe Anzahl von Eingangs-Queues verursacht,sondern durch die Tatsache, dass der Eingangs-Queue-Scheduler zuviele Dialog-Workprozesse des CRM-Systems belegt hat. Der Ein-gangs-Queue-Scheduler besitzt keine Logik, die prüft, wie stark dasSystem bereits ausgelastet ist, und daraufhin entscheidet, ob weiterQueue-Einträge abgearbeitet werden können oder eine Pause einge-legt werden muss. Alle Workprozesse, die ihm zur Verfügung ste-hen, werden so lange zur Abarbeitung genutzt, bis alle Eingangs-Queues leer sind.

RFC-Server-Gruppe

Überlastsituationen dieser Art können Sie nur verhindern, indem Siedie Anzahl der Dialog-Workprozesse, die der Eingangs-Queue-Sche-duler belegen darf, limitieren. Zu diesem Zweck ist der Eingangs-Queue-Scheduler einer RFC-Server-Gruppe zugeordnet. RFC-Server-Gruppen werden mit Hilfe der Transaktion RZ12 angelegt undgepflegt. In Abbildung 8.6 sehen Sie ein CRM-System mit drei RFC-Server-Gruppen. Die erste Gruppe (ohne Namen) ist die Standard-gruppe. Sie wird immer verwendet, wenn keine explizite Zuordnungzu einer Gruppe existiert. Die anderen beiden Gruppen – Queue_Scheduler und parallel_generators – wurden manuell angelegt, undbeiden Gruppen wurde jeweils eine Instanz zugeordnet. Grundsätz-lich können einer Gruppe auch mehrere Instanzen zugeordnet wer-den. In diesen Fällen wird bei der Anmeldung eines Benutzers auto-matisch die Instanz mit den günstigsten Antwortzeiten ermittelt, undder Benutzer wird auf dieser Instanz angemeldet.

Um eine RFC-Server-Gruppe anzulegen, starten Sie die TransaktionRZ12 und klicken auf die Schaltfläche Neu (Menüpfad: Bearbeiten �Zuordnung anlegen). Um sich die Ressourcenzuordnung einerInstanz anzeigen zu lassen oder sie zu ändern, führen Sie einen Dop-pelklick auf der entsprechenden Zeile aus. Es erscheint ein Pop-up-Fenster Zuordnung ändern mit den RFC-Parameterwerten derInstanz.

Abarbeitung der Eingangs-Queues beschäftigt, und ein weiteres Arbeitenmit dem CRM-System ist nicht mehr möglich (dies gilt insbesondere auchfür den Systemadministrator). Außerdem vervielfacht sich die Verarbei-tungsdauer der einzelnen Datensätze aufgrund des CPU-Engpasses.


217


Abbildung 8.6 RFC-Server-Gruppen (Transaktion RZ12)

Parameter der RFC-Server-Gruppe

Die Parameter haben folgende Bedeutung:

� Aktiviert (0 or 1)Schalter zur Aktivierung der Ressourcenbestimmung. Sollteimmer den Standardwert 1 (= aktiv) haben.

� Max. Requests in Queue (%)Quote für die Anzahl der maximal anstehenden Requests in derDialogwarteschlange des Dispatchers im Verhältnis zur maxima-len Länge der Dispachter Request Queue. Der Standardwert ist 5.

� Max. Anzahl Logins (%)Dieser Wert gibt an, wie viel Prozent der Anmeldungen an dieserInstanz maximal durch asynchrone RFCs zustande kommen dür-fen (Gesamtzahl der Anmeldungen steht im Parameter rdisp/tm_max_no). Der verbleibende Prozentsatz bleibt für Dialog- und


218

Eingangs-Queues8

HTTP-Benutzer reserviert, d.h., übersteigt die Anzahl der Loginsdiesen Wert, bekommt der Aufrufer keine Ressourcen zugewie-sen. Standardwert ist 90.

� Max. Anz. eigene Logins (%)Dieser Wert gibt an, wie viel Prozent der Anmeldungen an dieserInstanz maximal durch asynchrone RFCs eines Benutzers4 zustandekommen dürfen (Gesamtzahl der Anmeldungen steht im Parame-ter rdisp/tm_max_no). Übersteigt die Anzahl der eigenen Loginsdiesen Wert, bekommt der Benutzer keine weiteren Ressourcenzugewiesen. Dieser Wert sollte sinnvollerweise nicht größer seinals der Parameter Max. Anzahl Logins (%). Standardwert ist 25.

� Max. Anz. benutzte WPs (%)Quote für die Anzahl von Dialog-Workprozessen, die ein Benutzerbelegen darf. Übersteigt die Anzahl der belegten Dialog-Workpro-zesse diesen Wert, bekommt der Aufrufer keinen Dialog-Work-prozess mehr zugewiesen. Diese Quote verhindert, dass alle Dia-log-Workprozesse durch RFCs eines Benutzers belegt werden.Standardwert ist 75.

Es wird nicht auf den Benutzernamen geprüft, d.h., wenn sich einBenutzer mehrfach am System anmeldet, wird jede Anmeldungals eigener Benutzer gewertet, obwohl der Benutzername gleichist.

� Min. Anz. freie WPsQuote für die Anzahl von Dialog-Workprozessen, die für andereBenutzer freigehalten werden sollen. Sind weniger Dialog-Work-prozesse frei als durch die Quote vorgegeben, bekommt der Auf-rufer keinen Dialog-Workprozess zugewiesen. Standardwert ist 1.

Der Wert muss immer kleiner als die Anzahl der Dialog-Workpro-zesse (Parameter rdisp/wp_no_dia) sein, da sonst kein RFCRequest bearbeitet werden kann.

� Max. Anz. Komm.eintraege (%)Quote für die Anzahl der Kommunikationseinträge einer Instanz,die maximal durch parallele RFCs belegt werden dürfen (Gesamt-zahl der Kommunikationseinträge steht im Parameter rdisp/max_comm_entries). Übersteigt die Anzahl der benutzten Einträge die-

4 Eine Anwendung, die parallele RFCs benutzt.


219


sen Wert, bekommt der Aufrufer keine Ressource zugewiesen.Standardwert ist 90.

� Max. warten zeitMaximale Anzahl in Sekunden, die sich ein Workprozess »schla-fen legt«, wenn er nach einer Lastüberprüfung keine Ressourcenbekommt. Die tatsächliche Wartezeit ergibt sich aus den zur Ver-fügung stehenden Ressourcen. Je weniger Ressourcen zur Verfü-gung stehen, desto länger ist die Wartezeit.

Profilparameter der RFC-Server-Gruppe

Alle Einstellungen, die in der Transaktion RZ12 vorgenommen wer-den, sind sofort aktiv, werden aber nur bis zum nächsten Durchstar-ten der Instanz gespeichert. Danach sind sie verloren, und die altenWerte sind wieder aktiv. Um die Werte dauerhaft zu speichern, müs-sen sie als Profilparameter gespeichert werden. In Tabelle 8.2 findenSie die Namen der Profilparameter zu den einzelnen Werten inTransaktion RZ12.

RFC-Server-Gruppe zuordnen

Die Zuordnung des Eingangs-Queue-Schedulers zu einer RFC-Server-Gruppe erfolgt in der Transaktion SMQR. Wählen Sie den Menü-punkt Bearbeiten � AS-Gruppe ändern, und tragen Sie den Namender RFC-Server-Gruppe ein.

In Abbildung 8.7 sehen Sie, dass der Parameter Name der AS-Gruppe(DEFAULT = alle) nicht mehr den Wert »DEFAULT«, sondern denWert »Queue_Scheduler« hat.

RZ12 Profilparameter

Aktiviert (0 or 1) rdisp/rfc_use_quotas

Max. Requests in Queue (%) rdisp/rfc_max_queue

Max. Anzahl Logins (%) rdisp/rfc_max_login

Max. Anz. eigene Logins (%) rdisp/rfc_max_own_login

Max. Anz. benutzte WPs (%) rdisp/rfc_max_own_used_wp

Min. Anz. freie WPs rdisp/rfc_min_wait_dia_wp

Max. Anz. Komm.eintraege (%) rdisp/rfc_max_comm_entries

Max. warten zeit rdisp/rfc_max_wait_time

Tabelle 8.2 Namen der Profilparameter


220

Eingangs-Queues8

Abbildung 8.7 Zuordnung der RFC-Server-Gruppe (Transaktion SMQR)

OptimaleEinstellung der

RFC-Server-Gruppe

Die optimale Einrichtung von RFC-Server-Gruppen hängt von derverfügbaren Hardware, dem Datenvolumen und den verwendetenSzenarien ab. Wird ein reines Mobile-Sales-Szenario verwendet,muss bei der Optimierung des Systems auf keine Online- oder Inter-net-Sales-Benutzer Rücksicht genommen werden. In diesem Fallkönnen dem RFC fast alle Workprozesse zur Verfügung gestellt wer-den. In allen anderen Fällen müssen die Ressourcen für den RFC solimitiert werden, dass die Benutzer auch bei hoher RFC-Last weitermit dem System arbeiten können. Hat das CRM-System mehr alseinen Applikationsserver, kann es sinnvoll sein, die RFC-Server-Gruppen so einzurichten, dass die RFC-Verarbeitung auf die Ressour-cen eines Applikationsservers beschränkt ist, während die Online-Benutzer einen anderen Applikationsserver verwenden. Auf dieseWeise stören sich Benutzer und RFC nicht gegenseitig. Dies gilt ins-besondere dann, wenn ein Datentransfer aus dem Backend bzw. vonoder zu den Mobile Clients und eine intensive Nutzung der CRM-Applikation parallel stattfinden. Der Nachteil an diesem Setup ist,dass bei hoher RFC-Last (z.B. bei einer Massenänderung), der RFCauf einen Server beschränkt ist, auch wenn auf dem anderen ServerRessourcen verfügbar sind (beispielsweise in der Nacht).

Gibt es nur einen Applikationsserver, ist es besonders wichtig, dieParameter der RFC-Server-Gruppe optimal einzustellen. In jedemFall sollte die Verteilung der Ressourcen die tatsächliche Lastvertei-lung – RFC-Last vs. Online-Last – widerspiegeln.


221


Um zu verhindern, dass der Eingangs-Queue-Scheduler alle Work-prozesse des CRM-Systems belegt, müssen die Parameter Max. Anz.benutzte WPs (%) und Min. Anz. freie WPs richtig eingestellt wer-den. Min. Anz. freie WPs legt fest, wie viele Workprozesse dem RFCzur Verfügung stehen, und Max. Anz. benutzte WPs (%) legt fest, wieviele Workprozesse von einem RFC-Benutzer belegt werden dürfen.

Sind genügend Dialog-Workprozesse im System vorhanden, sollteder Parameter Min. Anz. freie WPs statt des Standardwerts 1 denWert 3 haben. Auf diese Weise ist sichergestellt, dass Sie sich auchbei sehr hoher Last über SAP GUI auf dieser Instanz noch einloggenkönnen. Diese Empfehlung gilt nur für ein reines Mobile-Sales-Sze-nario bzw. eine reine RFC-Instanz. In allen anderen Fällen sollte derWert größer sein und sich an der Anzahl der gleichzeitig aktiven(»concurrent«) Online-Benutzer orientieren.

Bei der Wahl des Parameters Max. Anz. benutzte WPs (%) ist zubeachten, dass nicht nur der Eingangs-Queue-Scheduler, sondernauch andere Benutzer den RFC verwenden (Replication & Realign-ment, Ausgangs-Queue-Scheduler, externe Systeme – insbesonderedie Mobile Clients über die DCOM Station/.NET Connector). Wirdder Wert zu hoch gewählt, werden die Eingangs-Queues zwarschnell abgearbeitet, aber die Daten stauen sich in anderen Berei-chen der Middleware, da dort Ressourcen fehlen. Eine optimale Ver-arbeitungsgeschwindigkeit wird nur erreicht, wenn alle Komponen-ten des Systems über ausreichend Ressourcen verfügen können. Aufdiese Abhängigkeiten in der Middleware gehen wir ausführlich inKapitel 13, Massenänderungen optimiert durchführen, ein.

Eine detaillierte Dokumentation zur Konfiguration der Systemres-sourcen für parallelen RFC, tRFC und qRFC finden Sie im SAP Help-Portal (http://help.sap.com) unter SAP NetWeaver. Wählen Sie Releaseund Sprache. Für Web AS 6.40 (SAP NetWeaver '04) finden Sie dieDokumentation unter SAP NetWeaver � SAP NetWeaver Konfigura-tion � SAP Web Application Server � SAP Web Application ServerABAP � Konfiguration von Systemressourcen für parallelen RFC,tRFC, qRFC.


222

Eingangs-Queues8

8.4 Performance-Analyse der Einzelsatz-verarbeitung

Für eine Performance-Analyse liefert SAP eine ganze Reihe von sta-tistischen Informationen und Trace-Möglichkeiten. Einige davonsind in Tabelle 8.3 aufgeführt.

Analysetrans-aktionen

Abgesehen von der Nachrichtenfluss-Statistik (Transaktion SMWM-FLOW) und dem Middleware-Trace (Transaktion SMWT) – auf die wirnoch näher eingehen werden – handelt es sich bei den Analysetrans-aktionen um »Standard«, d.h. nicht CRM-spezifische Transaktionen,die in jedem SAP-System zu finden sind. Zu diesen Transaktionenund dazu, wie Sie sie am besten nutzen, gibt es bereits ausführlicheBeschreibungen, die wir an dieser Stelle nicht wiederholen wollen.5

Wir wollen aber auf einen Aspekt hinweisen, bei dem sich die Per-formance-Analyse der CRM Middleware von der Performance-Ana-lyse in anderen SAP-Systemen unterscheidet. Bei einer Performance-Analyse wird häufig der Benutzer, der eine Transaktion ausführt, alsFilter benutzt, um die richtigen statistischen Datensätze zu finden

Transaktion Beschreibung

ST03N Systemlastmonitor

STAD Statistical Records

ST12 Single Transaction Trace

SE30 Laufzeitanalyse (ABAP Trace)

ST04 Database Performance Analysis

DB02 Database Performance: Tables and Indices

ST10 Table Call Statistics

ST05 Performance-Analyse (SQL Trace)

SQLR SQL Trace Interpeter

SMWMFLOW Nachrichtenfluss-Statistik

SMWT Middleware-Trace

Tabelle 8.3 Performance-Analysetransaktionen

5 Empfehlenswert ist hier z.B. das Buch SAP-Performanceoptimierung. Analyse undTuning von SAP-Systemen von Thomas Schneider, erschienen bei SAP PRESS (4.Auflage 2005).


223

Performance-Analyse der Einzelsatzverarbeitung 8.4

oder eine bestimmte Aktion im System zu tracen. In der CRM Midd-leware ist der »Benutzer« nicht immer so einfach zu ermitteln. Unterwelchem Benutzer zum Beispiel eine Eingangs-Queue abgearbeitetwird, steht nur dann eindeutig fest, wenn eine logische Destinationgepflegt wurde. Ansonsten wird die Queue-Prozessierung unter derBenutzer-ID durchgeführt, die gerade eine registrierte Queue (diesmuss nicht dieselbe Queue sein) bearbeitet.

Ein Queue-Eintrag wird also nicht zwangsläufig mit der Benutzer-IDweiterverarbeitet, die ihn in die Queue geschrieben hat, sondernkann mit einer anderen Benutzer-ID verarbeitet werden. Wenn diesebeiden Benutzer unterschiedliche Rechte haben, kann es passieren,dass ein Benutzer mit nicht ausreichenden Rechten versucht, Queue-Einträge eines anderen Benutzers zu verarbeiten. Die auftretendenFehler sind sehr schwierig zu analysieren, da sie in der Regel seltenauftreten und kaum reproduzierbar sind.

8.4.1 Logische Destinationen

Wir empfehlen daher dringend, logische Destinationen für alle Ein-gangs-Queues anzulegen. Der Aufwand ist gering, aber der Nutzengroß. Um eine logische Destination anzulegen, müssen Sie folgendeSchritte durchführen:

1. Für jede Queue sollten Sie einen Benutzer anlegen, unter dessenID die Queue abgearbeitet werden soll, z.B. R3A_Inbound für dieR3A*-Queues. Starten Sie dazu die Transaktion SU01, klicken Sieauf die Schaltfläche Neu und legen Sie einen Benutzer vom Typ»Kommunikation« an.

2. Prüfen Sie in Transaktion SM59, ob eine interne Verbindung vomTyp »None« existiert, und merken Sie sich den Namen dieser Ver-bindung.

3. Legen Sie eine neue interne Verbindung in Transaktion SM59 an.Wählen Sie dazu als Verbindungstyp »L«, und tragen Sie im ReiterTechnische Einstellungen in das Feld Referenzeintrag den Namender internen Verbindung »None« aus Schritt 2 ein (siehe Abbil-dung 8.8). Gehen Sie auf den Reiter Anmeldung & Sicherheit, undtragen Sie hier die Logon-Informationen des Benutzers aus Schritt1 ein (siehe Abbildung 8.9).


224

Eingangs-Queues8

4. In Transaktion SMQR können Sie jetzt die interne Verbindung derentsprechenden Queue zuordnen (siehe Abbildung 8.10).

� Markieren Sie dazu die entsprechende Queue.

� Klicken Sie auf die Schaltfläche Registrierung.

� Im Pop-up-Fenster Queue-Registrierung tragen Sie in das FeldUSERDEST die ID der internen Verbindung aus Schritt 3 ein.

� Bestätigen Sie die Eingabe.

In Abbildung 8.11 sehen Sie, dass die logische Destination R3A_INBOUND nun allen Queues, die mit dem Präfix »R3A« beginnen,zugeordnet ist.

Wiederholen Sie diese Schritte, bis Sie allen Eingangs-Queues inTransaktion SMQR eine logische Destination (und damit einen eige-nen Benutzer) zugeordnet haben. In der Prozessübersicht (Transak-tion SM50) können Sie nun direkt sehen, welche Workprozesse anwelchen Eingangs-Queues arbeiten. Auch in anderen Transaktionenerweist sich der Benutzer als hilfreich. So können Sie z.B. bei derBDoc-Fehleranalyse (Transaktion SMW01) die Benutzer-ID als Filterim Feld Benutzer (Autor) benutzen, wenn Sie die entsprechendenmBDocs selektieren wollen.

Abbildung 8.8 Neue interne Verbindung vom Typ »L« anlegen (Transaktion SM59)


225


Abbildung 8.9 Benutzer der neuen Verbindung zuordnen (Transaktion SM59)

Abbildung 8.10 Logische Destination eintragen (Transaktion SMQR)


226

Eingangs-Queues8

Abbildung 8.11 R3A-Queue mit logischer Destination (Transaktion SMQR)

8.4.2 Nachrichtenfluss-Statistiken

CRM-spezifische Statistiken, die bei der Performance-Analyse sehrhilfreich sein können, sind die Nachrichtenfluss-Statistiken. Zu denNachrichtenfluss-Statistiken gelangen Sie, indem Sie im Easy Access-Menü folgendem Pfad folgen:

Architektur und Technologie � Middleware � Monitoring � Nachrich-tenfluss � Nachrichtenfluss-Statistik anzeigen

Alternativ können Sie auch die Transaktion SMWMFLOW verwen-den. In Abbildung 8.12 sehen Sie das Startfenster der Transaktion. Siehaben die Möglichkeit, zwischen verschiedenen Statistiken zu wäh-len: den Kernel-Anwendungsstatistiken und den Site-/Queue-Statistiken.

Abbildung 8.12 Startfenster der Transaktion SMWMFLOW


227


An-/Abschalten von Statistiken

Das Schreiben der Statistiken kann an- und abgeschaltet werden.Daher sollten Sie vor einer Performance-Analyse unbedingt prüfen,ob die Statistiken auch geschrieben werden. Klicken Sie dazu imMenü auf Springen � Turn on statistics.

Im nächsten Fenster haben Sie nun die Möglichkeit, die Kernel-Anwendungsstatistiken und die Site-/Queue-Statistiken unabhängigvoneinander an- und abzuschalten (siehe Abbildung 8.13):

� Kernel-AnwendungsstatistikenWenn Sie auf die Schaltfläche Kernel-Anwendungsstatistik kli-cken, öffnet sich das Fenster, das Sie in Abbildung 8.14 sehen.Damit die Statistiken für die Middleware geschrieben werden,sollte in der Zeile Middleware Message Hub Statistic ein Haken inder Spalte active gesetzt sein. Damit die Kernel-Statistiken auchtatsächlich aktiviert werden, müssen Sie zuvor den Hintergrund-job SAP_COLLECTOR_FOR_PERFMONITOR eingeplant haben.

Abbildung 8.13 Statistiken aktivieren

Abbildung 8.14 Kernel-Anwendungsstatistik aktivieren


228

Eingangs-Queues8

� Site-/Queue-StatistikenWenn Sie auf die Schaltfläche Statistik Middleware-Message-Flowklicken, öffnet sich das Fenster, das Sie in Abbildung 8.15 sehen.Für eine Analyse sollte sowohl der Monitoring Message Flow alsauch der Collector eingeschaltet sein.

Abbildung 8.15 Site-/Queue-Statistiken einschalten

Workload-Statistik

Um sich die Workload-Statistiken anzeigen zu lassen, klicken Sie inder Transaktion SMWMFLOW auf eine der beiden SchaltflächenWorkload aus Datenbank oder Workload d. letzten Minuten (sieheAbbildung 8.12).

Letzte Minuten Wenn Sie auf die Schaltfläche Workload d. letzten Minuten klicken,wird Ihnen die aktuelle Last der letzten x Minuten der CRM-Instanzangezeigt, auf der Sie sich befinden. Sie haben die Möglichkeit,selbst festzulegen, wie groß »x« ist.

Historische Daten Wenn Sie auf die Schaltfläche Workload aus Datenbank klicken,werden Ihnen »historische« Daten angezeigt. Sie können sich Statis-tiken einer Instanz oder aller Instanzen anzeigen lassen und zwi-schen verschiedenen Zeitintervallen wählen.

In beiden Fällen ist der Aufbau des Ergebnisfensters identisch. Siebekommen Daten über die Anzahl der BDocs pro Typ, die in dem


229


Zeitraum verarbeitet wurden, über Verarbeitungszeit, CPU-Zeit,Wartezeit, Datenbankzeit und die Anzahl der angeforderten KBytes.Bei allen Zeitangaben erhalten Sie zusätzlich Informationen über diegesamte Zeit und die Durchschnittszeit (siehe Abbildung 8.16). Dafür die interne Berechnung die Werte in Millisekunden verwendetwerden, die Gesamtzeit aber in Sekunden angegeben wird, kann eszu Rundungseffekten kommen. Dies tritt besonders bei relativ klei-nen Werten bzw. wenigen Statistiksätzen auf.

Abbildung 8.16 Workload-Statistik (Transaktion SMWMFLOW)

Workload-Statis-tik »pro Dienst«

Weitere Detailinformationen über die Verarbeitungszeiten einesbestimmten BDoc-Typs erhalten Sie, wenn Sie eine Zeile markierenund auf die Schaltfläche Pro Dienst klicken. Es werden die Servicesaufgelistet, die bei der Verarbeitung eines BDoc-Typs gerufen wur-den, und für jeden Service werden Antwortzeit, CPU-Zeit, Wartezeitund Datenbankzeit angegeben (siehe Abbildung 8.17).

Abbildung 8.17 Workload-Statistik per Dienst (Transaktion SMWMFLOW)


230

Eingangs-Queues8

BDoc-Typhierarchie

Informationen über die BDoc-Typhierarchie erhalten Sie, wenn Sieeinen BDoc-Typ markieren und auf die Schaltfläche Verwendungs-nachweis rechts neben der Schaltfläche Pro Dienst klicken (sieheAbbildung 8.16). In Abbildung 8.18 sehen Sie ein Beispiel für denBDoc-Typ BUS_TRANS_MSG. Auch in dieser Darstellung bekommenSie Informationen über die verschiedenen Zeiten, die bei der Verar-beitung eines BDocs bzw. eines Service benötigt wurden. Zusätzlichbekommen Sie aber noch eine Reihe von Informationen zu denerzeugten BDocs.

In Zeile � sehen Sie, dass 52 mBDocs vom Typ BUS_TRANS_MSGmit dem Flow-Kontext M01 erzeugt wurden. Neben diesen 52 wur-den noch 17 BUS_TRANS_MSG-mBDocs mit dem Flow-Kontext MI0erzeugt (siehe Zeile �). Für diese 17 BDocs wurde nur der VALIDA-TION-Service gerufen. Anhand der Baumstruktur können Sie diejeweiligen Vorgänger- und Nachfolger-BDocs erkennen. Es wurden17 ACTIVITY_OBJECT-sBDocs mit dem Flow-Kontext SI1 verarbeitet(siehe Zeile �), und als Ergebnis wurden die 17 BUS_TRANS_MSG-mBDocs erzeugt. Business-technisch bedeutet dies, dass 17 Aktivitä-ten im Laufe des Tages von Mobile Clients an den CRM Server über-tragen und dort validiert wurden. Die Validierung hat pro mBDoc imSchnitt 3.435 ms gedauert �.

Die 52 BUS_TRANS_MSG-mBDocs mit dem Flow-Kontext MO1haben kein Vorgänger-BDoc. Das bedeutet, dass die Objekte im CRMOnline selber angelegt und nicht vom R/3 oder einem Mobile Clientgesendet wurden. Die durchschnittliche Antwortzeit von 7.255 ms(siehe Zeile �) für ein BUS_TRANS_MSG-mBDoc ist nur bedingt aus-sagekräftig, da ein BUS_TRANS_MSG-mBDoc unterschiedliche Busi-ness-Objekte enthalten kann, deren Verarbeitung unterschiedlichkomplex ist. Unterhalb von Zeile � sehen Sie die Services und Funk-tionen, die bei der Verarbeitung der BUS_TRANS_MSG-mBDocs auf-gerufen wurden. (Beachten Sie, dass die Reihenfolge in der Baum-struktur nicht der tatsächlichen Reihenfolge entspricht. Dietatsächliche Reihenfolge finden Sie in Transaktion SMO8FD.)

Zeile � enthält die Verarbeitungszeiten des Outbound Flow Service fürMobile Clients (Funktionsbaustein CRM_UPLOAD_MCA_SRV). ImMobile-Szenario wird das mBDoc auf ein oder mehrere sBDocsgemappt. Hier bekommen Sie die Information, welche sBDocs bei derVerarbeitung der 52 BUS_TRANS_MSG erzeugt wurden. Aus denNamen der sBDocs ist dann auch ersichtlich, welche Business-Objekte


231


sich in den 52 BUS_TRANS_MSG-mBDocs »verstecken«. Wenn Sieden Baum unterhalb von Zeile � öffnen, sehen Sie, dass die 52 BUS_TRANS_MSG-mBDocs zehn Aufträge (SALESDOCGEN_O_W-sBDoc),35 Aktivitäten (ACTIVITY_OBJECT-sBDoc), einen Service-Order(SRV_WRITE-sBDoc) und sechs Opportunities (OPP_WRITE-sBDoc)enthalten. Wenn Sie die Baumstruktur unterhalb dieser SO1-sBDocsöffnen (z.B. SALESDOCGEN_O_W in Zeile �), bekommen Sie Infor-mationen zu den verschiedenen Services und Funktionen, die bei derVerarbeitung der sBDocs aufgerufen wurden.

ZusammenfassungWenn die Verarbeitungszeiten eines Objekts also nicht gut genugsind, bieten Ihnen die statistischen Daten in der Transaktion SMWM-FLOW die Möglichkeit, genau zu analysieren, welcher Service oderwelche Funktion und welcher Bereich (Datenbank, CPU) langsam ist.Basierend auf dieser Information können Sie anschließend mit Hilfeeines SQL- oder ABAP-Traces ermitteln, in welchem Datenbank-State-ment oder in welcher Coding-Strecke die Zeit verloren geht.

Abbildung 8.18 Workload-Statistik – BDoc-Hierarchie (Transaktion SMWMFLOW)


232

Eingangs-Queues8

Nachrichtenfluss-Statistik

Um sich die Nachrichtenfluss-Statistiken anzeigen zu lassen, klickenSie in der Transaktion SMWMFLOW auf die Schaltfläche Nachrich-tenfluss-Statistik. Aufgrund der Entkopplung der Eingangs- und derAusgangsverarbeitung kann es sein, dass die Prozesse auf unter-schiedlichen Instanzen laufen. Daher sind die Statistiken der Ein-gangs- und der Ausgangsverarbeitung getrennt aufgeführt. Innerhalbder Eingangs- bzw. Ausgangsverarbeitung haben Sie die Möglichkeit,sich die Gesamtlast anzeigen zu lassen (Total) oder sich die Lastver-teilung über die einzelnen Instanzen anzusehen. Des Weiterenhaben Sie die Möglichkeit, ein Zeitintervall (Tag oder Woche) auszu-wählen. In Abbildung 8.19 sehen Sie ein Beispiel der Nachrichten-fluss-Statistik. Das System in diesem Beispiel verfügt über fünfInstanzen (us0091_Q5C_91 bis us4300_Q5C_91) und Tagesstatisti-ken vom 01.01.2007 bis zum 09.01.2007.

Abbildung 8.19 Nachrichtenfluss-Statistik (Transaktion SMWMFLOW)

Die verschiedenen Queue- und Verarbeitungszeiten werden auf derrechten Fensterseite dargestellt. Je nachdem, welchen Reiter Sie aus-wählen, werden die Zahlen pro BDoc-Typ, pro Site oder Queuezusammengefasst. Unter dem Reiter Zeitprofil finden Sie die Infor-mation, zu welchem Zeitpunkt wie viele BDocs verarbeitet wurdenund wie lange die Verarbeitung gedauert hat. Wenn Sie als Zeitinter-


233


vall einen Tag wählen, dann erscheint zusätzlich noch der Reiter Ein-zelsätze. Hier werden die Daten für jedes BDoc einzeln aufgelistet.

Zum leichteren Verständnis der Daten haben wir in Tabelle 8.4 (Ein-gangsverarbeitung) und in Tabelle 8.5 (Ausgangsverarbeitung) dieSpaltenüberschriften auf dem Reiter BDoc-Typ-Profil und ihreBedeutung aufgeführt. In Abbildung 8.20 (Eingangsverarbeitung)und in Abbildung 8.21 (Ausgangsverarbeitung) haben wir grafischdargestellt, wo die Zeiten innerhalb der Middleware gemessen wer-den.

Zeiten der Ein-gangsverarbeitung

Spaltentitel Bedeutung

Synchr.-BDoc-Typ Name des Synchronization-BDoc-Typs

Messaging-BDoc-Typ Name des Messaging-BDoc-Typs

bearbeitet Anzahl der insgesamt bearbeiteten BDocs dieses Typs

WSchl. Anzahl der BDocs dieses Typs in den Eingangs-Queues

Queue(s) Gesamtwartezeit in den Eingangs-Queues in Sekunden

DS(s) Durchschnittswartezeit in den Eingangs-Queues in Sekun-den

Eing.(ms) Gesamtbearbeitungszeit im Eingangsadapter in Millise-kunden

DS(ms) Durchschnittsbearbeitungszeit im Eingangsadapter in Mil-lisekunden

Mappg(ms) Gesamtbearbeitungszeit für das Mapping der BDocs in Millisekunden

DS(ms) Durchschnittsbearbeitungszeit für das Mapping der BDocs in Millisekunden

NFluß(ms) Gesamtbearbeitungszeit im Message Flow in Millisekun-den

DS(ms) Durchschnittsbearbeitungszeit im Message Flow in Milli-sekunden

Bearb.(ms) Gesamtbearbeitungszeit (ohne die Wartezeit in der Ein-gangs-Queue) in Millisekunden

DS(ms) Durchschnittsbearbeitungszeit (ohne die Wartezeit in der Eingangs-Queue) in Millisekunden

Tabelle 8.4 Bedeutung der Spalten in der Eingangsverarbeitung (Transaktion SMWMFLOW)


234

Eingangs-Queues8

Abbildung 8.20 Zeitangaben in der Eingangsverarbeitung (Transaktion SMWM-FLOW)

Zeiten der Aus-gangsverarbeitung

Eingangs-QueuesEingangsverarbeitung

Validierung

CRM-Applikation

mBDoc

sBDoc

XML

BAPI

Online-DB

CRM SITE*

R/3-Adapter

Groupware-Adapter

MobileAdapter

R3A*

ISP*

CRM SITE*

CRM SITE*

Validierungsservice

MobileClients

R/3

Groupware

Mapping

Mapping

Mapping

Spaltentitel Bedeutung

BDoc-Typ Name des BDoc-Typs

bearbeitet Anzahl der insgesamt bearbeiteten BDocs dieses Typs

WSchl. Anzahl der BDocs dieses Typs in den Eingangs-Queues

Queue(s) Gesamte Wartezeit in den Eingangs-Queues in Sekunden

DS(s) Durchschnittszeit in den Eingangs-Queues in Sekunden

NFluß(ms) Gesamtbearbeitungszeit im Message Flow in Millisekunden

DS(ms) Durchschnittszeit im Message Flow in Millisekunden

SFlow(ms) Gesamtbearbeitungszeit im Synchronization Flow in Millisekunden

DS(ms) Durchschnittszeit im Synchronization Flow in Millisekunden

SFlow-Zhlr. Anzahl der BDocs dieses Typs im Synchronization Flow

Durchschn. Anzahl der BDocs im Synchronization Flow geteilt durch die Anzahl der bearbeiteten BDocs

Bearb.(ms) Gesamtbearbeitungszeit (ohne die Wartezeit in der Eingangs-Queue) in Millisekunden

DS(ms) Durchschnittszeit (ohne die Wartezeit in der Eingangs-Queue) in Millisekunden

Tabelle 8.5 Bedeutung der Spalten in der Ausgangsverarbeitung (Transaktion SMWMFLOW)


235


Abbildung 8.21 Zeitangaben in der Ausgangsverarbeitung (Transaktion SMWM-FLOW)

8.4.3 CRM Middleware Trace

Trace-Stufen einstellen

Der CRM Middleware Trace bietet Ihnen die Möglichkeit, zusätzlicheInformationen zu bekommen, die während der Verarbeitung in derMiddleware geschrieben werden. Das CRM-System erlaubt es Ihnennicht nur, das Schreiben des Middleware-Trace ein- und auszuschal-ten, sondern Sie können auch festlegen, in welchem Bereich und mitwelcher Granularität der Trace geschrieben wird. Sie können zumBeispiel festlegen, dass im Nachrichtenfluss der Trace auf Fehler undWarnungen (Trace-Stufe: Warnung) beschränkt wird, während beider Generierung alle Informationen (Trace-Stufe: Detailebene 2)geschrieben werden sollen (siehe Abbildung 8.22). Zur Verwaltungder Trace-Stufe gelangen Sie über das SAP Easy Access-Menü Archi-tektur und Technologie � Middleware � Monitoring � Nachrichten-fluss � Middleware-Trace einrichten oder über die TransaktionSMWTAD.

MobileClients

Ausgangs-Queues


Synchronization FlowMobile Bridge

Mobile-Adapter

Replikations-service

R/3


R&R-Service

XML

sBDoc

CDBCDB-

Service


ISP*

CRM SITE*

CRM SITE*

CRM SITE*

sBDoc

CSA*


236

Eingangs-Queues8

Abbildung 8.22 Einstellungen des Middleware-Trace (Transaktion SMWTAD)

Trace-Stufen Folgende Trace-Stufen stehen Ihnen zur Verfügung:

� Stufe 0: FehlerNur schwere Fehler werden gemeldet.

� Stufe 1: WarnungenEs werden nur Umstände gemeldet, die zu einem Fehler führenkönnen.

� Stufe 2: Service FlowEs werden alle Services aufgeschrieben, die in der Middlewaredurchlaufen werden.

� Stufe 3: Detailebene 1Es werden zusätzliche Informationen zu den ausgeführten Pro-grammen und Modulen geschrieben.

� Stufe 4: Detailebene 2Es werden programmspezifische Informationen geschrieben.

Die Standardeinstellung im produktiven System ist die Stufe 1. DieStufen 3 und 4 sind für Entwickler gedacht.


237


Aus Performance- und Plattenplatzgründen sollten Sie alte Tracesregelmäßig löschen. SAP stellt Ihnen zur Reorganisation den ReportSMO6_REORG2 zur Verfügung, mit dem sich u.a. auch die Traceslöschen lassen. Details zu diesem Report und zur Reorganisation imAllgemeinen finden Sie in Kapitel 12, Reorganisation.

Trace anzeigenZum Trace selbst gelangen Sie, indem Sie im SAP Easy Access-Menüfolgendem Pfad folgen:

Architektur und Technologie � Middleware � Monitoring � Nachrich-tenfluss � Middleware-Trace anzeigen

Alternativ können Sie auch die Transaktion SMWT verwenden. InAbbildung 8.23 sehen Sie das Auswahlfenster, das erscheint, wennSie die Transaktion starten.

Abbildung 8.23 Auswahlfenster Middleware-Trace (Transaktion SMWT)

Entsprechend den von Ihnen eingetragenen Auswahlkriterien wirdIhnen eine Liste mit den im System vorhandenen Traces angezeigt.Durch einen Doppelklick auf die entsprechende Zeile wird der Traceangezeigt (siehe Abbildung 8.24).


238

Eingangs-Queues8

Abbildung 8.24 Middleware-Trace

Der Trace selbst enthält eine Reihe von Informationen: NebenDatum, Uhrzeit, Umgebung und Trace-Stufe (Level) werden insbe-sondere das Textfeld und die Trace-GUID angezeigt. Im Textfeld fin-den Sie die Trace-Meldung (maximal 250 Zeichen), und die Trace-GUID enthält die GUID des Trace-Objekts. Wenn Sie beispielsweisedie Trace-Meldungen zu einem bestimmten BDoc suchen, könnenSie im Feld Trace-GUID nach der GUID des BDocs suchen. Alternativkönnen Sie die BDoc-GUID als Auswahlkriterium im Feld GUID1 ein-tragen; dann werden Ihnen nur die Traces angezeigt, die Meldungenzu dem BDoc enthalten (siehe Abbildung 8.23). Speziell bei BDocsgibt es zusätzlich noch die Möglichkeit, von der Transaktion SMW01aus direkt in den Trace abzuspringen. Dazu markieren Sie das BDocin der SMW01 und klicken auf die Schaltfläche Middleware-Trace(siehe Abbildung 8.25).

Abbildung 8.25 Absprung in den Middleware-Trace aus Transaktion SMW01


239

Abhängigkeiten zwischen Eingangs-Queues 8.5

8.5 Abhängigkeiten zwischen Eingangs-Queues

Die parallele Abarbeitung der CSA-Eingangs-Queues ist nicht immeruneingeschränkt möglich. Bei einigen Objekttypen kann es zwischeneinzelnen Queues zu Abhängigkeiten kommen, so dass die Abarbei-tung einer Queue warten muss, bis einer oder mehrere Einträgeeiner anderen Queue verarbeitet wurden. Das folgende Beispiel ver-deutlicht diese Problematik anhand eines Downloads von Geschäfts-partnerbeziehungen aus dem R/3.

Beispiel

In einem CRM-System wird ein Request aller Geschäftspartnerbeziehun-gen gestartet. Die Anzahl der R3AR_BUPA*-Queues ist auf drei, dieAnzahl der CSABUPA*-Queues ist nicht limitiert. Ein BUPA_REL-BDoc ausdem R/3 enthält alle Beziehungen eines Geschäftspartners (zur Vereinfa-chung gehen wir im Folgenden davon aus, dass alle Geschäftspartner vierBeziehungen haben). Wird ein RFC-Satz in einer R3AR-Queue verarbeitet,werden die einzelnen Beziehungen in unterschiedliche CSA-Queuesgeschrieben (in Abhängigkeit von der Geschäftspartner-GUID in derBeziehung). Es entstehen also fünf CSA-Queue-Einträge (und damit auchdie entsprechenden CSA-Queues), obwohl nur ein mBDoc erzeugt wird.Wird das mBDoc verarbeitet, sehen Sie in der Transaktion SMQ2, dass diefünf Queues sich im Status running befinden, und in Transaktion SM50sehen Sie, dass nur ein Workprozess belegt ist.

Das BDoc kann nur verarbeitet werden, wenn alle CSA-Queue-Einträge ander ersten Stelle der jeweiligen Queue stehen, da sich die Queue-Einträgeansonsten überholen würden.

Wird die Anzahl der CSA-Queues nicht limitiert, haben sie in der Regeleinen Eintrag. Nur wenn zwei Geschäftspartner eine Beziehung unterein-ander oder zu einem gemeinsamen Dritten haben, kommt es zu zwei odermehreren Einträgen in einer CSABUPA-Queue. In Abbildung 8.26 sehenSie, dass sowohl Geschäftspartner 1111 als auch 2222 eine Beziehungzum Geschäftspartner 4112 haben. Werden die beiden Einträge in denQueues R3AR_BUPA1111 und R3AR_BUPA2222 verarbeitet, werdenzwei Einträge in die CSABUPA4112-Queue geschrieben. In alle anderenCSABUPA*-Queues wird nur ein Eintrag geschrieben. Die BUPA_REL-BDocs in den CSA-Queues zu den Geschäftspartnern GP1111 undGP3333 können sofort und parallel verarbeitet werden, da die jeweiligenEinträge an erster Stelle in den CSA-Queues stehen. Das BUPA_REL-BDoczum Geschäftspartner GP2222 kann nicht sofort verarbeitet werden, dadie Beziehung GP2222-GP4112 nicht an der ersten Stelle in der QueueCSABUPA4112 steht. Alle Queues, die eine Geschäftspartnerbeziehungzum GP2222 als ersten Eintrag haben (CSABUPA412*), bekommen denStatus waiting, da sie erst verarbeitet werden können, nachdem die Ge-


240

Eingangs-Queues8

Abbildung 8.26 Abhängigkeiten zwischen CSA-Queue-Einträgen

Ist die Anzahl der CSA-Queues nicht limitiert – wie in dem Beispielbeschrieben –, kommt es nur selten zu Situationen, in denen Queuesaufeinander warten müssen, oder es entstehen so viele Queues, dassdie Verarbeitungsgeschwindigkeit dadurch nicht beeinträchtigtwird. Anders stellt sich die Situation dar, wenn die Zahl der CSA-Queues sehr stark limitiert wurde. Die CSA-Queues haben generellmehr Einträge, und die Anzahl der aufeinander wartenden Queuessteigt, wie das folgende Beispiel verdeutlicht.

Geschäftspartnerbeziehung GP1111-GP4112 in Queue CSABUPA4112verarbeitet wurde.

Beispiel

Die Voraussetzungen in diesem Beispiel entsprechen denen des letztenBeispiels mit dem einzigen Unterschied, dass die Anzahl der CSABUPA*-Queues auf zehn limitiert wurde.

In Abbildung 8.27 sehen Sie, dass aufgrund der anderen Queue-Namens-findung die Beziehung zwischen GP2222 und GP4127 sowie die Beziehungzwischen GP3333 und GP4137 in dieselbe Queue geschrieben werden.

R3AR_BUPA3333

R3AR_BUPA2222

GP1111

GP4111

GP4112

GP4113

GP4114

GP2222

GP4112

GP4125

GP4126

GP4127

GP3333

GP4137

GP4138

GP4139

GP4130

R3AR_BUPA1111

Statusrunning

running

running

running

waiting

waiting

GP1111GP4111CSABUPA4111










GP2222GP4112

waiting

GP2222GP4137CSABUPA4137 running

running

running

running


241

Abhängigkeiten zwischen Eingangs-Queues 8.5

Abbildung 8.27 Abhängigkeiten bei limitierter Anzahl von CSA-Queues

Die Folge ist, dass das BUPA_REL-BDoc vom Geschäftspartner 3333 erstverarbeitet werden kann, wenn der Eintrag GP2222-GP4127 der QueueCSABUPA4127, d.h. das BUPA_REL-BDoc vom Geschäftspartner 2222,verarbeitet worden ist. Dieser Eintrag kann aber erst verarbeitet werden,wenn der erste Eintrag GP1111-GP4112 der Queue CSABUPA4112, d.h.das BUPA_REL-BDoc vom Geschäftspartner 1111, verarbeitet wurde. Dasbedeutet mit anderen Worten, dass die BUPA_REL-BDocs sequenziellabgearbeitet werden, obwohl zehn CSA-Queues existieren.

R3AR_BUPA3333

R3AR_BUPA2222

GP1111

GP4111

GP4112

GP4113

GP4114

GP2222

GP4112

GP4125

GP4126

GP4127

GP3333

GP4137

GP4138

GP4139

GP4130

R3AR_BUPA1111

Status

running

running

running

running

waiting

waiting

waiting

waiting

waiting











GP2222GP4112

GP3333GP4137

waiting


415

Index

.NET Connector 45

A

Ablehnungsnachricht 81, 127AC_EXTRACT-Queue 114AC-Extrakt 123, 292

Bulk-Extrakt 293ungefilterter Extrakt 293

Adapter 64Adapter-Framework 64Adapterobjekt 65

Aktivieren oder Deaktivieren 70Blockgröße 67Business-Objekt 65Customizing-Objekt 65Filtereinstellungen 74initialer Flow-Kontext 70Konditionsobjekt 65Mapping-Baustein CRM → R/3 75Mapping-Baustein R/3 → CRM 75Objektklasse 68Tabellen/Strukturen 72übergeordnete Objekte 75Zuordnung zu einem BDoc-Typ 67

Administrationskonsole 31, 92Verbesserungen 378Wizard 100

Analyse-RoadmapCPU-Engpass-Analyse 356, 412Eingangs-Queue-Verarbeitung

348, 411R&R-Optimierung 352, 412Workprozessanalyse 345, 410

Ankreuzleiste 181ARFCRDATA, Tabelle 48, 50ARFCRSTATE, Tabelle 47, 48ARFCSDATA, Tabelle 46, 47, 50ARFCSSTATE, Tabelle 46, 47, 48Ausgangsadapter 70, 92, 104, 106Ausgangs-qRFC mit Empfängerliste

279Vorteile 280

Ausgangs-Queue 29, 31, 49, 91, 128des Mobile Clients 33Details anzeigen 135

Einträge anzeigen 135im R/3 25Status 133Übersicht anzeigen 133

Ausgangs-Queue-NameDaten ins R/3 136Daten zu Mobile Clients 137Weitere 138

Ausgangs-Scheduler 129Ausgangsverarbeitung 91

für das R/3 29für Mobile Clients 32

B

Background-RFC 379BAPIMTCS 177BAPI-Struktur 25BDoc 37, 38

Fehlerstatus 155finaler Status 156Freigabe 152Instanz 146Klasse 142robuste Datenablage 158Sendbits 153Standardfeld 153statische WHERE-Klausel 151Status 154Task-Typ 153Typ 146Zuordnung Segment und Datenbank

149Zwischenstatus 154

BDoc Modeler 146BDoc-Freigabe

WHERE-Klausel 152BDoc-Instanz 40, 146BDoc-Merge 376BDoc-Nachricht 39BDoc-Statistik, Reorganisation 319BDoc-Store 77, 82BDoc-Typ 26, 39

Sperre 153BDoc-Verknüpfung

Nachbarfunktionalität 326Reorganisation 325


416

Index

Vermeidung 325Bestätigungsnachricht 127bgRFC → s. Background-RFCBlockgröße 288Bulk-Extrakt 293Bulk-Nachricht 127Business-Dokument 38Business-Objekt, Adapterobjekt 65

C

CDB 31, 110, 111CDB-Service 31, 110, 111ConnTrans 32, 76

Übertragungsdauer 282Consolidated Database → s. CDBCP_CODEPAGE 312CRM_MAX_QUEUE_NUMBER_DEL

TA, Parameter 211, 214CRMPAROLTP, Tabelle

Anzahl Eingangs-Queues 211CRM_XML_BACKGROUND_PROC

ESSING_ON 309CRMQNAMES, Tabelle 62, 210

FLDOFFSET, Feld 208LENGTH, Feld 208

CRMRFCPAR, TabelleXML-Steuerung 307

CRMSUBTAB, Tabelle 68, 177CRS_FIRST_DOWNLOAD_TRIGGER

177CSA-Queue 29, 103Current-State-Nachricht 127Customizing-Objekt, Adapterob-

jekt 65

D

Data Integrity Manager 139Datenbanktabelle anlegen 178Datenkollektor 261, 292, 306

Reorganisation 322Datenübernahme

Delta 65initial 64

DBSTATC, Tabelle 270DB-Statistiken 270Default Pool 286Delta-Datenübernahme 65Destination

ausschließen 132Parameter 131registrieren oder deregistrieren 131

Dienst, Generierung 188DIMa → s. Data Integrity Managerdynamisches Mapping 78

E

Eingangsadapter 26, 37, 64, 70Eingangs-Queue 26, 34, 37, 44, 49

Abhängigkeiten 239Anzahl Queues verringern 206deregistrieren 55des Mobile Clients 32Details 61Einträge 61im R/3 29Langsame Abarbeitung 205Parameter 55registrieren 53Status 60Übersicht 57

Eingangs-Queue-NameDaten aus dem R/3 62Daten von Mobile Clients 62für CSA-Queues 103

Eingangs-Queue-Scheduler 45, 51aktivieren 52Performance 205Status 52

Eingangs-Scheduler 51Eingangsverarbeitung 37

Daten aus dem R/3 28Daten vom Mobile Client 35

Error Handler 81, 84Erweiterungsteil → s. mBDocEXEMODE, Parameter 55Extended Markup Language → s.

XMLEXTRACTBLK-Queue 114EXTRACT-Queue 114Extraktor 177

F

Flow 37, 40Definition 42Kontext 40, 185


417

Index

G

generierter Mobile-Eingangsadap-ter 76

generischer Mobile-Eingangsadap-ter 76

GNRWB, Transaktion 314Groupware-Adapter

GWA_01 162GWA_02 162

Groupware-IntegrationAnalyse 171Client-Client-Szenario 161Daten-Queue, primäre 166Daten-Queue, sekundäre 166Groupware-Adapter 162Groupware-Konnektor 164Groupware-Konnektor-Proxy 164MapBox 163MapBox, Log-Dateien 171MapBox, RFC-Destination 164MBMANDTSTORE, Tabelle 168Ordner, öffentlich 163Ordner, privat 163Payload Interface 164Server-Server-Szenario 161System-Queues 167, 170Trace des internen SyncPoints 171Trace des Payload Interfaces 173Übersicht 161userlist.xml 168

Groupware-Konnektor → s. Group-ware-Integration

GWI → s. Groupware-Integration

H

Hardware-Engpass 215

I

Indexfragmentierung 271Indexqualität 271initiale Datenübernahme 64, 189Integrationsmodell

Nachrichtenaustausch 142Synchronisation 142

Interlinkage 100, 257

J

Java Connector (JCo) 45

K

Keep Pool 287Kernel-Anwendungsstatistiken 227klassischer Teil → s. mBDocKommunikationsmonitor, Reorgani-

sation 320Konditionsobjekt, Adapterobjekt 65

L

Logical Unit of Work 47logische Destination einrichten 223Lookup-Tabelle 31, 92, 260Löschnachricht 127

Vermeidung 255LUW 47

M

MapBox → s. Groupware-IntegrationMapping 78

BAPI-Container in mBDoc 186dynamisch 78mBDoc zu sBDoc 31statisch 78, 145

Mapping-Funktionsbaustein 26Mapping-Methode 34Massenänderung 194

geplant 337ungeplant 337

MAX_PACKAGE_SIZE, Parameter 288

MAXTIME, Parameter 55, 364mBDoc 26, 38, 142

Erweiterungsteil 143Erweiterungsteil anlegen 180klassischen Teil anlegen 184klassischer Teil 143

MBMANDTSTORE, Tabelle 168Messaging BDoc → s. mBDocMessaging Flow 103Middleware-Trace 235

Reorganisation 319Trace anzeigen 237


418

Index

Trace-Stufe einstellen 235Mobile Application BDoc 142Mobile Bridge 30, 92, 104, 107Mobile-Adapter 110Mobile-Ausgangsadapter 31, 126Mobile-Eingangsadapter 34

generierter 76generischer 76

N

Nachbarfunktionalität 325Nachrichtenfluss-Statistik 232

an-/abschalten 227Kernel-Anwendungsstatistik 227Statistik Middleware Message Flow

228NRETRY, Parameter 55

O

Objektklasse anlegen 187Online-Datenbank 27, 37

P

Parallelisierung, Optimierung der Middleware 328

Payload Interface → s. Groupware-Integration

Performance-Analyse 222SMWMFLOW 226SMWT 235

Plattensubsystem 284Publikation 95

Q

QIN-Scheduler → s. Eingangs-Queue-Scheduler

QOUT-Scheduler 129aktivieren 131Status 130

QREFTID, Tabelle 50qRFC 45, 48, 129

Monitor für Ausgangs-Queues 132Monitor für Eingangs-Queues 57

qRFC-Monitor für Eingangs-Queues 45

Query-BDoc → s. Mobile Application BDoc

Queue, Stoppen einer 265Queued RFC → s. qRFCQueue-Namensgebung

Änderung der Queue-Namensge-bung 207

Vor-/Nachteile 212

R

R&R 295blockweise Abarbeitung der Queues

374Definition 243DEPENDENCY-Queue 372interne Optimierung 272neuere Verbesserungen 372neues Queue-Framework 372Optimierung einer Massenänderung

276parallele Abarbeitung der Queues

374Parallelisierung der Queue-Verarbei-

tung 264Realignment 243Replikation 243Replikations-Wrapper 246verteilrelevante Felder 246Warteschlangen 244

R&R-Queue 114anzeigen 115starten oder stoppen 118Status 117

R&R-Queue-Dämon 115starten oder stoppen 117Status 116

R&R-Queue-Framework 114R&R-Service 31, 110R/3-Ausgangsadapter 29R3AC1, Transaktion 65, 188R3AC3, Transaktion 65, 186R3AC5, Transaktion 66R3AC6, Transaktion

Queue-Parallelisierung 264Steuerung der Reorganisation 320

R3AM1, Transaktion 189R3AR2, Transaktion

einmalige Anforderung 324


419

Index

R3AS, Transaktion 189Realignment 31, 112REALIGN-Queue 114Remote Function Call → s. RFCReorganisation

Anforderung 324BDoc-Nachrichten 319BDoc-Statistiken 319BDoc-Verknüpfungen 325Datenkollektor 322Middleware-Trace 319SAP_MW_REORG, Variante 319Schlüsselgenerierung 319SMO6_REORG 318SMO6_REORG2 318SMW3*-Tabellen 319Standardvariante 319Statistiken der CommStation-Sitzun-

gen 320Subskriptionsagent 322von Daten nicht aktivierbarer Sites

324Replication & Realignment → s. R&RReplication & Realignment-Service

→ s. R&R-ServiceReplikation 31, 112, 118

Bulk 118Intelligent 119

Replikationsobjekt 92Replikationsobjekttyp 93, 94

Abhängig 99Bulk 98Intelligent 99Simple Bulk (MESG) 98Simple Intelligent (MESG) 98Simple Intelligent (SYNC) 98

Replikationsservice 29, 104mBDoc 105sBDoc 118

Replikations-WrappermBDoc 105sBDoc 118

RFC 45RFC Software Development Kit 45RFC-Libraries 45RFC-Server-Gruppe 216, 266

anlegen 216optimale Anzahl 336Parameter 217Profilparameter 219

zuordnen 219RSANAORA, Report 271RSRLDREL, Programm 325RSTRFCQD, Report 367RSTRFCQDS, Report 367RZ12, Transaktion 216

S

SBDM, Transaktion 76, 80, 146, 184

sBDoc 30, 38, 142Blockgröße 288Struktur 142

Scheduler, tRFC 46SDIMA, Transaktion 139SDK

(RFC) Software Development Kit 45SE11, Transaktion 178Segment, Feldzuordnung 142Service 40Site 96

deaktivieren 252Massendeaktivierung 254

Site-Typ 96Site-Deaktivierung nicht unter-

stützt 324Sizing 287SM50, Transaktion

Belegung der Workprozesse 343SM59, Transaktion 55, 130

logische Destination einrichten 223SMO 285SMO8FD, Transaktion 42, 83SMO9_KYTBL, Tabelle

Reorganisation 319SMOE_BULK_SITE_ACTIVATION,

Report 295SMOEAC, Transaktion 63, 92, 137

AC-Extrakt 292XML-Optimierung 313

SMOECK, Transaktion 249SMOEGENDET, Tabelle 102SMOEGENHEA, Tabelle 102SMOEGENLOG, Tabelle

Reorganisation 322SMOEJOBID, Tabelle

Reorganisation 320SMOFFILTAB, Tabelle 74SMOFINICON, Tabelle 71


420

Index

SMOFOBJCLA, Tabelle 70SMOFOBJECT, Tabelle 66, 67, 70SMOFOBJPAR, Tabelle 75SMOFPARSFA, Tabelle 320

Blockgröße 288blockweise Abarbeitung der R&R-

Queues 375Default-Codepage 311mBDoc-Verknüpfungen deaktivie-

ren 325SMOFQFIND, Tabelle 210SMOFQNAMES, Tabelle 137SMOFSUBTAB, Tabelle 75SMOFUPLMAP, Tabelle 75SMOGGEN, Transaktion 188, 252SMOHILTP, Tabelle 102SMOHJOBQ, Tabelle 268SMOHLUBULK, Tabelle 98, 247SMOHMSGQ, Tabelle 115, 268

Optimierung des Zugriffspfads 268SMOHMSGST, Tabelle 268SMOHPUBL, Tabelle 95SMOHQTAB, Tabelle 63, 137SMOHQUEUE, Transaktion 115,

117, 118, 244, 252AC-Extrakt 293Blockgröße 289Queue stoppen 365

SMOHREPOBJ, Tabelle 94SMOHSGQST, Tabelle 115SMOHSITEID, Tabelle 96SMOHSITEQ, Tabelle 115, 268SMOHSUBSCR, Tabelle 97SMOHSUBSIT, Tabelle 97SMOJDC, Transaktion 264SMOJDCPROC, Tabelle

Reorganisation 322SMQ1, Transaktion 132SMQ2, Transaktion 57SMQR, Transaktion 51

logische Destination einrichten 224MAXTIME 364RFC-Server-Gruppe ändern 219

SMQS, Transaktion 130SMW01, Transaktion 85, 326

Absprung zum Middleware-Trace 238

DEBUGMODE 158SMW1SPRVDR, Tabelle 324SMW3*, Tabelle

Reorganisation 319SMW3BDOCIF, Tabelle 43, 82, 185SMW3FDBDOC, Tabelle 44, 108SMW3FDBDOC, Transaktion 44,

108SMW3FDCUST, Tabelle 44SMW3FDCUST, Transaktion 44SMW3FDIF, Transaktion 44, 78,

82, 185SMW3FDSTD, Tabelle 44SMW3FDSTD, Transaktion 44SMWMCOMM, Transaktion 320SMWMFLOW, Transaktion 226

Nachrichtenfluss-Statistik 232Workload-Statistik 228

SMWMSESSHT, Tabelle 320SMWMSESSIN, Tabelle 320SMWT, Transaktion 237, 319SMWT_TRC, Tabelle

Reorganisation 319SMWTAD, Transaktion 235SPRO, Transaktion 85ST03N, Transaktion 319, 320ST06, Transaktion

Idle-Zeit 353Load average 355

statisches Mapping 78Statistik Middleware Message Flow

228Storage Area Network 284Storage Quality 286SUBCHECK-Queue 114Subskription 97

Ändern der Zuordnung von Sites 124

Subskriptionsagent 102Reorganisation 322

Subskriptionsgenerierer 102Synchronisation 65Synchronization BDoc → s. sBDocSynchronization Flow 92, 110System Optimization Services 285Systemlandschaft

heterogen 307homogen 307inhomogen 307

Systemüberwachung 341Systemverbund 193


421

Index

T

TDELAY, Parameter 55TID 47Transaction Identifier 47Transactional Remote Function Call

→ s. tRFCtransaktionaler RFC → s. tRFCtRFC 45, 46TRFCQDATA, Tabelle 50TRFCQIN, Tabelle 50TRFCQOUT, Tabelle 50TRFCQSTATE, Tabelle 50TRFCRSTATE, Tabelle 50TRFCSDATA, Tabelle 50TRFCSSTATE, Tabelle 50TSMW3_STAT, Tabelle 154

U

Upload 65USERDEST, Parameter 55

V

Validierung 37, 81, 185Daten aus dem R/3 27Daten vom Mobile Client 35

Validierungsservice 26, 82Verteilmodell 31, 92

Optimierung 248Optimierung der Bulk-Publikationen

249Optimierung durch 256Optimierung von Interlinkages 257

VerteilungBulk 247intelligent 246intelligent, ohne Filterkriterium

249intelligent, Umstellung auf Bulk

250

W

WHERE-Klausel → s. BDocWizard 100Workload-Statistik 228

an-/abschalten 227

X

XML 307Codepage-Konvertierung 311Datenaustausch mit Mobile Clients

310Datenaustausch zwischen R/3 und

CRM 307Einschränkungen der Optimierung

315Entkopplung von Anwendung und

Konvertierung 309Performance-Verbesserungen für

Mobile-Client-Datenaustausch 311

synchroner RFC 308zwischen CRM-Server und Mobile

Client 310zwischen R/3 und CRM 307

Z

ZAP-Nachricht 127, 294


Optimierung der SAP CRM Middleware - EDV-BUCHVERSAND

Documents

Transcript of Optimierung der SAP CRM Middleware - EDV-BUCHVERSAND