DE112021005378T5

DE112021005378T5 - Selbstbedienungsintegration und testen von merkmalen

Info

Publication number: DE112021005378T5
Application number: DE112021005378.7T
Authority: DE
Inventors: Ankur Anand; Vikash Kumar Jain; Ayush Kumar; Satya S. Mishra; Oloyede Olumide; Naga Bhimanadha Swamy Kalanadhabhatla; Neha Goswami
Original assignee: Amazon Technologies Inc
Current assignee: Amazon Technologies Inc
Priority date: 2020-10-12
Filing date: 2021-10-08
Publication date: 2023-09-07
Also published as: GB2614198A; US11449415B2; WO2022081437A1; GB202304875D0; US20220114082A1

Abstract

Es werden verschiedene Ausführungsformen für Selbstbedienungsintegration und Testen von Merkmalen offenbart. In einer Ausführungsform empfängt ein Testmodusdienst eine Anforderung zum Testen einer Integration eines Drittanbietersystems mit einem Produktionssystem. Der Testmodusdienst aktiviert mindestens ein Plugin, um mindestens eine Funktion des Produktionssystems zu testen. Der Testmodusdienst führt mindestens eine Funktion unter Verwendung des/der Plugin(s) und Daten aus, die durch die Integration des Drittanbietersystems bereitgestellt werden. Der Testmodusdienst meldet dann ein Ergebnis darüber, wie das Produktionssystem die Funktion(en) ausführt, die dem/den Plugin(s) zugeordnet sind, unter Verwendung der Testdaten.

Description

QUERVERWEIS AUF VERWANDTE ANMELDUNGEN
Diese Anmeldung beansprucht den Vorteil und die Priorität der US-Patentanmeldung mit dem Titel „SELF-SERVICE INTEGRATION AND FEATURE TESTING“, eingereicht am 9. November 2020 mit der zugeteilten Anmeldenummer 17/093,565 , die den Vorteil und die Priorität der vorläufigen US-Patentanmeldung mit dem Titel „SELF-SERVICE INTEGRATION AND FEATURE TESTING“, eingereicht am 12. Oktober 2020 mit der zugeteilten Anmeldenummer 63/090,618 , beansprucht, die hierin durch Bezugnahme in ihrer Gesamtheit aufgenommen werden.
STAND DER TECHNIK
Mit der Verbreitung von miteinander verbundenen Rechensystemen kommt es oft vor, dass eine erste Entität ihre Systeme in die einer zweiten Entität integrieren muss. In einem Beispiel ist die zweite Entität ein E-Commerce-Anbieter und die erste Entität ist ein Betrieb, der versucht, Artikel über den E-Commerce-Anbieter unter Verwendung seiner Einkaufssysteme zu bestellen. Die zweite Entität veröffentlicht typischerweise eine Dokumentation für ihre Anwendungsprogrammierschnittstelle (API), in der die verschiedenen von ihr unterstützten API-Aufrufe aufgeführt sind, einschließlich Funktionalität, Parameter und Rückgabewerte. In einigen Fällen veröffentlicht die zweite Entität Spezifikationen für Beschaffungs-PunchOut, wie etwa Commerce Extensible Markup Language (cXML) oder Electronic Data Interchange (EDI). In einigen Fällen veröffentlicht die zweite Entität eine Dokumentation für ein Datenaustauschformat, das dazu verwendet wird, Befehle zur Massenverarbeitung an die zweite Entität hochzuladen. Wie bei jedem kundenspezifischen Softwaresystem treten häufig Codierungs- oder Konfigurationsfehler auf, zu denen einfache Tippfehler oder in einigen Fällen Missverständnisse in Bezug auf die Funktionsweise von Merkmalen gehören. Testen ist wichtig, um diese Fehler zu entdecken und zu bestätigen, dass bestimmte Merkmale wie beabsichtigt funktionieren.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Viele Aspekte der vorliegenden Offenbarung sind unter Bezugnahme auf die folgenden Zeichnungen besser verständlich. Die Komponenten in den Zeichnungen sind nicht unbedingt maßstabsgetreu dargestellt, der Schwerpunkt liegt vielmehr darauf, die Prinzipien der Offenbarung klar zu veranschaulichen. Überdies sind in den Zeichnungen entsprechende Teile in den verschiedenen Ansichten durch gleiche Bezugszeichen gekennzeichnet.

1A ist eine Zeichnung einer beispielhaften Benutzerschnittstelle, welche die Verwaltung eines Testmodusdienstes und die Auswahl von Testszenarien gemäß verschiedenen Ausführungsformen der vorliegenden Offenbarung erleichtert.
1 B ist eine Zeichnung einer beispielhaften Benutzerschnittstelle zum Einsehen von Informationen über verschiedene Testszenarien, die gemäß verschiedenen Ausführungsformen der vorliegenden Offenbarung ausgeführt wurden.
2 ist ein schematisches Blockdiagramm einer vernetzten Umgebung gemäß verschiedenen Ausführungsformen der vorliegenden Offenbarung.
3A ist ein Flussdiagramm, das ein Beispiel einer Funktionalität veranschaulicht, die als Teile eines Testmodusdienstes umgesetzt ist, der in einer Rechenumgebung in der vernetzten Umgebung von 2 ausgeführt wird, gemäß verschiedenen Ausführungsformen der vorliegenden Offenbarung.
3B ist ein Sequenzdiagramm, das ein Beispiel einer Interaktion zwischen verschiedenen Komponenten veranschaulicht, die in einer Rechenumgebung in der vernetzten Umgebung von 2 ausgeführt werden, gemäß verschiedenen Ausführungsformen der vorliegenden Offenbarung.
4 ist ein schematisches Blockdiagramm, das eine beispielhafte Veranschaulichung einer Rechenumgebung bereitstellt, die in der vernetzten Umgebung von 2 verwendet wird, gemäß verschiedenen Ausführungsformen der vorliegenden Offenbarung.

