Anypoint zeigt Ihnen, dass etwas hängt.nJAMS zeigt Ihnen, wo.
Jede Ausführung wird direkt aus dem Mule-Flow erfasst, über alle Applikationen hinweg korreliert und durchsuchbar gemacht. Ohne Log-Parsing, ohne Eingriff in den Anwendungscode.
| Process | Start | Duration |
|---|---|---|
| abgeschlossen: experienceOrderStatusFlow | 08:44:03.117 | 88 ms |
| abgebrochen: systemSapIdocFlow | 08:41:12.812 | 30.0 s |
| abgeschlossen: systemCustomerLookupFlow | 08:41:12.560 | 410 ms |
| abgebrochen, ausgewählt: processOrderToCashFlow | 08:41:12.402 | 30.6 s |
| abgeschlossen: experienceCreateOrderFlow | 08:41:12.318 | 142 ms |
| abgeschlossen: systemPriceLookupFlow | 08:38:41.902 | 96 ms |
| abgeschlossen: processOrderValidationFlow | 08:38:41.774 | 128 ms |
| abgeschlossen: experienceCreateOrderFlow | 08:38:41.690 | 155 ms |
Total events: 2
| Name | Event time | Message | Code |
|---|---|---|---|
| sap-idoc-sender | 08:41:42.917 | Connection timed out after 30000 ms | MULE:CONNECTIVITY |
| processOrderToCashFlow | 08:41:42.918 | Flow execution stopped | MULE:UNKNOWN |
java.util.concurrent.TimeoutException: connect timed out · order-to-cash/processOrderToCashFlow/processors/3
- {
- "message": {
- "payload": {
- "auftragsNr": "WS-2026-004711",
- "kunde": "Muster Industrieteile GmbH",
- "betrag": 12480.00,
- "waehrung": "EUR"
- },
- "attributes": {
- "x-correlation-id": "48fadc50-17b7-11f1-a6a7",
- "method": "POST",
- "requestUri": "/order-to-cash/orders"
- }
- }
- }
- Process name
- processOrderToCashFlow
- Correlation log ID
- 48fadc50-17b7-11f1
- Runtime version
- 4.9.1 - Mule EE
- Payload
- vollständig, replay-fähig
Nachgebaute nJAMS-Oberfläche, Beispieldaten.
From Integration Platform to Business Insights: nJAMS Observability for MuleSoft
Beim Abspielen wird eine Verbindung zu Vimeo aufgebaut, es werden keine Tracking-Cookies gesetzt.
Zwei Ebenen sind abgedeckt. Die dritte entscheidet.
Anypoint Monitoring beantwortet zuverlässig, ob die Infrastruktur läuft. Es beantwortet nicht, welcher Geschäftsprozess klemmt, welche Daten betroffen sind und wer handeln muss.
Was sich im Arbeitsalltag ändert.
Die Ursache steht am Durchlauf, nicht verstreut in Logdateien.
Automatisch erkannte Flows, visuelle Drill-Downs und Volltextsuche über Prozessdaten, statt Log-Korrelation von Hand über mehrere Applikationen hinweg.
- automatische flow-erkennung
- volltextsuche über prozessdaten
- drill-down bis auf schritt-ebene
Abweichungen sehen, bevor jemand anruft.
Ein Regelwerk erkennt fehlende oder verspätete Events früh. Reagieren auf SLA-relevante Ereignisse statt Nachbereitung im Nachhinein.
- regelwerk für fehlende events
- sla-relevante alarme
- frühe abweichungserkennung
Durchgängige Sicht über verteilte Deployments.
Hybride und verteilte Landschaften in einer Sicht, über CloudHub, Runtime Fabric und eigene Server hinweg.
- cloudhub / runtime fabric / on-prem
- eine sicht über alle umgebungen
Payload-Kontext direkt am Flow.
Kein Nachbauen von Fällen. Replay stellt Nachrichten und Batches gezielt nach, mit den Originaldaten aus dem echten Durchlauf.
- payload am schritt
- replay einzelner nachrichten
- keine code-instrumentierung
Reale Durchläufe als Testbasis.
Replay für funktionale Tests, Performance-Tests und Unit-Tests von Integrationsprozessen und ganzen API-Ketten.
- funktionale tests
- performance-tests
- api-ketten end-to-end
Auch das, was nicht passiert ist.
Ein Regelwerk wertet jede einzelne Nachricht aus und meldet, was daraus folgt. Auch das Ausbleiben: der nächtliche Batchlauf, der um halb zwei nicht gestartet ist.
- regelwerk je einzelnachricht
- meldung bei ausbleibenden ereignissen
- automatische flow-erkennung
Weniger Rückfragen an die IT.
Anwender suchen selbst nach Auftrags-Nr., Kundenname oder Konto-Nr. und sehen, ob eine Bestellung vollständig im SAP angekommen ist.
- suche über fachliche felder
- status ohne ticket
- selbstauskunft im fachbereich
Zwei Komponenten, keine Änderung am Anwendungscode.
nJAMS Client
Läuft in der Mule-Applikation und erfasst Transaktionsereignisse direkt aus den Flow-Ausführungen. Zusammenhängende Ausführungen werden automatisch korreliert.
nJAMS Server
Empfängt und persistiert die Ereignisse, korreliert sie über Applikationsgrenzen hinweg und hält sie für die Suche vor. Stellt jeden Einzeldurchlauf im Prozessmodell dar, öffnet Payload und Kontext und erlaubt Replay einzelner Nachrichten und Batches.
läuft auf CloudHub / Runtime Fabric / on-premise / hybrid / Anypoint Studio
Was der Betrieb davon hat.
Weniger blinde Flecken im Prozessverlauf
- automatische flow-erkennung
- volltextsuche über prozessdaten
Geringeres Risiko bei geschäftskritischen Transaktionen
- regelwerk für abweichungen und fehlende events
- reagieren auf sla-relevante ereignisse
Höhere Resilienz der Integrationslandschaft
- meldung bei ausbleibenden ereignissen
- automatische erkennung neuer und geänderter flows
Zwischen Shop und SAP hing ein Auftrag fest.Drei Abteilungen suchten, wo.
Ein international tätiger Konzern betreibt sein Geschäft über MuleSoft als zentrale Integrationsschicht. Die Plattform bewegte die Daten zuverlässig. Die Frage war nur, was passiert, wenn sie es einmal nicht tut.
Vorher
- Logdaten verteilt über CloudHub und eigene Server
- Ob eine Bestellung im SAP ankam, war nicht in einem Schritt zu beantworten
- Fehler fielen auf, wenn ein Anwender anrief
Seitdem
- Ein Prozessbild über alle Mule-Flows hinweg
- Der Schritt, an dem es bricht, ist markiert
- Der Payload, der die Ablehnung auslöst, liegt daneben
Angebundene Systeme im beschriebenen Fall
- integration
- MuleSoft
- erp
- SAP
- crm
- Microsoft Dynamics 365
- vorn
- Shop
- stammdaten
- MDM
- lager
- WMS
Ein Modell kennt Ihre Architektur.Nicht den Auftrag, der gestern hängen blieb.
Schemata, Flow-Definitionen, Code — das beschreibt, wie Ihre Integration gebaut ist. Nicht, was durch sie hindurchgelaufen ist. Diese Daten fallen nirgends an: Logdateien halten Zeilen fest, keine Durchläufe. nJAMS legt sie an.
- Es gibt keine zweite Quelle. Ohne nJAMS existiert dieser Bestand nicht.
- Was zusammengehört, ist verbunden. Über Applikationen, Cloud und eigene Server hinweg.
- Jeder Schritt trägt seine Geschäftsdaten. Auftragsnummer, Kunde, Betrag. Nicht nur Zeitstempel.
Was ein Modell daraus macht, ist die zweite Frage. Die Daten sind die erste.
Eine Sicht über alle Mule-Deployments.
Client innerhalb der Mule-Applikation, alle Deployment-Modelle, automatische Flow-Erkennung, Replay auf Nachrichten- und Batch-Ebene.
- cloudhub
- runtime fabric
- on-prem
- hybrid
Wie aufwändig ist die Einführung?
Zweiteilig, und der zweite Teil wird leicht übersehen. Der Client wird in der Mule-Applikation konfiguriert, ohne Änderung am Anwendungscode. Der Server wird installiert oder in Containern ausgerollt — das ist ein eigener Schritt und braucht eine Umgebung dafür.
Wie wird nJAMS dimensioniert?
Der Sizing-Aufwand hängt von Prozessvolumen, Teamanzahl und Deployment-Topologie ab. Das klärt sich in einem Scoping-Gespräch, nicht über eine pauschale Angabe.
Wer steht hinter nJAMS?
Salesfive, Salesforce- und MuleSoft-Partner.
Beyond the Black Box: Unlocking 100% Visibility in MuleSoft with nJAMS
Je größer eine MuleSoft-Landschaft wird, desto schwerer wird die Frage zu beantworten, wo genau ein Geschäftsprozess hängt und welche Daten betroffen sind. Das Whitepaper von Salesfive beschreibt, wo Standardwerkzeuge diese Grenze erreichen, und zeigt an einer anonymisierten Fallstudie, was sich ändert, wenn Durchläufe samt Payload erfasst werden.
- Die Sichtbarkeitsgrenze in MuleSoft
- Erfassung von Prozessschritten und Payloads
- Replay für Entwicklung und Test
- Anonymisierte Fallstudie, hybride Landschaft
Zeigen Sie uns Ihre Landschaft. Wir zeigen Ihnen die blinden Flecken.
Ein Gespräch reicht, um einzuordnen, ob nJAMS für Ihre Mule-Landschaft etwas verändert. Alles Weitere entscheiden Sie danach.