optimierung der sap crm middleware - edv-buchversand
Post on 03-Oct-2021
6 Views
Preview:
TRANSCRIPT
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
Eingangsverarbeitung
MobileClients
Ausgangs-Queues
Ausgangsverarbeitung
Validierung
Synchronization Flow
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
BAPI R/3-AdapterR3A*
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
846-0.book Seite 203 Montag, 2. April 2007 12:07 12
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
�
Eingangsverarbeitung
MobileClients
Ausgangs-Queues
�
Ausgangsverarbeitung
Validierung
Synchronization Flow
CRM-Applikation
Mobile Bridge
Mobile-Adapter
Replikationsservice
R/3
Groupware Groupware-Adapter
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
�
Ausgangsverarbeitung
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
�
Eingangsverarbeitung
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
846-0.book Seite 204 Montag, 2. April 2007 12:07 12
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.
846-0.book Seite 205 Montag, 2. April 2007 12:07 12
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.
846-0.book Seite 206 Montag, 2. April 2007 12:07 12
207
Die Anzahl der Eingangs-Queues ist zu hoch 8.1
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
846-0.book Seite 207 Montag, 2. April 2007 12:07 12
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
846-0.book Seite 208 Montag, 2. April 2007 12:07 12
209
Die Anzahl der Eingangs-Queues ist zu hoch 8.1
2. Einstellung: FLDOFFSET = 9 und LENGTH = 1
Ergebnis: Die sechs Kunden werden in zwei Queues geschrieben.
R/3-Kundennummer CRM-Queue-Name
0000054601 R3AD_CUSTOME0000054601
0000034541
0000099421
0000028421
0000028422 R3AD_CUSTOME0000028422
0000067822
3. Einstellung: FLDOFFSET = 8 und LENGTH = 2
Ergebnis: Die sechs Kunden werden in vier Queues geschrieben.
R/3-Kundennummer CRM-Queue-Name
0000054601 R3AD_CUSTOME0000054601
0000034541 R3AD_CUSTOME0000034541
0000099421 R3AD_CUSTOME0000099421
0000028421
0000028422 R3AD_CUSTOME0000028422
0000067822
4. Einstellung: FLDOFFSET = 6 und LENGTH = 2
Ergebnis: Die sechs Kunden werden in fünf Queues geschrieben.
R/3-Kundennummer CRM-Queue-Name
0000054601 R3AD_CUSTOME0000054601
0000034541 R3AD_CUSTOME0000034541
0000099421 R3AD_CUSTOME0000099421
0000028421 R3AD_CUSTOME0000028421
0000028422
0000067822 R3AD_CUSTOME0000067822
846-0.book Seite 209 Montag, 2. April 2007 12:07 12
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.
846-0.book Seite 210 Montag, 2. April 2007 12:07 12
211
Die Anzahl der Eingangs-Queues ist zu hoch 8.1
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.
846-0.book Seite 211 Montag, 2. April 2007 12:07 12
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.
846-0.book Seite 212 Montag, 2. April 2007 12:07 12
213
Die Anzahl der Eingangs-Queues ist zu hoch 8.1
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.
846-0.book Seite 213 Montag, 2. April 2007 12:07 12
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.
846-0.book Seite 214 Montag, 2. April 2007 12:07 12
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
846-0.book Seite 215 Montag, 2. April 2007 12:07 12
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.
846-0.book Seite 216 Montag, 2. April 2007 12:07 12
217
Hardware-Engpässe 8.3
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
846-0.book Seite 217 Montag, 2. April 2007 12:07 12
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.
846-0.book Seite 218 Montag, 2. April 2007 12:07 12
219
Hardware-Engpässe 8.3
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
846-0.book Seite 219 Montag, 2. April 2007 12:07 12
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.
846-0.book Seite 220 Montag, 2. April 2007 12:07 12
221
Hardware-Engpässe 8.3
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.
846-0.book Seite 221 Montag, 2. April 2007 12:07 12
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).
846-0.book Seite 222 Montag, 2. April 2007 12:07 12
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).
846-0.book Seite 223 Montag, 2. April 2007 12:07 12
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)
846-0.book Seite 224 Montag, 2. April 2007 12:07 12
225
Performance-Analyse der Einzelsatzverarbeitung 8.4
Abbildung 8.9 Benutzer der neuen Verbindung zuordnen (Transaktion SM59)
Abbildung 8.10 Logische Destination eintragen (Transaktion SMQR)
846-0.book Seite 225 Montag, 2. April 2007 12:07 12
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
846-0.book Seite 226 Montag, 2. April 2007 12:07 12
227
Performance-Analyse der Einzelsatzverarbeitung 8.4
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
846-0.book Seite 227 Montag, 2. April 2007 12:07 12
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
846-0.book Seite 228 Montag, 2. April 2007 12:07 12
229
Performance-Analyse der Einzelsatzverarbeitung 8.4
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)
846-0.book Seite 229 Montag, 2. April 2007 12:07 12
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
846-0.book Seite 230 Montag, 2. April 2007 12:07 12
231
Performance-Analyse der Einzelsatzverarbeitung 8.4
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)
846-0.book Seite 231 Montag, 2. April 2007 12:07 12
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-
846-0.book Seite 232 Montag, 2. April 2007 12:07 12
233
Performance-Analyse der Einzelsatzverarbeitung 8.4
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)
846-0.book Seite 233 Montag, 2. April 2007 12:07 12
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)
846-0.book Seite 234 Montag, 2. April 2007 12:07 12
235
Performance-Analyse der Einzelsatzverarbeitung 8.4
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
Ausgangsverarbeitung
Synchronization FlowMobile Bridge
Mobile-Adapter
Replikations-service
R/3
Groupware Groupware-Adapter
R&R-Service
XML
sBDoc
CDBCDB-
Service
BAPI R/3-AdapterR3A*
ISP*
CRM SITE*
CRM SITE*
CRM SITE*
sBDoc
CSA*
846-0.book Seite 235 Montag, 2. April 2007 12:07 12
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.
846-0.book Seite 236 Montag, 2. April 2007 12:07 12
237
Performance-Analyse der Einzelsatzverarbeitung 8.4
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).
846-0.book Seite 237 Montag, 2. April 2007 12:07 12
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
846-0.book Seite 238 Montag, 2. April 2007 12:07 12
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-
846-0.book Seite 239 Montag, 2. April 2007 12:07 12
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
GP1111GP4112CSABUPA4112
GP1111GP4113CSABUPA4113
GP1111GP4114CSABUPA4114
GP2222GP4125CSABUPA4125
GP2222GP4126CSABUPA4126
GP2222GP4127CSABUPA4127
GP3333GP4138CSABUPA4138
GP3333GP4139CSABUPA4139
GP1111GP4130CSABUPA4130
GP2222GP4112
waiting
GP2222GP4137CSABUPA4137 running
running
running
running
846-0.book Seite 240 Montag, 2. April 2007 12:07 12
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
GP1111GP4111CSABUPA4111
GP1111GP4112CSABUPA4112
GP1111GP4113CSABUPA4113
GP1111GP4114CSABUPA4114
GP2222GP4125CSABUPA4125
GP2222GP4126CSABUPA4126
GP2222GP4127CSABUPA4127
GP3333GP4138CSABUPA4138
GP3333GP4139CSABUPA4139
GP1111GP4130CSABUPA4130
GP2222GP4112
GP3333GP4137
waiting
846-0.book Seite 241 Montag, 2. April 2007 12:07 12
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
846-0.book Seite 415 Montag, 2. April 2007 12:07 12
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
846-0.book Seite 416 Montag, 2. April 2007 12:07 12
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
846-0.book Seite 417 Montag, 2. April 2007 12:07 12
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
846-0.book Seite 418 Montag, 2. April 2007 12:07 12
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
846-0.book Seite 419 Montag, 2. April 2007 12:07 12
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
846-0.book Seite 420 Montag, 2. April 2007 12:07 12
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
846-0.book Seite 421 Montag, 2. April 2007 12:07 12
top related