DETAILLIERTE BESCHREIBUNG
Die vorliegende Offenbarung betrifft Integration und Testen von Merkmalen. Beim Entwickeln einer Integration zwischen einem ersten System, das durch eine erste Entität betrieben wird, und einem zweiten System, das durch eine zweite Entität betrieben wird, ist Testen wichtig, um Codierungs- oder Konfigurationsfehler aufzudecken. Zu solchen Fehlern in verschiedenen Szenarien gehören beispielsweise einfache Tippfehler, Missverständnisse darüber, wie Merkmale funktionieren, und Fehler bei der Berücksichtigung von Grenzfällen. Während einige Fehler zur Kompilierzeit oder durch manuelle Überprüfung erkennbar sind, sind andere Fehler nur zur Laufzeit erkennbar. Insofern ist gründliches Testen entscheidend, um Fehler vor dem Produktionseinsatz zu entdecken.
Leider ist das Testen oft schwierig und nicht ausreichend. Zur Integration in ein Live-Produktionssystem gehört normalerweise das Einrichten eines Testsystems, das die Funktionalität des Produktionssystems repliziert, um die Integration zu testen. Das Einrichten des Testsystems ist in einigen Fällen mit großem Aufwand verbunden, um das Produktionssystem manuell zu replizieren, und beansprucht Zuweisungen von Rechenressourcen, die andernfalls für den produktiven Einsatz verwendet werden könnten. In einigen Ausführungsformen befindet sich das Testsystem in einer Sandbox-Umgebung, um Auswirkungen auf das Produktionssystem zu vermeiden. In einigen Szenarien kann das Testsystem das Produktionssystem nicht vollständig replizieren, was dazu führt, dass echte Fehler in der Integration oder den Merkmalen nicht erkannt werden oder Fehler fälschlicherweise erkannt werden, wenn sie nicht vorhanden sind. Ferner muss in einigen Szenarien der Code, der die Integration umsetzt, nach dem Testen aktualisiert werden, um auf das Produktionssystem statt auf das Testsystem zu verweisen, was eine weitere potenzielle Fehlerquelle darstellt.
Verschiedene Ausführungsformen der vorliegenden Offenbarung führen eine Architektur ein, um ein Produktionssystem zu modifizieren, um Selbstbedienung oder unterstützte Integration und Testen von Merkmalen zu erleichtern, ohne dass ein separates Testsystem oder eine Sandbox-Umgebung erforderlich ist, die das Produktionssystem repliziert, obwohl der Drittanbieter in einigen Fällen ein Test- oder Sandbox-System hat. Der Integrationscode ist dazu konfiguriert, mit dem endgültigen Produktionssystem zu kommunizieren, und ein oder mehrere Flags, die entweder den Test- oder den Produktionsbetrieb von Teilen des Produktionssystems konfigurieren, werden im Produktionssystem konfiguriert. Wenn das Testen aktiviert ist, werden unerwünschte Nebenwirkungen im Zusammenhang mit der Nutzung von Merkmalen des Produktionssystems deaktiviert. Im Fall von Bestellungsbearbeitungs- und - erfüllungssystemen eines E-Commerce-Anbieters sollte das Testen einer Bestellungsaufgabeintegration viele reale Szenarien mit Systemen und Teilsystemen umfassen, deren unterschiedliche Reaktionen das Ergebnis beeinflussen könnten. Beim Testen einer Bestellungsaufgabeintegration sollte das Aufgeben einer Testbestellung jedoch nicht dazu führen, dass ein Zahlungsmittel tatsächlich belastet wird, und sollte nicht dazu führen, dass eine Lieferung tatsächlich erfüllt wird.
1A zeigt eine beispielhafte Benutzerschnittstelle 100, welche die Verwaltung eines Testmodusdienstes und die Auswahl von Testszenarien erleichtert, wie beschrieben wird. Die verschiedenen in der Benutzerschnittstelle 100 beschriebenen Komponenten entsprechen in einigen Umsetzungen Schaltflächen, Schiebereglern, Optionsfeldern, Hyperlinks und/oder anderen Eingabekomponenten der Benutzerschnittstelle. Ein Statusindikator 103 zeigt an, dass sich das Produktionssystem derzeit in einem Testmodus für den Kunden befindet. Die Komponenten 106 und 109 ermöglichen das Umschalten zwischen dem Testmodus, in dem Bestellungen nicht tatsächlich in Rechnung gestellt, erfüllt und versendet werden, und einem aktiven Modus, in dem Bestellungen tatsächlich in Rechnung gestellt, erfüllt und versendet werden.
Mehrere mögliche Testszenarien 112 werden zur Benutzerauswahl präsentiert. Szenario 112a entspricht einem einfachen Bestelltest. In einem Beispiel werden beim einfachen Bestelltest die Daten des übermittelten Warenkorbs, der erhaltenen Bestellung und der Versandbestätigung validiert. Im Szenario 112a wird der Benutzer angewiesen, einen Artikelkatalog eines E-Commerce-Anbieters unter Verwendung der Integration des Einkaufssystems des Benutzers zu durchsuchen, Artikel zu einem Einkaufswagen oder -korb hinzuzufügen und dann die Bestellung durch das Einkaufssystem zu genehmigen. Danach überprüft der Benutzer die Testprotokolle, um das Ergebnis des Tests zu beobachten. In dem Szenario 112a bewirkt eine Komponente 115a, dass das Szenario 112a ausgeführt wird, und eine Komponente 118a bewirkt, dass die Testprotokolle in der Benutzerschnittstelle 100 präsentiert oder heruntergeladen werden. Ein Testergebnisindikator 121a zeigt an, ob das Szenario 112a als erfolgreich markiert wurde.
Die Szenarien 112b-112e in diesem Beispiel entsprechen verschiedenen Bestellschutztests, wobei jedes der jeweiligen Szenarien 112 einen bestimmten Einzelposten in der Bestellung manipuliert, sodass der Benutzer sehen kann, wie das Problem durch die Integration des Einkaufssystems gehandhabt wird. Zum Beispiel beinhaltet Szenario 112b eine Mengenänderung, die durch das Bestellungsbearbeitungs- und -erfüllungssystem umgesetzt wird. In diesem Beispiel ändert sich die Menge des Artikels auf weniger als die in der Testbestellung angegebene, und eine Bestellschutzeinstellung ist so konfiguriert, dass als Folge der Artikel abgelehnt wird. In dem Szenario 112b, wie in den anderen Szenarien 112b-112e, bewirkt eine Komponente 115b, dass das Szenario 112b ausgeführt wird, eine Komponente 118b, dass die Testprotokolle präsentiert werden, und ein Testergebnisindikator 121b zeigt, dass der Test noch nicht als erfolgreich markiert wurde.
Szenario 112c entspricht einer zu späten Artikellieferung. In diesem Beispiel legt das Bestellungsbearbeitungs- und -erfüllungssystem einen Zeitrahmen für die Lieferung von Artikeln fest, der dazu konfiguriert ist, eine Bestellschutzeinstellung zu überschreiten, die für die Integration des Einkaufssystems konfiguriert ist. Beispielsweise konfiguriert die Bestellschutzeinstellung eine maximale Lieferzeit von vier Tagen und die simulierte Artikellieferzeit beträgt fünf Tage.
Szenario 112d entspricht einer Artikelpreisänderung. In diesem Beispiel erhöht sich der Stückpreis des Artikels vom Zeitpunkt des Hinzufügens des Artikels zum Einkaufswagen bis zum Übermitteln der Bestellung, und die für die Integration des Einkaufssystems konfigurierte Bestellschutzeinstellung ist so konfiguriert, dass der Artikel infolgedessen abgelehnt wird. Zum Beispiel konfiguriert das Szenario 112d eine Änderung eines Artikelpreises von 5,99 $ auf 6,15 $, und die Bestellschutzeinstellung lehnt jede Artikelpreiserhöhung ab.
Szenario 112e entspricht zu hohen Versandkosten. In diesem Beispiel fallen für einen Artikel Versandkosten an, die eine Bestellschutzeinstellung überschreiten, die für die Integration des Einkaufssystems konfiguriert wurde. Zum Beispiel konfiguriert das Szenario 112e eine Änderung der Versandkosten von 10 $ auf 21 $, und die Bestellschutzeinstellung lehnt alle Versandkosten über 20 $ ab.
In anderen Beispielen beinhalten die Szenarien 112 eines oder mehrere von einem Szenario 112, das eine Rechnung mit Versandkosten in der Zusammenfassung testet, einem Szenario 112, das eine Rechnung mit einem Sonderabwicklungsbetrag in der Zusammenfassung testet, einem Szenario 112, das eine Rechnung mit einem Rabattbetrag in der Zusammenfassung testet, einem Szenario 112, das eine Rechnung mit Versandkosten und einem Rabatt in der Zusammenfassung testet, einem Szenario 112, das eine Rechnung mit Sonderabwicklungsgebühren und einem Rabatt in der Zusammenfassung testet, einem Szenario 112, das eine Rechnung mit Steuern, Versandkosten, Sonderabwicklungsgebühren und Rabatt in der Zusammenfassung, eine Gutschrift mit mehreren Zeilen mit Steuern, Versand, Sonderabwicklungsgebühren und Rabatt in der Zusammenfassung testet, und/oder andere Szenarien 112.
1B zeigt eine beispielhafte Benutzerschnittstelle 130 zum Einsehen von Informationen über verschiedene Testszenarien 112 (1B), die ausgeführt wurden. Die Informationen in diesem Beispiel beinhalten eine Bestellkennung, eine Szenariokennung, eine Zeit/ein Datum, wann die Bestellung eingegangen ist, und ein Testergebnis. Zusätzliche Informationen werden in anderen Beispielen präsentiert, wie etwa detaillierte Informationen darüber, welche Datenergebnisse von bestimmten Komponenten des Produktionssystems im Testmodus ausgegeben wurden. In anderen Beispielen werden Benutzerschnittstellenkomponenten gezeigt, um das Suchen nach Testbestellungen nach Schlüsselwort, Empfangsdatum, Szenariotyp, Ergebnis und/oder anderen Kriterien zu ermöglichen. In einem anderen Beispiel zeigt die Benutzerschnittstelle 130 Informationen über Shopping-Sessions, für die keine Bestellung empfangen wurde, und/oder Shopping-Sessions, die aus anderen Gründen fehlgeschlagen sind.
Wie für den Fachmann angesichts dieser Offenbarung ersichtlich ist, können bestimmte Ausführungsformen in der Lage sein, bestimmte Vorteile zu erzielen, einschließlich einiger oder aller der folgenden: (1) Reduzieren des Ressourcenverbrauchs von Computersystemen (z. B. in Bezug auf Prozessorzeit und Speicherauslastung) durch Eliminieren eines separaten Testsystems in einer Sandbox, das die Funktionalität eines Produktionssystems repliziert; (2) Reduzieren von Codierungsfehlern und Inkonsistenzen, die durch Erstellen einer Kopie eines Produktionssystems zu Testzwecken eingeführt werden; (3) effektiveres Gestalten des Testprozesses für eine Integration durch Verwenden des tatsächlichen Produktionssystems; (4) Reduzieren von Fehlern, die dadurch entstehen, dass eine Integration von einem Testsystem auf ein Produktionssystem umgeleitet werden muss; (5) Verbessern der Flexibilität der Testarchitektur durch Erstellen von Plugins, die auf spezifische Testszenarien und Komponenten des Produktionssystems zugeschnitten sind; (6) Verbessern des Benutzererlebnisses, indem das Testen zur Selbstbedienung gemacht wird, ohne dass ein Verwalter des Produktionssystems manuell eingreifen muss; und so weiter. In der folgenden Erörterung ist eine allgemeine Beschreibung des Systems und seiner Komponenten bereitgestellt, gefolgt von einer Erörterung des Betriebs desselben.
2 veranschaulicht eine vernetzte Umgebung 200 gemäß verschiedenen Ausführungsformen. Die vernetzte Umgebung 200 beinhaltet eine Rechenumgebung 203, eine Rechenumgebung 206 eines Drittanbieters und eine oder mehrere Client-Vorrichtungen 209, die über ein Netzwerk 212 in Datenkommunikation miteinander stehen. Das Netzwerk 212 beinhaltet beispielsweise das Internet, Intranets, Extranets, Wide Area Networks (WANs), Local Area Networks (LANs), verdrahtete Netzwerke, drahtlose Netzwerke, Kabelnetzwerke, Satellitennetzwerke oder andere geeignete Netzwerke usw. oder eine Kombination aus zwei oder mehreren solchen Netzwerken.
Bei einer oder mehreren Ausführungsformen umfasst die Rechenumgebung 203 beispielsweise einen Servercomputer oder ein anderes System, das Rechenleistung bereitstellt. Alternativ verwendet die Rechenumgebung 203 in einer oder mehreren Ausführungsformen eine Vielzahl von Rechenvorrichtungen, die beispielsweise in einer oder mehreren Serverbänken oder Computerbänken oder anderen Anordnungen angeordnet sein kann. Solche Rechenvorrichtungen befinden sich in einigen Beispielen in einer einzigen Installation oder sind auf viele verschiedene geografische Standorte verteilt. Beispielsweise beinhaltet die Rechenumgebung 203 eine Vielzahl von Rechenvorrichtungen, die zusammen eine gehostete Rechenressource, eine Grid-Rechenressource und/oder eine andere verteilte Rechenanordnung umfassen kann. In einigen Fällen entspricht die Rechenumgebung 203 einer elastischen Rechenressource, bei der die zugewiesene Verarbeitungskapazität, das Netzwerk, die Speicherung oder andere Rechenressourcen im Laufe der Zeit variieren können.
Verschiedene Anwendungen und/oder andere Funktionalitäten werden in der Rechenumgebung 203 gemäß verschiedenen Ausführungsformen ausgeführt. Außerdem werden verschiedene Daten in einem Datenspeicher 215 gespeichert, auf den die Rechenumgebung 203 zugreifen kann. Der Datenspeicher 215 ist in einigen Fällen repräsentativ für eine Vielzahl von Datenspeichern 215, wie ersichtlich ist. Die im Datenspeicher 215 gespeicherten Daten sind beispielsweise dem Betrieb der verschiedenen nachstehend beschriebenen Anwendungen und/oder funktionalen Einheiten zugeordnet.
Die auf der Rechenumgebung 203 ausgeführten Komponenten beinhalten beispielsweise ein Produktionssystem 218, ein oder mehrere Test-Plugins 221, einen Testmodusdienst 224, eine Produktionssystemschnittstelle 227 und/oder andere Komponenten. Das Produktionssystem 218 wird ausgeführt, um einen Live-Produktionsdienst im Auftrag des Betreibers der Rechenumgebung 203 bereitzustellen. In einer Ausführungsform ist das Produktionssystem 218 ein System zur Aufgabe, Bearbeitung und Erfüllung von Bestellungen, das von einem E-Commerce-Anbieter betrieben wird. Das Produktionssystem 218 beinhaltet eine Vielzahl von Komponenten 230, bei der es sich um Systeme und Teilsysteme handelt, die betrieben werden, um den/die Dienst(e) des Produktionssystems 218 bereitzustellen. Die Komponenten 230 sind in einigen Beispielen in einer Pipeline angeordnet, um von Drittanbietern bereitgestellte Daten, wie etwa Bestellungen, zu verarbeiten. Die Komponenten 230 setzen bei Ausführung in einigen Situationen normalerweise eine nicht umkehrbare Zustandsänderung um.
In einer Ausführungsform beinhalten die Komponenten 230 einen oder mehrere von einem Bestellungsaufgabedienst, der den Empfang, die Aufgabe und die Bestätigung von Bestellungen erleichtert; einen Zahlungsbearbeitungsdienst zum Belasten von Zahlungsmitteln wie Bankkonten, Belastungskonten, Zahlungskarten, Geschenkkarten und so weiter; einen Warenbestandsdienst, der eine virtuelle Darstellung des Warenbestands in einem oder mehreren Erfüllungszentren unterhält und die Reservierung von Warenbestand zur Erfüllung von Bestellungen erleichtert; einen Versandplanungsdienst, der den Warenbestand in einem oder mehreren Erfüllungszentren optimal auswählt; einen Erfüllungsdienst, der die Auswahl, die Verpackung und den Versand von Bestellungen in einem oder mehreren Erfüllungszentren koordiniert; einen Speditionsdienst, der den Transport von Sendungen über einen oder mehrere Spediteure koordiniert; einen Last-Mile-Lieferdienst, der die Lieferung von Sendungen an die Bestimmungsorte koordiniert; und/oder andere Komponenten 230.
Die Test-Plugins 221 sind einzelne Plugins, die Merkmale von Testszenarien 233 in Bezug auf die Komponenten 230 des Produktionssystems 218 umsetzen. Insbesondere wenn ein Testmodus aktiviert ist, kommuniziert ein entsprechendes Test-Plugin 221 mit einer oder mehreren Komponenten 230 des Produktionssystems 218, um Aktionen zu deaktivieren, die zu einer nicht umkehrbaren Zustandsänderung führen, oder um Zustandsänderungen, die der Verarbeitung von Testdaten wie etwa Bestellungen zugeordnet sind, umzukehren. In einigen Fällen blockiert, verhindert oder ersetzt ein jeweiliges Test-Plugin 221 die Ausführung einer oder mehrerer Komponenten 230 des Produktionssystems 218, sodass das jeweilige Test-Plugin 221 in der Lage ist, die Ausführung der Komponenten 230 durch simulierte oder Dummy-Daten zu ersetzen. In einer Ausführungsform ist ein erstes Test-Plugin 221 ein Zahlungs-Plugin, das ermöglicht, eine Testbestellung unter Verwendung eines Testmodus-Zahlungsmittels aufzugeben, ist ein zweites Test-Plugin 221 ein Bestell-Plugin, das ein Kaufdokument in dem Datenspeicher 215 mindestens teilweise auf Grundlage einer durch ein Kundensystem übermittelten Testbestellung erstellt, ist ein drittes Test-Plugin 221 ein Warenbestands-Plugin, das ermöglicht, eine Testbestellung aufzugeben, indem Echtzeit-Warenbestand von einer Warenbestandskomponente 230 des Produktionssystems 218 abgerufen, der Warenbestand reserviert und ein Kaufdokument erstellt wird.
Der Testmodusdienst 224 wird ausgeführt, um die Testmodusfunktionalität für eine Integration 236 eines Drittanbietersystems 239 in das Produktionssystem 218 zu aktivieren. Dies ermöglicht ein Selbstbedienungstesten der Integration 236 ohne manuellen Eingriff durch den Bediener des Produktionssystems 218. Beispielsweise führt der Testmodusdienst 224 Testbestellungen im Produktionssystem 218 aus und übermittelt die Ergebnisse (z. B. Bestellbestätigungen, Versandbenachrichtigungen, Rechnungen) zurück an Einkaufs- oder Beschaffungssysteme. In einer Ausführungsform beinhaltet der Testmodusdienst 224 einen Testmodusszenario-Ausführungsdienst 242, einen Testmodus-Plugin-Orchestrierer 245 und einen Testmodus-Verwaltungsdienst 248. Der Testmodusdienst 224 beinhaltet in anderen Ausführungsformen andere konstituierende Komponenten. Der Testmodusszenario-Ausführungsdienst 242 ist für das Einstellen und Ausführen eines durch ein Testszenario 233 festgelegten Arbeitsablaufs verantwortlich. Der Testmodus-Plugin-Orchestrierer 245 ist eine technische Schicht, die eine Teilmenge der Test-Plugins 221 nach Bedarf für ein Testszenario 233 aufruft, mindestens teilweise auf Grundlage einer Eingabe von dem Testmodus-Szenario-Ausführungsdienst 242. Der Testmodus-Verwaltungsdienst 248 generiert Benutzerschnittstellen wie etwa die Benutzerschnittstelle 100 (1 B), welche die Steuerung des Testmodus und die Auswahl von Testszenarien 233 erleichtern, und die Benutzerschnittstelle 130 (1 B), die Protokolle präsentiert, die Ergebnisse der Ausführung von Testszenarien 233 zeigt.
Die Produktionssystemschnittstelle 227 ist ein Gateway, um von Drittanbietern bereitgestellte Daten 251, wie etwa Bestellungen, zur Verarbeitung durch das Produktionssystem 218 zu übermitteln. Beispielsweise unterstützt die Produktionssystemschnittstelle 227 eine Anwendungsprogrammierschnittstelle (API) zur Kommunikation zwischen einem Drittanbietersystem 239 und dem Produktionssystem 218. In einigen Ausführungsformen verwendet die Produktionssystemschnittstelle 227 eine Commerce Extensible Markup Language (Commerce XML), Open Buying on the Internet (OBI), Electronic Data Interchange (EDI) und/oder andere Frameworks. In einigen Ausführungsformen erleichtert die Produktionssystemschnittstelle 227 das Durchsuchen eines vom Produktionssystem 218 gehosteten Artikelkatalogs, um Artikel für einen Einkaufswagen oder -korb auszuwählen, die als Grundlage für eine Bestellung dienen.
Die im Datenspeicher 215 gespeicherten Daten beinhalten beispielsweise ein oder mehrere Testszenarien 233, ein oder mehrere Testprotokolle 254, von Drittanbietern bereitgestellte Daten 251, Produktionssystemdaten 257, Testmodus-Konfigurationsdaten 260 und möglicherweise andere Daten. Die Testszenarien 233 testen einzeln bestimmte Merkmale einer Integration 236 in das Produktionssystem 218. Zu diesen Merkmalen gehören beispielsweise Aufgeben einer Testbestellung, Abwickeln einer Mengenänderung in einer Bestellung, Abwickeln einer Artikellieferung, die über einen Schwellenwert hinaus verspätet ist, Abwickeln einer Preisänderung, nachdem ein Artikel in einen Einkaufswagen gelegt, aber bevor eine Bestellung aufgegeben wurde, Abwickeln von Versandkosten, die einen Schwellenwert überschreiten, und andere Merkmale.
Die Testprotokolle 254 zeichnen Informationen bezüglich der Ausführung von Testszenarien 233 durch den Testmodusdienst 224 auf, ähnlich zu denen, die in der Benutzerschnittstelle 130 gezeigt sind. Die von Drittanbietern bereitgestellten Daten 251 entsprechen den Daten, die von der Integration 236 in das Drittanbietersystem 239 bereitgestellt werden. In einem Fall entsprechen die von Drittanbietern bereitgestellten Daten 251 einer Bestellung, die von einem elektronischen Beschaffungs- oder Einkaufssystem generiert wurde.
Die Produktionssystemdaten 257 entsprechen verschiedenen Datenobjekten, die von einem Produktionssystem 218 verwendet werden. In einem Beispiel beinhalten die Produktionssystemdaten 257 ein Kaufdokument oder eine Darstellung einer Bestellung für den E-Commerce-Anbieter. Die Testmodus-Konfigurationsdaten 260 beinhalten einen oder mehrere Parameter, welche die Ausführung des Testmodusdienstes 224 steuern. Beispielsweise beinhalten die Testmodus-Konfigurationsdaten 260 eine Testmoduseinstellung, die den Testmodus auf einer Pro-Kunde- oder Pro-Konto-Basis aktiviert oder deaktiviert. Die Testmodus-Konfigurationsdaten 260 beinhalten in einigen Ausführungsformen simulierte Daten oder Dummy-Daten, die durch ein oder mehrere Test-Plugins 221 verwendet werden, um beim Ausführen eines Tests durch Umgehen von Komponenten 230 zu helfen, die eine nicht umkehrbare Zustandsänderung bewirken würden.
Bei einer oder mehreren Ausführungsformen beinhaltet die Drittanbieter-Rechenumgebung 206 beispielsweise einen Servercomputer oder ein anderes System, das Rechenleistung bereitstellt. Alternativ verwendet die Drittanbieter-Rechenumgebung 206 in einer oder mehreren Ausführungsformen eine Vielzahl von Rechenvorrichtungen, die beispielsweise in einer oder mehreren Serverbänken oder Computerbänken oder anderen Anordnungen angeordnet sein kann. Solche Rechenvorrichtungen befinden sich in einigen Beispielen in einer einzigen Installation oder sind auf viele verschiedene geografische Standorte verteilt. Beispielsweise beinhaltet die Drittanbieter-Rechenumgebung 206 eine Vielzahl von Rechenvorrichtungen, die zusammen eine gehostete Rechenressource, eine Grid-Rechenressource und/oder eine andere verteilte Rechenanordnung umfassen kann. In einigen Fällen entspricht die Drittanbieter-Rechenumgebung 206 einer elastischen Rechenressource, bei der die zugewiesene Verarbeitungskapazität, das Netzwerk, die Speicherung oder andere Rechenressourcen im Laufe der Zeit variieren können.
Verschiedene Anwendungen und/oder andere Funktionalitäten werden in der Drittanbieter-Rechenumgebung 206 gemäß verschiedenen Ausführungsformen ausgeführt. Außerdem werden verschiedene Daten in einem Datenspeicher gespeichert, auf den die Drittanbieter-Rechenumgebung 206 zugreifen kann. Die auf der Datenverarbeitungsumgebung 206 eines Drittanbieters ausgeführten Komponenten umfassen beispielsweise ein System eines Drittanbieters 239, eine Integration 236 und andere Komponenten.
Das Drittanbietersystem 239 ist ein System, das von einem Drittanbieter betrieben wird, der sich von dem Betreiber des Produktionssystems 218 unterscheidet. In einigen Beispielen ist der Drittanbieter ein Kunde des Betreibers des Produktionssystems 218 und hat ein Konto bei diesem. Das Drittanbietersystem 239 kommuniziert mit dem Produktionssystem 218, um eine Funktion auszuführen. In einigen Beispielen ist das Drittanbietersystem 239 ein elektronisches Beschaffungssystem oder ein Einkaufssystem des Drittanbieters. Die Integration 236 entspricht Code oder Einstellungen, die eine Kommunikation zwischen dem Drittanbietersystem 239 und der Produktionssystemschnittstelle 227 ermöglichen. In einem Beispiel konfiguriert die Integration 236 das Drittanbietersystem 239, um bestimmte API-Aufrufe durchzuführen oder Dokumente in einem bestimmten Format zu generieren, die durch die Produktionssystemschnittstelle 227 zu importieren sind. Die Integration 236 wird in einigen Fällen kundenspezifisch für den Drittanbieter entwickelt.
Die Client-Vorrichtung 209 ist repräsentativ für eine Vielzahl von Client-Vorrichtungen, die an das Netzwerk 212 gekoppelt sein kann. Die Client-Vorrichtung 209 kann beispielsweise ein prozessorbasiertes System wie etwa ein Computersystem umfassen. Ein solches Computersystem kann in Form eines Desktop-Computers, eines Laptop-Computers, eines Personal Digital Assistant, eines Mobiltelefons, eines Smartphones, einer Set-Top-Box, eines Musikplayers, eines Webpads, eines Tablet-Computersystems, einer Spielekonsole, eines Lesegeräts für elektronische Bücher, einer Smartwatch, eines Head-Mounted-Displays, einer Sprachschnittstellenvorrichtung oder anderer Vorrichtungen verkörpert sein. Die Client-Vorrichtung 209 kann eine jeweilige Anzeige 263 beinhalten. Die Anzeige 263 kann beispielsweise eine oder mehrere Vorrichtungen umfassen, wie etwa Flüssigkristallanzeigen (LCD), Flachbildschirme auf Gasplasmabasis, Anzeigen mit organischen Leuchtdioden (OLED), Anzeigen mit elektrophoretischer Tinte (E-Tinte), LCD-Projektoren oder andere Arten von Anzeigevorrichtungen usw.
Die Client-Vorrichtung 209 kann dazu konfiguriert sein, verschiedene Anwendungen wie etwa eine Client-Anwendung 266 und/oder andere Anwendungen auszuführen. Die Client-Anwendung 266 kann beispielsweise in einer Client-Vorrichtung 209 ausgeführt werden, um auf Netzwerkinhalte zuzugreifen, die durch die Rechenumgebung 203 und/oder andere Server bereitgestellt werden, wodurch eine Benutzerschnittstelle 269 auf der Anzeige 263wiedergegeben wird. Zu diesem Zweck kann die Client-Anwendung 266 beispielsweise einen Browser, eine dedizierte Anwendung usw. umfassen, und die Benutzerschnittstelle 269 kann eine Netzwerkseite, einen Anwendungsbildschirm usw. umfassen, welche die Verwaltung eines Testmodusdiensts 224 ermöglicht. Die Client-Vorrichtung 209 kann dazu konfiguriert sein, Anwendungen über die Client-Anwendung 266 hinaus auszuführen, wie etwa E-Mail-Anwendungen, Anwendungen für soziale Netzwerke, Textverarbeitungsprogramme, Tabellenkalkulationen und/oder andere Anwendungen.
Als Nächstes werden nicht einschränkende Beispiele in Bezug auf die Integration in E-Commerce-Systeme beschrieben. Ein E-Commerce-System beinhaltet Systeme zum Durchführen solcher Funktionen wie etwa Anzeigen von Produktempfehlungen, Empfangen einer Bestellung, Erstellen von Rechnungen, Bearbeiten von Zahlungen, Verwalten von Warenbeständen und Abwickeln von Versand und Rücksendungen usw. Jede dieser Funktionen ist so programmiert, dass sie auf den Wert oder Status einer Reihe von Variablen achtet, die bestimmen, wie eine Bestellung bearbeitet wird. Das beschriebene Integrationssystem definiert eine Reihe von Testszenarien, die ändern, wie eine oder mehrere dieser Funktionen eine Bestellung bearbeitet.
In einer Ausführungsform legt jedes Testszenario eine Kombination aus einem oder mehreren Plugins fest, um einen Testbestellungsablauf auszuführen, wie etwa unten in Beispiel 1 und Beispiel 2 beschrieben, die den Wert oder Status der Flags oder Variablen ändern, die durch die Funktionen zur Bearbeitung einer Bestellung verwendet werden. Der Benutzer kann auswählen, welche Testszenarien auf einer Testmodus-Benutzeroberfläche aktiviert sind, und empfängt Ergebnisse, die zeigen, wie das E-Commerce-System als Reaktion auf die Änderungen reagiert, die durch das aktivierte Testszenario vorgenommen werden.
In einer Ausführungsform enthält jede Bestellung, die von einem Beschaffungssystem eines Drittanbieters aufgegeben wird, das in das E-Commerce-System integriert ist, ein Feld, das seine Bestellung als „TESTMODUS“ markiert, beispielsweise in einer Extensible-Markup-Language(XML)-Datei, welche die Bestellung definiert. Das E-Commerce-System ist so programmiert, dass es in jeder eingehenden Bestelldatei nach diesem Wert sucht und, wenn der Wert vorliegt, die Bestellung an das Integrationssystem weiterleitet. Das Integrationssystem fährt mit der Bearbeitung der Testmodus-Bestellung fort, indem es nachsieht, welche der Testszenarien durch den Kunden aktiviert wurden. Intern aktiviert das System bei Auswahl dieser Testszenarien ein oder mehrere Plugins für die jeweiligen Testszenarien.
Diese Plugins, die aktiviert wurden, ändern oder setzen den Wert einer oder mehrerer der vorbestimmten Variablen oder Flags, die durch die E-Commerce-Funktionen verwendet werden. In einer Ausführungsform ist jedes Skript so geschrieben, dass keine tatsächlichen Lieferungen oder Zahlungen erfolgen und dass in einer Bestellung angeforderter Warenbestand nicht tatsächlich von den Aufzeichnungen des vorhandenen Warenbestands abgezogen wird. Der folgende Pseudocode zeigt Schritte, die von Plugins ausgeführt werden können, um Zahlungen oder Sendungen zu testen.
Beispiel 1: Ausführung des Zahlungs-Plugins:
In diesem Szenario besteht die Absicht eines Kunden darin, die Nachrichtenübertragungsflüsse und -werte zu testen, ohne eine Zahlung für die Bestellung zu leisten. Daher rufen die jeweiligen Szenarien ein Zahlungs-Plugin auf, um seinen Wert auf ein Dummy-Zahlungsmittel festzulegen. Dieser Wert ermöglicht es den internen Systemen, den Bestellablauf auszuführen, ohne ihn dem Kunden in Rechnung zu stellen. Bei einem anderen Ansatz wählt das Zahlungs-Plugin eines der im Geschäftskonto des Kunden eingerichteten Zahlungsmittel aus. Das Plugin vollzieht dies, indem es die Zahlungsfunktion aufruft, und die Funktion kehrt mit dem bevorzugten Zahlungsmittel des Kunden zurück, um einen Kauf auszuführen. Das Plugin setzt das Zahlungsmittel - bevorzugtes Zahlungsmittel (Kreditlinie, Kreditkarte usw.) fest, um den Bestellablauf auszuführen. Sobald ein Bestellablauf End-to-End ausgeführt wurde, empfängt das Plugin die Eingabe vom Testbestellungsszenario-Ausführungsdienst, um das Zahlungsmittel freizugeben und den Zahlungsfluss zu stornieren. Da die Bestellung nicht versandt wurde, wird das Zahlungsmittel des Kunden nicht belastet und durch das Plugin bis zum Eingang der nächsten Testbestellung nicht mehr verwendet.
Ein Zahlungs-Plugin im Testmodus setzt Folgendes fest: Payment = DummyPaymentlnstrument (eine interne Zahlungsmethode, die alle Zahlungsoperationen wie Kredit, Lastschrift, Kontostand usw. bereitstellt).
Bei der Nachbearbeitung der Bestellung storniert das Zahlungs-Plugin die Zahlung, was nicht erforderlich ist, wenn es sich bei einer Zahlung um eine Dummy-Zahlung handelt.
Beispiel 2: Ausführung des Versand-Plugins:
Um den End-to-End-Bestellablauf zu vervollständigen, wird eine „virtuelle“ Dummy-Sendung generiert. Dadurch wird sichergestellt, dass der Kunde alle End-to-End-Nachrichten wie Lieferavis und Rechnung empfängt. In einer Ausführungsform besteht die Art und Weise, wie dies ausgeführt wird, darin, das Versand-Plugin aufzurufen, um den Erfüllungswert auf unechte Versandgenerierung zu setzen. Wenn dieser Wert gesetzt ist, durchläuft die Bestellung nicht die Erfüllungssysteme und es findet kein Versand statt. Das E-Commerce-System ist jedoch in der Lage, die Bestellung End-to-End mit Dummy-Versandwerten wie etwa Lieferdaten und Frachtnummer des Spediteurs zu verarbeiten. Dadurch kann der Bestellablauf zu den nächsten Schritten der Erstellung und Übermittlung von Rechnungen an den Kunden übergehen.
Das Versand-Plugin im Testmodus setzt Folgendes fest:

