Datenkollektor für SAP Customer Relationship Management (CRM) Status:

Transkript

1 Datenkollektor für SAP Customer Relationship Management (CRM) Status:

2 Inhaltsverzeichnis SAP CRM DATENKOLLEKTOR 3 DIE LEISTUNGSMERKMALE DES DATENKOLLEKTORS FÜR SAP CRM...3 Ziele des Monitorings:...3 CRM Middleware Component Monitoring...3 Kommunikation zwischen CRM-System und R/3-OLTP-System...3 Kommunikation zwischen R/3 OLTP-System und CRM-System...4 Scheduler Status SMQR...5 Überwachung der Replication Queue...5 BDoc Summary SMW01/SMW Dieser Datenkollektor ist für die folgenden Anwendungen erhältlich:...7 Performance-Daten...7 Copyright REALTECH 2008 Seite 2 von 7

3 SAP CRM Datenkollektor Die Leistungsmerkmale des Datenkollektors für SAP CRM Ziele des Monitorings: Herausfinden von fehlerhaften Dokumenten Herausfinden von inkonsistenten Status im Empfänger- und Sendersystem CRM Middleware Component Monitoring Um Dateninkonsistenzen vorzubeugen ist es wichtig die Schnittstellen regelmäßig auf abgebrochene oder gestoppte Übertragungen von Dokumenten zu prüfen. Kommunikation zwischen CRM-System und R/3-OLTP-System Es ist normal, dass die Queues der einzelnen Mandanten schon einige Einträge enthalten, wie z.b.: Einträge aller Objekte, die zu dem OLTP-System und zu den mobilen Mandanten gesendet werden sollen Jede Queue enthält einzelne trfcs in einer bestimmten Reihenfolge, genannt qrfc Jeder Mandant hat eine fest zugeordnete Nummer Mobile Mandanten bauen eine asynchrone Verbindung zum CRM-System auf - die Queue wartet solange in SMQ1 bis der mobile Mandant verbunden ist, damit er seine Nachrichten abrufen kann Einträge von Queues zu mobilen Mandanten beginnen mit CRM_SITE_ Einträge von Queues für das OLTP-System beginnen mit R3A..., die Anzahl der Queues hängt von der business logic und den Customizing-Einstellungen ab. Das OLTP System sollte immer connected sein (Ausnahme: wenn es wegen eines Backups heruntergefahren wird) Die serialisierten R/3 Adapter-relevanten Queues beginnen alle mit R3AI<object name>, R3AD<object name><key> or R3AR<object name>. Copyright REALTECH 2008 Seite 3 von 7

4 Wenn im OLTP-System viele Updates vorgenommen werden, z. B. Updates von Applikationen, dann werden die Daten über die ausgehende Queue zum CRM- Middleware- System gesendet. Diese Daten werden über qrfc-einstellungen geregelt. qrfc wird von mehreren SAP-Applikationen wie z. B. Advanced Planner und Optimizer (APO), Business Warehouse (BW) und Customer Relationship Management (CRM) für die interne Kommunikation benutzt. Bitte beachten Sie, dass mittels der Transaktion SMQ1, überwachte Outbound-Queues (qrfc Outbound-Queue Monitor) angezeigt werden können, wie z.b.: CRM_Site -> Queue für die Mobile-Clients R3A* -> Queues für das OLTP-System Anzahl der Queue-Einträge Queue-Status (CPICERROR, SYSFAIL,...) Kommunikation zwischen R/3 OLTP-System und CRM-System Die Übertragung der Delta-Informationen laufen vom R/3 OLTP-System zum CRM- Middleware-Server. Wenn die Delta-Informationen den CRM-Middleware-Server erreicht haben, werden die Daten an die Inbound-Queue weitergeleitet. Die Delta-Daten befinden sich in den R3AD* Queues. Die Inbound-Queues sind normalerweise leer oder klein, wenn der CRM-Server genügend Ressourcen hat und kein Fehler auftritt. Hier findet man gestoppte oder hängende Queues, wenn man einen Eintrag markiert und das Brillen-Icon drückt (F7). Wenn man auf die Queues doppelklickt, werden die zugehörigen LUWs angezeigt Auf keinen Fall sollten Queues oder Einträge von Queues gelöscht werden, weil dies zu Unregelmäßigkeiten führen kann. Bitte beachten Sie, dass mittels der Transaktion SMQ2 überwachte Inbound-Queues (qrfc Inbound Queue Monitor), wie z.b.: R3AD* -> Delta-Queues sowie die Anzahl der Queueeinträge verschiedener Queuetypen (Eine große Anzahl von Einträgen kann ein Indiz für eine unzureichende Leistungsfähigkeit des Middleware-Systems sein) als auch der Queue-Status angezeigt werden können. Copyright REALTECH 2008 Seite 4 von 7