Fulfillment=FakeShipGen (um Versandquittung zu generieren)
Fulfillment=FakeShipComplete (nach Versandquittung, um echten Versand zu stoppen)

Wenn in einem anderen Beispiel ein Plugin geschrieben wird, um zu sehen, wie das System auf eine 20-prozentige Preisänderung bei einem Artikel reagiert, setzt das Plugin den Wert der Preisvariablen, die durch das E-Commerce-System überprüft wird, so, dass der Preis um 20 % im Vergleich zu dem in der Testbestellung aufgeführten Preis erhöht wird. Das System hat seine eigenen Toleranzgrenzen und basierend darauf wird das System reagieren, wie diese Bestellung fortgesetzt wird. Das Plugin-Skript wird geschrieben, um die Ergebnisse in Bezug darauf zu sammeln, wie sich das E-Commerce-System als Reaktion auf die Preisänderung verhält, und um die Werte in einer XML-Datei für die Bestellung an den Kunden auszugeben.
3A ist ein Ablaufdiagramm, das ein Beispiel für den Betrieb eines Teils des Testmodusdienstes 224 gemäß verschiedenen Ausführungsformen bereitstellt. Es versteht sich, dass das Ablaufdiagramm aus 3A lediglich ein Beispiel der vielen unterschiedlichen Arten von Funktionsanordnungen bereitstellt, die verwendet werden können, um den Betrieb des Teils des Testmodusdienstes 224 wie in dieser Schrift beschrieben umzusetzen. Als Alternative kann das Ablaufdiagramm aus 3A als Darstellung eines Beispiels von Elementen eines Verfahrens angesehen werden, das in der Rechenumgebung 203 (2) gemäß einer oder mehreren Ausführungsformen umgesetzt ist.
Beginnend mit Kästchen 303 generiert der Testmodusdienst 224 über den Testmodus-Verwaltungsdienst 248 (2) eine Verwaltungsbenutzerschnittstelle 269 (2) als Reaktion auf eine Anforderung, die durch eine Client-Anwendung 266 (2) gesendet wird, die auf der Client-Vorrichtung 209 (2) ausgeführt wird. In einem anderen Beispiel wird die Anforderung über eine Kontoaktion auf dem Produktionssystem 218 generiert. Die Verwaltungsbenutzerschnittstelle 269 ist in einem Beispiel die Benutzerschnittstelle 100 (1A). In Kästchen 306 empfängt der Testmodusdienst 224 eine Anforderung, den Testmodus für ein Konto bei dem Produktionssystem 218 (2) zu aktivieren. In Kästchen 309 fährt der Testmodusdienst 224 damit fort, den Testmodus für das Konto zu aktivieren, was bedeutet, dass die von Drittanbietern bereitgestellten Daten 251 (2), die dem Produktionssystem 218 bereitgestellt werden, nicht auf normale Weise verarbeitet werden. Wenn beispielsweise die von Drittanbietern bereitgestellten Daten 251 einer Bestellung entsprechen, führt das Produktionssystem 218 im Testmodus keine Aktionen durch, die zu nicht umkehrbaren Zustandsänderungen führen (z. B. Belastung von Zahlungsmitteln, tatsächliche Erfüllung von Bestellungen, Versand von Bestellungen usw.).
In Kästchen 312 empfängt der Testmodusdienst 224 eine Anforderung zum Testen einer Integration 236 (2) eines Drittanbietersystems 239 (2) in das Produktionssystem 218. In einem Beispiel wählt der Benutzer ein bestimmtes Testszenario 233 (2) aus einer Vielzahl möglicher Testszenarien 233 aus, die in einer Verwaltungsbenutzerschnittstelle 269 aufgeführt sind, die von der Client-Vorrichtung 209 wiedergegeben wird.
In Kästchen 315 aktiviert der Testmodusdienst 224 ein oder mehrere Test-Plugins 221 (2), um die Funktionalität einer oder mehrerer Komponenten 230 (2) des Produktionssystems 218 zu testen. In dieser Hinsicht richtet der Testmodus-Szenario-Ausführungsdienst 242 (2) den Arbeitsablauf ein, der zum Umsetzen des ausgewählten Testszenarios 233 erforderlich ist, wie etwa Identifizieren einer Teilmenge von zu verwendenden Test-Plugins 221, mindestens teilweise auf Grundlage der Testmoduskonfigurationsdaten 260 (2). Das Aktivieren der Test-Plugins 221 markiert Daten, die durch die Komponenten 230 des Produktionssystems 218 verarbeitet werden, als Testdaten, sodass die normalen Folgen des Ausführens der Funktionalität blockiert oder rückgängig gemacht werden. Beispielsweise führt ein Test-Plugin 221 ein oder mehrere Attribute in Bestelldaten ein, um die Bestelldaten als Testdaten zu markieren.
In Kästchen 318 empfängt der Testmodusdienst 224 von Drittanbietern bereitgestellte Daten 251, wie etwa eine Bestellung, über die Produktionssystemschnittstelle 227 (2). Beispielsweise generiert das Drittanbietersystem 239 eine Bestellung über die Integration 236, wodurch Artikel aus einem Artikelkatalog über das Produktionssystem 218 und das Drittanbietersystem 239 ausgewählt werden können, wo die ausgewählten Artikel einem Einkaufswagen oder -korb für einen Kauf hinzugefügt werden. Die von Drittanbietern bereitgestellten Daten 251 entsprechen in manchen Fällen einer Shopping-Session, einer Stornierungsanfrage für eine Bestellung oder einer Rückgabeanfrage für eine Bestellung. Der Testmodus-Plugin-Orchestrierer 248 (2) ruft dann die Teilmenge von Test-Plugins 221 auf, um die von Drittanbietern bereitgestellten Daten 251 mindestens teilweise auf Grundlage der Informationen zu verarbeiten, die von dem Testmodusszenario-Ausführungsdienst 242 bereitgestellt werden.
In Kästchen 321 führt der Testmodusdienst 224 eine oder mehrere Funktionen einer oder mehrerer Komponenten 230 des Produktionssystems 218 unter Verwendung der Teilmenge von Test-Plugins 221 aus. Die Test-Plugins 221 bewirken in verschiedenen Szenarien, dass die Ausführung einer oder mehrerer Komponenten 230 übersprungen und durch simulierte oder Dummy-Daten ersetzt wird. Die Test-Plugins 221 bewirken in verschiedenen Szenarien, dass eine oder mehrere Komponenten 230 davon absehen, eine nicht umkehrbare Zustandsänderung vorzunehmen (z. B. eine Belastung eines Zahlungsmittels, nicht umkehrbare Warenbestandsreservierung, Versand einer Bestellung durch einen Spediteur usw.). Die Test-Plugins 221 bewirken in verschiedenen Szenarien, dass eine oder mehrere Komponenten 230 eine Zustandsänderung umkehren (z. B. eine Zahlungsautorisierung stornieren, eine Zahlungsgebühr zurückerstatten, reservierten Warenbestand freigeben usw.).
In einigen Beispielen veranlasst ein Zahlungsverarbeitungs-Plugin einen Zahlungsverarbeitungsdienst dazu, ein Testmodus-Zahlungsmittel für die Zahlungsverarbeitung zu verwenden, bewirkt ein Bestell-Plugin, dass ein Kaufdokument erstellt wird, das als Testbestellung gekennzeichnet ist, veranlasst ein Warenbestand-Plugin ein Warenbestandssystem dazu, davon abzusehen, einen Warenbestand für die Testbestellung zu reservieren, veranlasst ein Bestellbenachrichtigungs-Plugin einen Bestellbenachrichtigungsdienst, Client-Anwendungen 266 über die Kaufdokumente zu benachrichtigen, und so weiter.
In Kästchen 324 empfängt der Testmodusdienst 224 das Ergebnis der Ausführung der Komponenten 230 und/oder der Test-Plugins 221. Der Testmodusdienst 224 empfängt in einigen Fällen auch Ergebnisse, die von dem Drittanbietersystem 239 oder der Integration 236 gemeldet werden. In Kästchen 327 meldet der Testmodusdienst 224 die Ergebnisse der ausgewählten Testszenarien 233 über eine Benutzerschnittstelle 269, wie etwa die Benutzerschnittstelle 130 (1 B). Beispielsweise geben die Ergebnisse an, wie das Produktionssystem 218 eine Testbestellung oder andere von der Integration 236 bereitgestellte Daten verarbeitet hat. Auf Grundlage dessen, was gemeldet wird und/oder was von dem Drittanbietersystem 239 oder der Integration 236 gemeldet wird, markiert ein Benutzer in einigen Ausführungsformen ein Testszenario 233 als fehlgeschlagen oder erfolgreich. In einigen Ausführungsformen bestimmt die automatisierte Logik mindestens teilweise auf Grundlage des Ergebnisses, ob das Testszenario 233 fehlgeschlagen ist oder erfolgreich war. Danach endet der Betrieb des Teils des Testmodusdienstes 224.
3B ist ein Sequenzdiagramm 330, das ein Beispiel der Interaktion zwischen dem Drittanbietersystem 239, dem Testmodusdienst 224, den Test-Plugins 221 und dem Produktionssystem 218 gemäß verschiedenen Ausführungsformen bereitstellt. Es versteht sich, dass das Sequenzdiagramm 330 lediglich ein Beispiel für die vielen unterschiedlichen Arten von funktionalen Anordnungen liefert, die verwendet werden können, um die Interaktion zwischen dem Drittanbietersystem 239, dem Testmodusdienst 224, den Test-Plugins 221 und dem Produktionssystem 218 umzusetzen. Als Alternative kann das Ablaufdiagramm aus 3B als Darstellung eines Beispiels von Elementen eines Verfahrens angesehen werden, das in der Rechenumgebung 203 (2) gemäß einer oder mehreren Ausführungsformen umgesetzt ist.
Beginnend mit Kästchen 333 generiert das Drittanbietersystem 239 eine Testbestellung. Diese folgt einem Benutzer, der dem Drittanbieter entspricht, der ein Testszenario 233 (2) über eine Benutzerschnittstelle 269 (2) aktiviert. Die Testbestellung wird durch die Integration 236 (2) über das Netzwerk 212 (2) an die Produktionssystemschnittstelle 227 (2) gesendet. In einem Beispiel führt die Produktionssystemschnittstelle 227 Struktur, Authentizitäts- und Autorisierungsprüfungen durch. Wenn einer dieser Tests fehlschlägt, wird dem Benutzer über die Benutzerschnittstelle 269 eine Fehlermeldung ausgegeben. Die Produktionssystemschnittstelle 227 aktiviert ein oder mehrere Testmodus-Flags und ruft den Testmodusdienst 224 auf, um einen entsprechenden Arbeitsablauf für das von dem Drittanbieter gewählte Testszenario 233 zu ermitteln. Der Testmodusdienst 224 (2) empfängt die Testbestellung über die Produktionssystemschnittstelle 227.
In Kästchen 336 bestimmt der Testmodusdienst 224 einen Satz von einem oder mehreren Test-Plugins 221, die zu aktivieren sind, um das Testen des Produktionssystems 218 unter Verwendung der Testbestellung zu erleichtern. In Kästchen 339 aktiviert der Testmodusdienst 224 die Test-Plugins 221, was bewirkt, dass die Test-Plugins 221 ein oder mehrere Attribute in die Testbestellung zum Testen der Funktionalität des Produktionssystems 218 einfügen.
In Kästchen 342 führen die Test-Plugins 221 eine oder mehrere Funktionen des Produktionssystems 218 aus, um die Funktionen unter Verwendung der Testbestellung zu testen. In dieser Hinsicht werden von den Test-Plugins 221 Attribute gesetzt und zurückgesetzt, Operationen ausgeführt und rückgängig gemacht, Dummy-Datensätze erstellt und gelöscht und so weiter. In einem Beispiel legt ein Zahlungstest-Plugin ein Zahlungsmittel als Dummy-Zahlungsmittel fest. In einem Beispiel setzt ein Versandtest-Plugin Erfüllungsattribute, um eine Versandquittung zu generieren und einen echten Versand zu stoppen. In einem Beispiel gibt ein Bestelltest-Plugin eine Bestellung auf, ein Warenbestandstest-Plugin reserviert Warenbestand, und wenn die Bestellung aufgegeben wird, speichert das Bestelltest-Plugin alle erforderlichen Daten, um eine Testrechnung zu erstellen. Dann gibt das Warenbestandstest-Plugin den Warenbestand frei und das Bestelltest-Plugin storniert die Bestellung.
In Kästchen 345 führt das Produktionssystem 218 die Funktionen aus und kehrt zu den Test-Plugins 221 zurück. Die Antwort der Test-Plugins 221 entscheidet über einen nächsten Satz von Aktionen, wie etwa zum nächsten Schritt übergehen, den Arbeitsablauf unterbrechen und so weiter. In Kästchen 348 generieren die Test-Plugins 221 simulierte Daten, um eine oder mehrere Aktionen des Produktionssystems 218 zu simulieren. In Kästchen 351 machen die Test-Plugins 221 eine oder mehrere Aktionen des Produktionssystems 218 rückgängig. Beispielsweise storniert ein Zahlungs-Plugin im Testmodus eine Zahlung. In Kästchen 354 werden die Ergebnisse, wie das Produktionssystem 218 die Funktionen unter Verwendung der Testbestellung ausführt, einschließlich nach Bedarf der simulierten Daten, durch die Test-Plugins 221 an den Testmodusdienst 224 und schließlich an das Drittanbietersystem ausgegeben. Danach endet das Sequenzdiagramm 330.
4 ist ein schematisches Blockdiagramm der Rechenumgebung 203 gemäß einer Ausführungsform der vorliegenden Offenbarung. Die Rechenumgebung 203 beinhaltet eine oder mehrere Rechenvorrichtungen 400. Jede Rechenvorrichtung 400 beinhaltet mindestens eine Prozessorschaltung, beispielsweise mit einem Prozessor 403 und einem Speicher 406, die beide mit einer lokalen Schnittstelle 409 gekoppelt sind. Zu diesem Zweck umfasst jede Rechenvorrichtung 400 beispielsweise mindestens einen Servercomputer oder eine ähnliche Vorrichtung. Die lokale Schnittstelle 409 umfasst beispielsweise einen Datenbus mit einem begleitenden Adress-/Steuerbus oder einer anderen Busstruktur, wie ersichtlich ist.
Im Speicher 406 sind sowohl Daten als auch mehrere Komponenten gespeichert, die durch den Prozessor 403 ausführbar sind. Insbesondere sind im Speicher 406 ein Produktionssystem 218, ein oder mehrere Test-Plugins 221, ein Testmodusdienst 224, eine Produktionssystemschnittstelle 227 und möglicherweise andere Anwendungen gespeichert und durch den Prozessor 403 ausführbar. Außerdem können im Speicher 406 ein Datenspeicher 215 und andere Daten gespeichert sein. Zusätzlich kann ein Betriebssystem im Speicher 406 gespeichert und durch den Prozessor 403 ausführbar sein.
Es versteht sich, dass es andere Anwendungen geben kann, die im Speicher 406 gespeichert sind und durch den Prozessor 403 ausführbar sind, wie ersichtlich ist. Wenn eine in dieser Schrift erörterte Komponente in Form von Software umgesetzt wird, kann eine beliebige einer Reihe von Programmiersprachen verwendet werden, wie etwa beispielsweise C, C++, C#, Objective C, Java^®, JavaScript^®, Perl, PHP, Visual Basic^®, Python^®, Ruby, Flash^® oder andere Programmiersprachen.
Eine Reihe von Softwarekomponenten sind im Speicher 406 gespeichert und durch den Prozessor 403 ausführbar. In dieser Hinsicht bedeutet der Begriff „ausführbar“ eine Programmdatei, die in einer Form vorliegt, die letztendlich durch den Prozessor 403 ausgeführt werden kann. Beispiele für ausführbare Programme können beispielsweise ein kompiliertes Programm, das in Maschinencode in einem Format übersetzt werden kann, das in einen Teil des Speichers 406 mit wahlfreiem Zugriff geladen und vom Prozessor 403 ausgeführt werden kann, Quellcode, der in einem geeigneten Format ausgedrückt werden kann, wie etwa Objektcode, der in einen Teil des Speichers 406 mit wahlfreiem Zugriff geladen und durch den Prozessor 403 ausgeführt werden kann, oder Quellcode, der durch ein anderes ausführbares Programm interpretiert werden kann, um Befehle in einem Teil des Speichers 406 mit wahlfreiem Zugriff zu generieren, die durch den Prozessor 403 ausgeführt werden können, usw. sein. Ein ausführbares Programm kann in jedem Teil oder jeder Komponente des Speichers 406 gespeichert sein, einschließlich beispielsweise Direktzugriffsspeicher (RAM), Nur-Lese-Speicher (ROM), Festplatte, Solid-State-Laufwerk, USB-Flash-Laufwerk, Speicherkarte, optische Disc wie etwa Compact Disc (CD) oder Digital Versatile Disc (DVD), Diskette, Magnetband oder andere Speicherkomponenten.
Der Speicher 406 ist in dieser Schrift so definiert, dass er sowohl flüchtige als auch nichtflüchtige Speicher- und Datenspeicherkomponenten beinhaltet. Flüchtige Komponenten sind diejenigen, die Datenwerte bei einem Stromausfall nicht beibehalten. Nichtflüchtige Komponenten sind diejenigen, die Daten bei einem Stromausfall beibehalten. Somit kann der Speicher 406 beispielsweise einen Direktzugriffsspeicher (RAM), einen Festwertspeicher (ROM), Festplattenlaufwerke, Solid-State-Laufwerke, USB-Flash-Laufwerke, Speicherkarten, auf die über ein Speicherkartenlesegerät zugegriffen wird, Disketten, auf die über ein zugehöriges Diskettenlaufwerk zugegriffen wird, optische Platten, wie etwa solche, auf die über ein optisches Laufwerk zugegriffen wird, Magnetbänder, auf die über ein entsprechendes Bandlaufwerk zugegriffen wird, und/oder andere Speicherkomponenten oder eine Kombination aus zwei oder mehreren dieser Speicherkomponenten umfassen. Außerdem kann der RAM beispielsweise einen statischen Direktzugriffsspeicher (SRAM), einen dynamischen Direktzugriffsspeicher (DRAM) oder einen magnetischen Direktzugriffsspeicher (MRAM) und andere derartige Vorrichtungen umfassen. Der ROM kann beispielsweise einen programmierbaren Nur-Lese-Speicher (PROM), einen löschbaren programmierbaren Nur-Lese-Speicher (EPROM), einen elektrisch löschbaren programmierbaren Nur-Lese-Speicher (EEPROM) oder eine andere ähnliche Speichervorrichtung umfassen.
Außerdem kann der Prozessor 403 mehrere Prozessoren 403 und/oder mehrere Prozessorkerne darstellen und der Speicher 406 kann mehrere Speicher 406 darstellen, die jeweils in parallelen Verarbeitungsschaltungen arbeiten. In einem solchen Fall kann die lokale Schnittstelle 409 ein geeignetes Netzwerk sein, das eine Kommunikation zwischen zwei der mehreren Prozessoren 403, zwischen einem Prozessor 403 und einem der Speicher 406 oder zwischen zwei der Speicher 406 usw. erleichtert. Die lokale Schnittstelle 409 kann zusätzliche Systeme umfassen, die dazu ausgelegt sind, diese Kommunikation zu koordinieren, einschließlich beispielsweise der Durchführung eines Lastausgleichs. Der Prozessor 403 kann eine elektrische oder eine andere verfügbare Konstruktion sein.
Obwohl das Produktionssystem 218, die Test-Plugins 221, der Testmodusdienst 224, die Produktionssystemschnittstelle 227 und andere verschiedene in dieser Schrift beschriebene Systeme in Software oder Code verkörpert sein können, der durch Allzweckhardware ausgeführt wird, wie vorstehend erörtert, kann es alternativ dazu auch in dedizierter Hardware oder einer Kombination aus Software/Allzweckhardware und dedizierter Hardware verkörpert sein. Bei Verkörperung in dedizierter Hardware kann jede als Schaltung oder Zustandsmaschine umgesetzt werden, die eine beliebige oder eine Kombination mehrerer Technologien verwendet. Diese Technologien beinhalten unter anderem diskrete Logikschaltungen mit Logikgattern zur Umsetzung verschiedener logischer Funktionen bei der Anwendung eines oder mehrerer Datensignale, anwendungsspezifische integrierte Schaltungen (ASICs) mit entsprechenden Logikgattern, feldprogrammierbare Gate-Arrays (FPGAs) oder andere Komponenten usw. Solche Technologien sind dem Fachmann allgemein gut bekannt und werden folglich in dieser Schrift nicht im Detail beschrieben.
Das Ablaufdiagramm aus 3A zeigt die Funktionalität und den Betrieb einer Umsetzung von Teilen des Testmodusdienstes 224. Bei Verkörperung in Software kann jeder Block ein Modul, ein Segment oder einen Teil eines Codes darstellen, der Programmbefehle umfasst, um die festgelegte(n) logische(n) Funktion(en) umzusetzen. Die Programmbefehle können in Form eines Quellcodes, der für Menschen lesbare Anweisungen umfasst, die in einer Programmiersprache geschrieben sind, oder von Maschinencode, der numerische Befehle umfasst, die von einem geeigneten Ausführungssystem wie etwa einem Prozessor 403 in einem Computersystem oder einem anderen System erkennbar sind, verkörpert sein. Der Maschinencode kann aus dem Quellcode konvertiert werden usw. Bei Verkörperung in Hardware kann jeder Block eine Schaltung oder eine Anzahl miteinander verbundener Schaltungen darstellen, um die festgelegte(n) logische(n) Funktion(en) umzusetzen.
Obwohl das Ablaufdiagramm aus 3A und das Sequenzdiagramm aus 3B eine spezifische Ausführungsreihenfolge zeigen, versteht es sich, dass die Ausführungsreihenfolge von der dargestellten abweichen kann. Beispielsweise kann die Ausführungsreihenfolge von zwei oder mehr Blöcken relativ zu der gezeigten Reihenfolge umgestellt werden. Auch können zwei oder mehr Blöcke, die in 3A oder 3B nacheinander gezeigt sind, gleichzeitig oder teilweise gleichzeitig ausgeführt werden. Ferner können in einigen Ausführungsformen einer oder mehrere der in 3A oder 3B gezeigten Blöcke übersprungen oder weggelassen werden. Außerdem kann dem in dieser Schrift beschriebenen logischen Fluss eine beliebige Anzahl von Zählern, Zustandsvariablen, Warnsemaphoren oder Nachrichten hinzugefügt werden, um den Nutzen, die Abrechnung, die Leistungsmessung oder die Bereitstellung von Hilfen zur Fehlersuche usw. zu verbessern. Es versteht sich, dass alle diese Variationen im Umfang der vorliegenden Offenbarung liegen.
Außerdem kann jede in dieser Schrift beschriebene Logik oder Anwendung, einschließlich des Produktionssystems 218, der Test-Plugins 221, des Testmodusdienstes 224 und der Produktionssystemschnittstelle 227, die Software oder Code umfasst, in einem beliebigen nichtflüchtigen computerlesbaren Medium zur Verwendung durch oder in Verbindung mit einem Befehlsausführungssystem wie etwa einem Prozessor 403 in einem Computersystem oder einem anderen System verkörpert sein. In diesem Sinne kann die Logik beispielsweise Anweisungen umfassen, die Befehle und Deklarationen beinhalten, die von dem computerlesbaren Medium abgerufen und durch das Befehlsausführungssystem ausgeführt werden können. Im Zusammenhang mit der vorliegenden Offenbarung kann ein „computerlesbares Medium“ ein beliebiges Medium sein, das die in dieser Schrift beschriebene Logik oder Anwendung zur Verwendung durch oder in Verbindung mit dem Befehlsausführungssystem enthalten, speichern oder pflegen kann.
Das computerlesbare Medium kann eines von vielen physischen Medien umfassen, wie etwa beispielsweise magnetische, optische oder Halbleitermedien. Spezifischere Beispiele für ein geeignetes computerlesbares Medium würden Magnetbänder, Magnetdisketten, magnetische Festplatten, Speicherkarten, Solid-State-Laufwerke, USB-Flash-Laufwerke oder optische Platten beinhalten, ohne jedoch darauf beschränkt zu sein. Außerdem kann das computerlesbare Medium ein Direktzugriffsspeicher (RAM) sein, der beispielsweise einen statischen Direktzugriffsspeicher (SRAM) und einen dynamischen Direktzugriffsspeicher (DRAM) oder einen magnetischen Direktzugriffsspeicher (MRAM) beinhaltet. Außerdem kann das computerlesbare Medium ein Nur-Lese-Speicher (ROM), ein programmierbarer Nur-Lese-Speicher (PROM), ein löschbarer programmierbarer Nur-Lese-Speicher (EPROM), ein elektrisch löschbarer programmierbarer Nur-Lese-Speicher (EEPROM) oder eine andere Art von Speichervorrichtung sein.
Ferner kann jede in dieser Schrift beschriebene Logik oder Anwendung, einschließlich des Produktionssystems 218, der Test-Plugins 221, des Testmodusdienstes 224 und der Produktionssystemschnittstelle 227, auf vielfältige Weise umgesetzt und strukturiert werden. Beispielsweise können eine oder mehrere beschriebene Anwendungen als Module oder Komponenten einer einzelnen Anwendung umgesetzt werden. Ferner können eine oder mehrere hierin beschriebene Anwendungen in gemeinsam genutzten oder separaten Rechenvorrichtungen oder einer Kombination davon ausgeführt werden. Beispielsweise kann eine Vielzahl der hierin beschriebenen Anwendungen in derselben Rechenvorrichtung 400 oder in mehreren Rechenvorrichtungen 400 in derselben Rechenumgebung 203 ausgeführt werden.
Eine disjunktive Formulierung, wie etwa der Ausdruck „mindestens eines von X, Y oder Z“, ist, sofern nicht ausdrücklich anders angegeben, im Kontext so zu verstehen, wie sie im Allgemeinen verwendet wird, um darzustellen, dass ein Gegenstand, ein Begriff usw. entweder X, Y oder Z oder eine beliebige Kombination davon (z. B. X, Y und/oder Z) sein kann. Somit soll eine derartige disjunktive Sprache im Allgemeinen nicht ausdrücken, dass bestimmte Ausführungen erfordern, dass mindestens eines von X, mindestens eines von Y oder mindestens eines von Z jeweils vorhanden ist.
Ausführungsformen der vorliegenden Offenbarung lassen sich durch mindestens die folgenden Klauseln beschreiben:

Klausel 1. Nichtflüchtiges computerlesbares Medium, das ein Programm verkörpert, das auf mindestens einer Rechenvorrichtung ausführbar ist, wobei das Programm bei Ausführung die mindestens eine Rechenvorrichtung zu mindestens Folgendem veranlasst: Empfangen einer Anforderung, eine Integration eines Einkaufssystems, das durch einen Drittanbieter betrieben wird, mit einem Bestellungsaufgabe- und -erfüllungssystem zu testen, das durch einen E-Commerce-Anbieter und in Live-Produktion betrieben wird; Aktivieren des mindestens einen Test-Plugins, das ein oder mehrere Attribute in Bestelldaten des Bestellungsaufgabe- und -erfüllungssystem einführt, wobei das eine oder die mehreren Attribute die Bestelldaten als Testdaten markieren, die durch das Bestellungsaufgabe- und -erfüllungssystem zu verarbeiten sind; Ausführen von mindestens einer Funktion des Bestellungsaufgabe- und -erfüllungssystems durch das mindestens eine Test-Plugin unter Verwendung einer Testbestellung, die durch die Integration des Einkaufssystems bereitgestellt wird; Melden eines Ergebnisses, wie das Bestellungsaufgabe- und -erfüllungssystem die Testbestellung bearbeitet, indem die mindestens eine Funktion durch das mindestens eine Test-Plugin ausgeführt wird.
Klausel 2. Nichtflüchtiges computerlesbares Medium nach Klausel 1, wobei das mindestens eine Test-Plugin eine Warenbestandsreservierung bzw. Bestandsreservierung rückgängig macht, die dem Ausführen der mindestens einen Funktion unter Verwendung der Testbestellung zugeordnet ist.
Klausel 3. Nichtflüchtiges computerlesbares Medium nach den Klauseln 1 bis 2, wobei das mindestens eine Test-Plugin die Erfüllung einer Sendung blockiert, die dem Ausführen der mindestens einen Funktion unter Verwendung der Testbestellung zugeordnet ist.
Klausel 4. System, umfassend: mindestens eine Rechenvorrichtung; und einen Testmodusdienst, der in der mindestens einen Rechenvorrichtung ausführbar ist, wobei der Testmodusdienst bei Ausführung die mindestens eine Rechenvorrichtung mindestens zu Folgendem veranlasst: Empfangen einer Anforderung zum Testen einer Integration eines Drittanbietersystems mit einem Produktionssystem; Aktivieren von mindestens einem Plugin, um mindestens eine Funktion des Produktionssystems zu testen, wobei das Aktivieren des mindestens einen Plugins Daten markiert, die durch das Produktionssystem als Testdaten verarbeitet werden; Ausführen der mindestens einen Funktion des Produktionssystems unter Verwendung des mindestens einen Plugins und der Daten, die durch die Integration des Drittanbietersystems bereitgestellt werden; und Melden eines Ergebnisses darüber, wie das Produktionssystem die mindestens eine Funktion durchführt, die dem mindestens einen Plugin unter Verwendung der Testdaten zugeordnet ist.
Klausel 5. System nach Klausel 4, wobei die Integration des Drittanbietersystems dazu konfiguriert ist, während des Testens mit dem Produktionssystem zu kommunizieren.
Klausel 6. System nach den Klauseln 4 bis 5, wobei der Testmodusdienst ein Selbstbedienungstesten der Integration des Drittanbietersystems ohne manuellen Eingriff durch einen Bediener des Produktionssystems bereitstellt.
Klausel 7. System nach den Klauseln 4 bis 6, wobei das Produktionssystem eine Vielzahl von Komponenten beinhaltet, die in einer Pipeline angeordnet ist, um die Daten zu verarbeiten, die durch die Integration des Drittanbietersystems bereitgestellt werden.
Klausel 8. System nach den Klauseln 4 bis 7, wobei die Anforderung zum Testen der Integration ein bestimmtes Testszenario angibt und der Testmodusdienst ferner die mindestens eine Rechenvorrichtung dazu veranlasst, das mindestens eine Plugin als eine Teilmenge einer Vielzahl von Plugins mindestens teilweise auf Grundlage des jeweiligen Testszenarios zu identifizieren.
Klausel 9. System nach Klausel 8, wobei der Testmodusdienst ferner die mindestens eine Rechenvorrichtung mindestens dazu veranlasst, eine Benutzerschnittstelle zu generieren, die eine Benutzerauswahl des jeweiligen Testszenarios aus einer Vielzahl von möglichen Testszenarien erleichtert.
Klausel 10. System nach den Klauseln 4 bis 9, wobei das mindestens eine Plugin eine Zustandsänderung umkehrt, die durch die Ausführung der mindestens einen Funktion des Produktionssystems verursacht wird.
Klausel11. System nach den Klauseln 4 bis 10, wobei das mindestens eine Plugin einen Betrieb mindestens eines Teils des Produktionssystems unter Verwendung der Daten simuliert, die durch die Integration des Drittanbietersystems bereitgestellt werden.
Klausel 12. System nach den Klauseln 4 bis 11, wobei die mindestens eine Funktion des Produktionssystems bei Ausführung normalerweise eine nicht umkehrbare Zustandsänderung umsetzt und das mindestens eine Plugin die nicht umkehrbare Zustandsänderung blockiert.
Klausel 13. System nach den Klauseln 4 bis 12, wobei das Drittanbietersystem einem Einkaufssystem eines Drittanbieters entspricht, das Produktionssystem einem Bestellungsaufgabe- und -erfüllungssystem eines E-Commerce-Anbieters entspricht und die durch die Integration des Drittanbietersystems bereitgestellten Daten einer Testbestellung entsprechen.
Klausel 14. Verfahren, umfassend: Empfangen, über mindestens eine Rechenvorrichtung, einer Anforderung zum Testen einer Integration eines Drittanbietersystems mit einem Produktionssystem; Ausführen, über die mindestens eine Rechenvorrichtung, mindestens einer Funktion des Produktionssystems unter Verwendung von mindestens einem Plugin und Daten, die durch die Integration des Drittanbietersystems bereitgestellt werden; Umkehren, über die mindestens eine Rechenvorrichtung, einer Zustandsänderung, die durch die Ausführung der mindestens einen Funktion unter Verwendung des mindestens einen Plugins verursacht wurde; und Melden, über die mindestens eine Rechenvorrichtung, eines Ergebnisses darüber, wie das Produktionssystem die mindestens eine Funktion ausführt, die dem mindestens einen Plugin zugeordnet ist.
Klausel 15. Verfahren nach Klausel 14, ferner umfassend Generieren einer Benutzerschnittstelle über die mindestens eine Rechenvorrichtung, die eine Benutzerauswahl eines bestimmten Testszenarios aus einer Vielzahl möglicher Testszenarien erleichtert.
Klausel 16. Verfahren nach den Klauseln 14 bis 15, ferner umfassend Aktivieren des mindestens einen Plugins über die mindestens eine Rechenvorrichtung, um die mindestens eine Funktion des Produktionssystems zu testen.
Klausel 17. Verfahren nach den Klauseln 14 bis 16, ferner umfassend Verhindern, über die mindestens eine Rechenvorrichtung, einer weiteren Zustandsänderung, die durch die Ausführung der mindestens einen Funktion des Produktionssystems unter Verwendung des mindestens einen Plugins verursacht wird.
Klausel 18. Verfahren nach den Klauseln 14 bis 17, ferner umfassend Blockieren, über die mindestens eine Rechenvorrichtung, mindestens eines Teils der Ausführung der mindestens einen Funktion des Produktionssystems unter Verwendung des mindestens einen Plugins.
Klausel 19. Verfahren nach Klausel 18, ferner umfassend Bereitstellen von simulierten Daten über die mindestens eine Rechenvorrichtung, die einer Simulation des mindestens einen Teils der Ausführung der mindestens einen Funktion des Produktionssystems unter Verwendung des mindestens einen Plugins entsprechen.
Klausel 20. Verfahren nach den Klauseln 14 bis 19, wobei das Drittanbietersystem einem Einkaufssystem eines Drittanbieters entspricht, das Produktionssystem einem Bestellungsaufgabe- und -erfüllungssystem eines E-Commerce-Anbieters entspricht und die durch die Integration des Drittanbietersystem bereitgestellten Daten einer Testbestellung entsprechen.