5 Scheduler Status SMQR Diese Transaktion führt der Scheduler aus, um die Inbound-Queues auf dem CRM- Middleware-Server zu überprüfen. Stellen Sie sicher, dass der Scheduler aktiv ist. Hier können Sie die Inbound-Queues registrieren oder aus der Registrierung herausnehmen. Sie können alle Inbound-Queues im CRM anhalten, wenn Sie die Queues in der Transaktion SMQR aus der Registrierung herausnehmen. Nur registrierte Queues werden abgearbeitet. Registrierte Queue-Namen beginnen mit R, unregistrierte mit U (R = registriert, U = unregistriert). Solche Einträge muss es in der Transaktion SMQR für die Queues geben, z. B. R3A* für die Delta-Queues. Bitte beachten Sie, dass mittels der Transaktion SMQR die Queue Registrierung angezeigt werden kann, z.b. zur Prüfung: Ob alle Queues registriert sind (Type = R) Des Status des Scheduler u.u. der Anzahl der Einträge pro Queue Überwachung der Replication Queue Zeigt den Status und den Inhalt der Replication-, und Realignment-Queues in den Mandanten an; wird im CRM-Middleware-System definiert. Replication-Queues werden mittels eines Doppelklicks auf die Verkehrsampel - die Ampel wechselt zwischen rot, gelb oder grün. In aller Regel werden die Queues abgearbeitet. Die Funktion SMOH_QUEUEDEMON wird automatisch ausgelöst, wenn Einträge in die Queue erfolgen, um diese abzuarbeiten. Die Zahl neben der Queue ist die Anzahl der sich gerade in der Queue befindlichen Einträge. Wenn Sie auf die Zahl doppelklicken, werden die Einträge der entsprechenden Queue angezeigt. Wird der Queue-Prozess unterbrochen, wird der gegenwärtige Eintrag noch ausgeführt und die Queue danach in den Status Hold versetzt. Dadurch erzeugt der Datenkollektor eine Alarmmeldung. Eine weitere Alarmmeldung erfolgt, wenn der Queue-Demon nicht mehr läuft (Status <> running"). Copyright REALTECH 2008 Seite 5 von 7

6 Bitte beachten Sie, dass mittels der Transaktion SMOHQUEUE der Replication-Queue- Monitor angezeigt werden kann. BDoc Summary SMW01/SMW02 Transaktion SMW01 erlaubt es, die Daten von einem BDoc zu sehen. Mittels Transaktion SMW02 ist es möglich, sich den Bearbeitungsstatus eines einzelnen BDoc von den BDoc- Types selbst anzeigen zu lassen. Suche nach speziellen Fehler-Situationen mittels Bdoc-ID, date, Site ID, message ID... Transaktion SMW01/SMW02 (BDocs im Error Status) Monitoring im OLTP Überwachung der Kommunikation zwischen R/3-OLTP-System und CRM System OLTP -> SMQ1 -> R3D* ->: BAPI-Data, die vom OLTP-System zum Middleware-System übertragen werden. Bitte beachten Sie, dass mittels der Transaktion SMQ1 (Out Queue), z.b.: CRM_Site -> Queue für die Mobile-Clients R3A* -> Queues für das OLTP-System Anzahl der Queue-Einträge Queuestatus (CPICERROR, SYSFAIL, etc.) verschiedener Queues angezeigt werden kann. Copyright REALTECH 2008 Seite 6 von 7

7 Dieser Datenkollektor ist für die folgenden Anwendungen erhältlich: SAP CRM 2.0 Ab Version 2.0 ist die Funktionalität des SAP R/3 Enterprise Datenkollektors im CRM Datenkollektor integriert. Damit bietet der CRM Datenkollektor eine, über die R/3 Überwachung hinausgehende Funktionalität Performance-Daten Performance Statistiken für SAP-Aktivitäten nach Transaktionsgruppen, User Gruppen oder Job Gruppen werden durch einen Zusatz-Datenkollektor (SAP Performance DC) gesammelt. Dieser ist Grundvoraussetzung für die Alarmierung, für das Reporting und die Service-Level-Analyse auf diese Objekte. Details sind im Technical White Paper" über die ABAP-Suite" beschrieben. Der SAP Performance DC ist fester Bestandteil des SAP R/3, SAP R/3 Enterprise, APO, CRM und BW Datenkollektors. Die in dieser Broschüre veröffentlichten Verfügbarkeiten beziehen sich auf die allgemeine Verfügbarkeit eines Produktes, bzw. einer Produktkomponente. Diese Angaben sind unverbindliche Vorraussagen! Knowledge powered by REALTECH Weitere Informationen über REALTECH s Softwareprodukte unter: REALTECH AG Industriestraße 39c Walldorf Germany Tel Fax customer-services@realtech.com Copyright REALTECH 2008 Seite 7 von 7