Es ist hervorzuheben, dass die vorstehend beschriebenen Ausführungsformen der vorliegenden Offenbarung nur mögliche Beispiele für Umsetzungen sind, die lediglich für ein eindeutiges Verständnis der Grundsätze der Offenbarung dargelegt sind. Viele Variationen und Modifikationen können an der (bzw. den) vorstehend beschriebenen Ausführungsform(en) vorgenommen werden, ohne wesentlich vom Geist und von den Grundsätzen der Offenbarung abzuweichen. Sämtliche derartige Modifikationen und Variationen sollen im Umfang dieser Offenbarung hierin eingeschlossen und durch die folgenden Ansprüche geschützt sein.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 17/093565 [0001]
US 63/090618 [0001]

Claims

Nichtflüchtiges computerlesbares Medium, das ein Programm verkörpert, das auf mindestens einer Rechenvorrichtung ausführbar ist, wobei das Programm bei Ausführung die mindestens eine Rechenvorrichtung mindestens zu Folgendem veranlasst: Empfangen einer Anforderung zum Testen einer Integration eines durch einen Drittanbieter betriebenen Einkaufssystems mit einem durch einen E-Commerce-Anbieter und in Live-Produktion betriebenen Bestellungsaufgabe- und -erfüllungssystem; Aktivieren mindestens eines Test-Plugins, das ein oder mehrere Attribute in Bestelldaten des Bestellungsaufgabe- und -erfüllungssystems einführt, wobei das eine oder die mehreren Attribute die Bestelldaten als Testdaten markieren, die von dem Bestellungsaufgabe- und -erfüllungssystem zu verarbeiten sind; Ausführen mindestens einer Funktion des Bestellungsaufgabe- und -erfüllungssystems durch das mindestens eine Test-Plugin unter Verwendung einer Testbestellung, die durch die Integration des Einkaufssystems bereitgestellt wird; Melden eines Ergebnisses darüber, wie das Bestellungsaufgabe- und -erfüllungssystem die Testbestellung verarbeitet, indem es die mindestens eine Funktion durch das mindestens eine Test-Plugin ausführt.
Nichtflüchtiges computerlesbares Medium nach Anspruch 1, wobei das mindestens eine Test-Plugin eine Warenbestandsreservierung bzw. Bestandsreservierung rückgängig macht, die dem Ausführen der mindestens einen Funktion unter Verwendung der Testbestellung zugeordnet ist, und wobei das mindestens eine Test-Plugin die Erfüllung einer Sendung, die dem Ausführen der mindestens einen Funktion unter Verwendung der Testbestellung zugeordnet ist, blockiert.
System, umfassend: mindestens eine Rechenvorrichtung; und einen Testmodusdienst, der in der mindestens einen Rechenvorrichtung ausführbar ist, wobei der Testmodusdienst bei Ausführung die mindestens eine Rechenvorrichtung mindestens zu Folgendem veranlasst: Empfangen einer Anforderung zum Testen einer Integration eines Drittanbietersystems mit einem Produktionssystem; Aktivieren mindestens eines Plugins, mindestens eine Funktion des Produktionssystems zu testen, wobei das Aktivieren des mindestens einen Plugins Daten, die durch das Produktionssystem verarbeitet werden, als Testdaten markiert; Ausführen der mindestens einen Funktion des Produktionssystems unter Verwendung des mindestens einen Plugins und der Daten, die durch die Integration des Drittanbietersystems bereitgestellt werden; und Melden eines Ergebnisses darüber, wie das Produktionssystem die mindestens eine Funktion ausführt, die dem mindestens einen Plugin zugeordnet ist, unter Verwendung der Testdaten.
System nach Anspruch 3, wobei die Integration des Drittanbietersystems dazu konfiguriert ist, während des Testens mit dem Produktionssystem zu kommunizieren.
System nach Anspruch 3 oder 4, wobei der Testmodusdienst ein Selbstbedienungstesten der Integration des Drittanbietersystems ohne manuellen Eingriff durch einen Bediener des Produktionssystems bereitstellt.
System nach einem der Ansprüche 3 bis 5, wobei das Produktionssystem eine Vielzahl von Komponenten beinhaltet, die in einer Pipeline angeordnet ist, um die Daten zu verarbeiten, die durch die Integration des Drittanbietersystems bereitgestellt werden.
System nach einem der Ansprüche 3 bis 6, wobei die Anforderung zum Testen der Integration ein bestimmtes Testszenario angibt und der Testmodusdienst ferner die mindestens eine Rechenvorrichtung dazu veranlasst, das mindestens eine Plugin als eine Teilmenge einer Vielzahl von Plugins mindestens teilweise auf Grundlage des jeweiligen Testszenarios zu identifizieren.
System nach Anspruch 7, wobei der Testmodusdienst ferner die mindestens eine Rechenvorrichtung mindestens dazu veranlasst, eine Benutzerschnittstelle zu generieren, die eine Benutzerauswahl des jeweiligen Testszenarios aus einer Vielzahl von möglichen Testszenarien erleichtert.
System nach einem der Ansprüche 3 bis 8, wobei das mindestens eine Plugin eine Zustandsänderung umkehrt, die durch die Ausführung der mindestens einen Funktion des Produktionssystems verursacht wird.
System nach einem der Ansprüche 3 bis 9, wobei die mindestens eine Funktion des Produktionssystems bei Ausführung normalerweise eine nicht umkehrbare Zustandsänderung umsetzt und das mindestens eine Plugin die nicht umkehrbare Zustandsänderung blockiert.
System nach einem der Ansprüche 3 bis 10, wobei das Drittanbietersystem einem Einkaufssystem eines Drittanbieters entspricht, das Produktionssystem einem Bestellungsaufgabe- und -erfüllungssystem eines E-Commerce-Anbieters entspricht und die durch die Integration des Drittanbietersystem bereitgestellten Daten einer Testbestellung entsprechen.
Verfahren, umfassend: Empfangen, über mindestens eine Rechenvorrichtung, einer Anforderung zum Testen einer Integration eines Drittanbietersystems mit einem Produktionssystem; Ausführen, über mindestens eine Rechenvorrichtung, von mindestens einer Funktion des Produktionssystems unter Verwendung von mindestens einem Plugin und von Daten, die durch die Integration des Drittanbietersystems bereitgestellt werden; Umkehren, über die mindestens eine Rechenvorrichtung, einer Zustandsänderung, die durch die Ausführung der mindestens einen Funktion unter Verwendung des mindestens einen Plugins verursacht wurde; und Melden, über die mindestens eine Rechenvorrichtung, eines Ergebnisses darüber, wie das Produktionssystem die mindestens eine Funktion ausführt, die dem mindestens einen Plugin zugeordnet ist.
Verfahren nach Anspruch 12, ferner umfassend Generieren, über die mindestens eine Rechenvorrichtung, einer Benutzerschnittstelle, die eine Benutzerauswahl eines bestimmten Testszenarios aus einer Vielzahl möglicher Testszenarien erleichtert.
Verfahren nach Anspruch 12 oder 13, ferner umfassend Aktivieren des mindestens einen Plugins über die mindestens eine Rechenvorrichtung, um die mindestens eine Funktion des Produktionssystems zu testen.
Verfahren nach einem der Ansprüche 12 bis 14, ferner umfassend mindestens einen der folgenden Schritte: Verhindern, über die mindestens eine Rechenvorrichtung, einer weiteren Zustandsänderung, die durch die Ausführung der mindestens einen Funktion des Produktionssystems unter Verwendung des mindestens einen Plugins verursacht wird; oder Blockieren, über die mindestens eine Rechenvorrichtung, mindestens eines Teils der Ausführung der mindestens einen Funktion des Produktionssystems unter Verwendung des mindestens einen Plugins.