DE202011110313U1

DE202011110313U1 - Vorrichtung für dynamische Endpunktgeneratoren und dynamisches Entdecken und Brokerage von Remote Objekten

Info

Publication number: DE202011110313U1
Application number: DE202011110313U
Authority: DE
Original assignee: Sourcecode Technology Holdings Inc
Current assignee: K2 Software Inc
Priority date: 2011-09-21
Filing date: 2011-09-21
Publication date: 2013-06-25
Anticipated expiration: 2021-09-22

Abstract

Computerlesbares Medium, auf dem Instruktionen zum Erzeugen eines dynamischen Endpunkts gespeichert sind, die einem Client-Gerät ermöglichen ein Geschäftsobjekt weiterzuverarbeiten, wobei der Endpunkt eine Adresse, eine Binding, und einen Contract umfasst, wobei die Instruktionen ein Computergerät veranlassen: Laden einer Definition des Geschäftsobjekts, wobei die Definition Eigenschaften und Verfahren aufweist; Iterieren durch die Definition; und Zuordnen der Definition zu Endpunkt-unterstützten Protokollen, wobei das Zuordnen umfasst: (i) Zuordnen der Geschäftsobjekt Eigenschaften zu Contractsdaten, (ii) Zuordnen der Geschäftsobjekt Verfahren zu Betriebsdaten; und (iii) Sicherstellen, dass Geschäftsobjekt Verfahrensignaturen Endpunkt-unterstützte Eingaben und Ausgaben aufweisen; wobei der Endpunkt als Antwort auf mindestens eines von (a) die Client-Gerät fragt das Geschäftsobjekt ab, (b) das Geschäftsobjekt wird erzeugt und (c) das Geschäftsobjekt wird aktualisiert, erzeugt wird.

Description

Technisches Gebiet
Die vorliegende Anmeldung betrifft dynamische Endpunktgeneratoren im Allgemeinen, und insbesondere eine Vorrichtung für dynamische Endpunktgeneratoren, die einen Endpunkt für Geschäftsobjekte automatisch veröffentlichen, so dass Remote-Client-Geräte Geschäftsobjekte einfach entdecken und auf diese zugreifen können.
Hintergrund
Da in Organisationen die Zahl an Informationsquellen zunimmt, wird es zunehmend schwierig für Verbraucher bzw. Abnehmer der Informationen, auf sie unter Betreff auf herkömmlichen Geschäftsobjekte, auf logische und strukturierte Art zuzugreifen, die den Verbrauchern in ihren Organisationen (beispielsweise als Kunde, Vermögen, Verkäufer, Personal, etc.) gut bekannt ist. Daten vorhandener Systeme werden für gewöhnlich auf eine äußerst technische Art zur Verfügung gestellt, die bedeutende technische und entwicklerische Kenntnisse benötigt, damit sie nicht-technischen Nutzern in der Organisation verdeutlicht wird. Nicht-technische Nutzer müssen in die Lage versetzt werden, Informationen zu einer logischen Geschäftsobjektdefinition hinzuzufügen, ohne technische und entwicklerische Kenntnisse einzubeziehen. Sowohl technische als auch nicht-technische Nutzer von Daten müssen in die Lage versetzt werden, auf ihre Informationen von zahlreichen Daten-/Informationsquellen zuzugreifen, die in der Art eines Geschäftsobjekts strukturiert sind, während die Flexibilität zusätzliche Informationsdefinitionen zu den vorhandenen Geschäftsobjekten zuzufügen oder neue Geschäftsobjekte aus vorhandenen oder neuen Datenquellen zu erzeugen immer noch beibehalten wird, ohne die Entwicklung schlüsselfertiger Lösungen zu erfordern.
Vorhandene Enterprise Application Integration (EAI) Systeme, die mit Entwicklungswerkzeugen kombiniert sind, können zur Entwicklung von maßgeschneiderten Entwicklungslösungen verwendet werden, die den Zugriff auf Daten und Informationen einfacher gestalten, wobei diese Lösungen allerdings für gewöhnlich fest eingebaut sind und bedeutende technische und entwicklerische Kenntnisse zur Instandhaltung und Anpassung im Lauf der Zeit erfordern. Darüber hinaus werden Personen, die mit Informationen arbeiten, aufgrund der statischen Geschäftsformen und den ihnen vorgezeigten Informationen durch lösungsbasierende oder maßgeschneiderte Entwicklungsanwendungen, die sie täglich verwenden, eingeschränkt. Des Weiteren stellen vorhandene Automatisierungswerkzeuge für Prozesse kein ausreichendes Niveau an gestalterischen Werkzeugen und Konzepten bereit, um sowohl technisch als auch nicht-technischen Nutzern es zu ermöglichen, eine vollständige Geschäftsprozesslösung in einer einzigen gestalterischen/automatischen Werkzeugumgebung abzufassen.
Diese Schwierigkeiten können durch Verwendung von Enterprise Application Integration (EAI) Quellen (bspw. EAI Software, Web Dienste, Anwendung API) gelöst werden, um Framework auf höherer Ebene (beispielsweise Runtime Broker und Adapter Dienste) mit bezogenen Lösungskomponenten (beispielsweise Benutzeroberflächen und Werkzeugbereitstellung) bereitzustellen, die es technischen und nicht-technischen Nutzern ermöglicht, logische Geschäftsobjekte abzufassen, die Datendefinitionen (beispielsweise Kundenname, Nachname, etc.) und Maßnahmen oder Verfahren (beispielsweise speichern, laden, löschen) von vorhandenen oder neuen Datenquellen umfassen. Nutzer können Daten von zahlreichen Quellen in eine einzelne Geschäftsobjektdefinition kombinieren, die Definitionen für Daten und Verfahren/Maßnahmen umfasst. Das logische Geschäftsobjekt ist ein smartes Objekt (Smart Object), das eine einzelne logische Datenstruktur und Ansicht des Geschäftsobjekts ebenso wie einen einzelnen Satz logischer Verfahren herausstellt, die mit dem Geschäftsobjekt zusammenhängen. Das Geschäftsobjekt ist dynamisch und seine Definition kann entweder durch Hinzufügen oder Entfernen von Daten oder Maßnahmen geändert werden, ohne die Notwendigkeit technische oder entwicklerische Mittel einzubeziehen, um die gegenwärtigen Geschäftsobjekte zu rekonfigurieren oder rekompilieren.
Wurde jedoch einmal ein dynamisches Geschäftsobjekt erzeugt, kann darauf nicht von Remote-Client-Geräten zugegriffen und dieses nicht weiterverarbeitet werden. Technologien von heute erfordern, dass vor einer Weiterverarbeitung des Geschäftsobjekts durch vorhandene Web Diensttechnologien ein Endpunkt definiert werden muss. Ein Endpunkt wird verwendet, um die Interaktionserfordernisse zwischen dem Client-Gerät und dem Geschäftsobjekt zu bestimmen. Das Client-Gerät sendet beispielsweise eine Nachricht an den Endpunkt des Geschäftsobjekts, wenn die Verwendung des Geschäftsobjekts erwünscht ist, und die Nachricht wird gemäß den durch den Endpunkt bestimmten Informationen formatiert. Ein Geschäftsobjekt kann zahlreiche Endpunkte aufweisen, die Clients verschiedene Wege ermöglichen das Geschäftsobjekt weiterzuverarbeiten.
Ein Endpunkt wird für gewöhnlich durch eine Adresse, eine Binding, und einen Contract definiert. Eine Adresse ist die Stelle, an der sich der Endpunkt befindet. Eine Binding führt auf, wie ein Geschäftsobjekt weiterverarbeitet werden kann, wie beispielsweise das Protokoll oder Informationscodierung. Einen Contract für jedes Objekt führt die Operationen auf denen gegenüber das Geschäftsobjekt ausgesetzt wird. All diese Informationen müssen spezifiziert werden bevor ein Geschäftsobjekt von einem Remote-Client-Gerät verwendet werden kann.
Dieses Vorgehen bringt mehre Schwierigkeit mit sich. Der Contract muss für jedes Objekt von Hand erzeugt werden. Da der Endpunkt den Contract umfasst, muss der Endpunkt ebenso für jedes Objekt erzeugt werden. Das Erzeugen eines Contracts (und daher des Endpunkts) von Hand kann teuer und zeitaufwändig sein und ist empfänglich gegenüber Nutzerfehlern. Der Endpunkt kann ferner veraltern wenn er nicht aktualisiert wird sobald das Geschäftsobjekt aktualisiert wird und der Nutzer kann sich auf Endpunktinformationen verlassen, die das Geschäftsobjekt nicht genau wiedergeben.
Es besteht daher ein Bedarf im Fachbereich an einem effizienteren, sparsamen und genauen Weg, der Client-Geräten ermöglicht auf Remote-Geschäftsobjekte zuzugreifen und sie weiterzuverarbeiten.
Zusammenfassung
Das hierin offenbarte Verfahren und die Vorrichtung ermöglicht technisch und nichttechnischen Nutzern Objekte zu entdecken, darauf zugreifen und weiterzuverarbeiten bzw. benutzen, ohne die Notwendigkeit einen Endpunkt für jedes Objekt von Hand zu erzeugen. Ein Endpunkt kann irgendeine Information sein, die ein Client-Gerät benötigt bevor das Client-Gerät mit einem Geschäftsobjekt in Verbindung treten kann. Der Client kann anfordern bzw. abfragen bzw. beantragen ein Geschäftsobjekt weiterzuverarbeiten oder zu verwenden, und die Endpunktinformation, wie beispielsweise der Contract, wird automatisch erstellt und veröffentlicht. Dem Client erscheint es, ob ein Endpunkt bereits vorhanden gewesen wäre, obgleich er erzeugt wurde, als der Client das Geschäftsobjekt anforderte. Wahlweise wird der Endpunkt automatisch erstellt und veröffentlicht, wenn das Geschäftsobjekt erzeugt wird.
Dieser gesamte Vorgang findet ohne das Vorhandensein der gegenwärtig geschriebenen Adresse, Binding, oder Contractinformation, statt, die das Remote-Objekt darstellen. Die Endpunktinformation ist dynamisch und stellt die aktuellste Information über das Geschäftsobjekt genau dar. Ein Client-Gerät kann auf diese Art einen Endpunkt für ein Geschäftsobjekt einfach entdecken und beantragen.
Zusätzliche Merkmale und Vorteile werden hierin beschrieben, und werden aus der nachstehend aufgeführten ausführlichen Beschreibung und den Figuren offensichtlich.
Kurze Beschreibung der Figuren
Die 1 ist ein High-Level Blockdiagramm eines beispielhaften Kommunikationssystems.
Die 2 ist ein ausführlicheres Blockdiagramm, das ein Beispiel eines Computergeräts zeigt.
Die 3 ist ein Blockdiagramm, das beispielhafte Verbindungen zwischen mehreren Datenquellen und einer elektronischen Form über einen Objektbroker zeigt.
Die 4 ist ein Blockdiagramm, das beispielhafte Verbindungen zwischen Datenquelle und Geschäftsobjekten zeigt.
Die 5 ist eine ausführlichere Ansicht einer beispielhaften Kundenbestellseite und den damit zusammenhängenden Verbindungen mit einem Kundenspezifische Geschäftsobjekt und einem Bestell-Geschäftsobjekt.
Die 6 ist ein Flussdiagramm eines beispielhaften Objektbrokerprozesses.
Die 7 ist ein Flussdiagramm eines beispielhaften Bildungsprozesses.
Die 8 ist ein Screenshot einer beispielhaften Workflow Erstellungshilfe bzw. Entwerfertools, die einem Nutzer die Definition einer Ressourcenkarte ermöglicht.
Die 9 ist ein Screenshot einer beispielhaften Workflow Erstellungshilfe, die einem Nutzer die Definition einer Prozesskarte ermöglicht.
Die 10 ist eine beispielhafte Prozesskarte, in der ein örtlich begrenzter Bereich der Prozesskarte hervorgehoben ist.
Die 11 ist ein Screenshot eines beispielhaften Activity Strips.
Die 12 ist ein Screenshot eines beispielhaften Setup Wizards in einem teilweise gedrehten Zustand.
Die 13 ist ein Screenshot des beispielhaften Setup Wizards in einem vollständig gedrehten Zustand.
Die 14 ist ein Screenshot des beispielhaften Setup Wizards mit einem Popup Fenster.
Die 15 ist ein Flussdiagramm eines beispielhaften Setup Wizard Prozesses.
Die 16 ist ein Diagram, das ein Beispiel eines Systemen zeigt, in dem ein dynamischer Endpunkte Generator implementiert ist, um einer Anwendung die Weiterverarbeitung von Geschäftsobjekten zu ermöglichen.
Die 17 ist ein Flussdiagramm, das ein beispielhaften Prozess eines Erzeugens, Einsetzens und Veröffentlichens eines Geschäftsobjekts, ein automatisches Erzeugen eines dynamischen Endpunkts für das Geschäftsobjekt, und einem Client-Gerät zu ermöglichen das Geschäftsobjekt unter Verwebdung des dynamischen Endpunkts weiterzuverarbeiten.
Die 18 ist ein Screenshot einer beispielhaften Erstellungshilfe, die einem Nutzer ermöglicht ein leeres Geschäftsobjekt zu erzeugen.
Die 19 ist ein Screenshot eines beispielhaften Produkte Geschäftsobjekt.
Die 20 ist ein Screenshot eines Beispiels von Geschäftsobjekteigenschaften.
Die 21 ist ein Screenshot eines Beispiels eines Einsetzens eines Geschäftsobjekts.
Die 22 ist ein Screenshot eines Beispiels eines Veröffentlichens eines Geschäftsobjekts auf einem Server.
Die 23 ist ein Flussdiagramm, das ein Beispiel eines Konfigurierens von Endpunkten für ein Geschäftsobjekt zeigt.
Die 24 ist ein Screenshot eines Beispiels eines Dienstes, der Clients ermöglicht mit einem Geschäftsobjekt zusammenhängende Verfahren zu nutzen.
Die 25 ist ein Screenshot eines Beispiels von WCF und REST Endpunkten.
Die 26 ist ein Screenshot eines Beispiels eines Codes, der zum Testen verwendet werden kann, ob ein Dienst funktioniert.
Die 27 ist ein Screenshot eines Beispiels eines WCF Endpunkts in WSDL.
Die 28 ist ein Screenshot eines Beispiels für ein Erzeugen einer neuen Client-Geräte Anwendung.
Die 29 ist ein Screenshot eines Beispiels eines Hinzufügens einer Service Referenz.
Die 30 ist ein Screenshot eines Beispiels einer eines Clients, der mit einem Geschäftsobjekt unter Verwendung eines dynamischen Endpunkts kommuniziert.
Die 31 ist ein Screenshot eines Beispiels von Geschäftsobjekt Metadaten, die einem Client-Gerät bereitgestellt werden.
Die 32 ist ein Screenshot eines Beispiels von Geschäftsobjekt Daten und einem Verfahren, die einem Client-Gerät bereitgestellt werden.
Die 33 ist ein Screenshot eines Beispiels eines Client-Geräte ohne Objektaufnahme bzw. Object records.
Die 34 ist ein Screenshot eines Beispiels einer Aufnahme bzw. Records eines Geschäftsobjekts, das unter Verwendung eines dynamischen Endpunkts erzeugt wurde.
Die 35 ist ein Screenshot eines Beispiels zahlreicher Aufnahmen von Geschäftsobjekten, die unter Verwendung eines dynamischen Endpunkts erzeugt wurden.
Die 36 ist ein Screenshot eines Beispiels eines Zugriffs auf ein Verfahren für ein Objekt unter Verwendung eines REST Endpunkts.
Die 37 ist ein Screenshot eines Beispiels eines Zugriffs auf ein anderes Verfahren für ein Objekt unter Verwendung eines REST Endpunkts.
Die 38 ist ein Screenshot eines Beispiels eines Zugriffs auf ein Verfahren für ein Objekt unter Verwendung eines REST Endpunkts in XML.
Die 39 ist ein Screenshot eines Beispiels eines Zugriffs auf ein Verfahren für ein Objekt unter Verwendung eines REST Endpunkts in einem Atom Feed.
Ausführliche Beschreibung
Das vorliegende System ist in einem Netzwerk Kommunikationssystem am einfachsten umzusetzen. Ein High-Level Blockdiagramm eines beispielhaften Netzwerk Kommunikationssystem 100 wird in der 1 gezeigt. Das gezeigte System 100 umfasst ein oder mehr Client-Geräte 102, einen oder mehr Router 106, und mehrere verschiedener Datenquellen 108, einschließlich Datenbank Server 110 und/oder Datenbanken 112. Datenübertragung zu/von den Client-Geräten 102 von/zu der Datenquelle 108 wird durch einen oder mehr Objektbroker Server 114 bewerkstelligt. Jede dieser Vorrichtungen kann mit jeder anderen über eine Verbindungen mit einem oder mehreren Kommunikationskanälen 116, wie dem Internet und/oder irgendwelchen anderen Daten Netzwerken, einschließlich, aber nicht darauf begrenzt, irgendeinem flächendeckenden Netzwerk oder lokalem Netzwerk, in Verbindung treten. Es ist klar, dass irgendeine der hierin beschriebenen Vorrichtungen miteinander unmittelbar anstelle über ein Netzwerk verbunden werden kann.
Die Datenquelle 108 speichert mehrere Dateien, Programme, und/oder Webseiten in einer oder mehreren Datenbanken 112 zur Verwendung durch die Client-Geräte 102. Eine Datenquelle kann beispielsweise Kundeninformationen speichern. Die Datenquelle 108 kann mit einem Datenbank Server 110 unmittelbar und/oder über eines oder mehrere Netzwerke verbunden sein.
Eine Datenquelle 108 und/oder ein Objektbroker Server 114 können mit einer großen Zahl anderer Vorrichtungen interagieren. Jede Datenquelle 108 und/oder ein Objektbroker Server 114 ist demgemäß für gewöhnlich ein High End Computer mit einer großen Speicherkapazität, einem oder mehreren schnellen Mikroprozessoren, und einer oder mehrerer Hochgeschwindigkeits-Netzwerkverbindungen. Im Gegenzug umfasst jedes Client-Gerät 102, in Bezug auf einen gewöhnlichen Server, für gewöhnlich eine geringere Speicherkapazität, einen einzelnen Mikroprozessor und eine einzelne Netzwerkverbindung.
Ein ausführlicheres Blockdiagramm der elektrischen Systeme eines Computergeräts (bspw., Hand-Client-Geräte 102, Personal Computer Client-Geräte 102, Routers 106, Datenbank Servers 110, und/oder Objektbroker Servers 114) ist in der 2 gezeigt. Obgleich die elektrischen Systeme dieser Computergeräte ähnlich sein können, sind die strukturellen Unterschiede zwischen diesen Vorrichtungen gut bekannt. Ein gewöhnliches Hand-Client-Gerät 102 ist beispielsweise klein und leicht im Vergleich zu einem gewöhnlichen Datenbank Server 110.
Das beispielhafte Computergerät 102, 106, 110, 114 umfasst eine Haupteinheit 202, die vorzugsweise einen oder mehrere Prozessoren 204 umfasst, die durch einen Adress-/Datenbus 206 mit einer oder mehreren Speichervorrichtungen 208 elektrisch verbunden sind, andere Computerschaltungsanordnungen 210 und eine oder mehrere Schnittstellenschaltungen 212. Der Prozessor 204 kann irgend ein geeigneter Prozessor sein, wie beispielsweise ein Mikroprozessor der INTEL PENTIUM^® Familie von Mikroprozessoren. Der Speicher 208 umfasst vorzugsweise flüchtigen Speicher und permanenten Speicher. Der Speicher 208 speichert vorzugsweise ein Softwareprogramm, das mit den anderen Vorrichtungen in dem System 100 wie nachstehend beschrieben interagiert. Dieses Programm kann durch den Prozessor 204 in irgendeiner geeigneten Art ausgeführt werden. Der Speicher 208 kann ebenso digitale Daten speichern, die Dokumente, Dateien, Programme, Webseiten, etc. anzeigen, die von einem anderen Computergerät abgerufen und/oder über eine Eingabevorrichtung 214 geladen wurden.
Die Schnittstellenschaltung 212 kann unter Verwendung irgendeines geeigneten Schnittstellenstandards, wie beispielsweise einer Ethernet Schnittstelle und/oder einer Universal Serial Bus (USB) Schnittstelle, implementiert werden. Eine oder mehrere Eingabevorrichtungen 214 können mit der Schnittstellenschaltung 212 zur Eingabe von Daten und Befehlen in die Haupteinheit 202 verbunden werden. Die Eingabevorrichtung 214 kann beispielsweise eine Tastatur, Maus, Touchscreen, Trackpad, Trackball, Isopoint, und/oder ein Spracherkennungssystem sein.
Eine oder mehrere Anzeigen, Drucker, Lautsprecher, und/oder andere Ausgabevorrichtungen 216 können mit der Haupteinheit 202 über die Schnittstellenschaltung 212 verbunden sein. Die Anzeige 216 eine Bildschirmröhre (CRT), Flüssigkristallanzeigen (LCD) oder irgendeine andere Art von Anzeige sein. Die Anzeige 216 erzeugt visuelle Anzeigen von Daten, die währen dem Betrieb des Computergeräts 102, 106, 110, 114 erzeugt wurden. Die Anzeige 216 kann beispielsweise zum Anzeigen von Webseiten verwendet werden, die von dem Objektbroker Server 114 empfangen werden, einschließlich von Daten von zahlreichen Datenquellen 108. Die visuellen Anzeigen können Eingabeaufforderungen zur menschlichen Eingabe, Laufzeitstatistiken, berechnete Werte, Daten, etc. umfassen.
Eine oder mehrere Speichervorrichtungen 218 können ebenso über die Schnittstellenschaltung 212 mit der Haupteinheit 202 verbunden sein. Eine Festplatte, CD Laufwerk, DVD Laufwerk, und/oder andere Speichervorrichtungen können beispielsweise mit der Haupteinheit 202 verbunden sein. Die Speichervorrichtungen 218 können irgendeine Art geeigneter Daten speichern.
Das Computergerät 102, 104 kann ebenso Daten mit anderen Netzwerk-Vorrichtungen 220 über einen Verbindung mit dem Netzwerk 116 austauschen. Die Netzwerkverbindung kann irgendeine Art einer Netzwerkverbindung sein, wie beispielsweise einer Ethernet Verbindung, Digital Subscriber Line (DSL), Telefonverbindung, koaxial Kabel, etc. sein. Es kann erforderlich sein, dass sich Nutzer des System 100 bei einem oder mehreren der Computergerät 102, 106, 110, 114 registrieren. Jeder Nutzer kann in diesem Fall eine Nutzerkennung (bspw. eine E-Mail Adresse) und ein Passwort wählen, die für die Aktivierung der Dienste erforderlich sein können. Die Nutzerkennung und das Passwort kann durch das Netzwerk 116 unter Verwendung einer Verschlüsselung verteilt werden (pass across), die in dem Webbrowser des Nutzers eingebaut bzw. installiert ist. Die Nutzerkennung und/oder das Passwort können wahlweise durch das Computergerät 102, 106, 110, 114 zugeteilt werden.
In einer Ausführungsform sieht und/oder ändert ein Nutzer an einem Client-Gerät 102 Daten von mehreren verschiedenen Datenquellen 108 über ein interaktives elektronisches Formular. Ein beispielhaftes Blockdiagramm, das Verbindungen zwischen mehreren Datenquellen 108 und einem elektronischen Formular 302 über ein Objektbroker Prozess 304 zeigt, ist aus 3 ersichtlich. Der Objektbroker Prozess 304 (nachstehend ausführlich unter Bezug auf 6 beschrieben) kompiliert im Allgemeinen Daten in einer Vielzahl nativer Formate von den verschiedenen Datenquellen 108 (bspw. verschiedenen Altdatenbank Systemen) in herkömmliche Geschäftsobjekte 306, 308 (bspw. in ein deklaratives Format, wie beispielsweise Extensible Markup Sprache (XML)). Ein Nutzer kann anschließend die Daten unter Verwendung eines oder mehrere elektronischer Formulare 302, 310, 312 ansehen. Darüber hinaus kann der Nutzer die Daten manipulieren und/oder Daten über die elektronischen Formulare 302, 310, 312 hinzufügen. Der Objektbroker Prozess 304 akzeptiert in einem solchen Fall die Daten über die Geschäftsobjekte 306, 308 und speichert die Daten in dem korrekten nativen Format zurück auf die Datenquelle 108.
Die Datenquelle 108 umfasst in diesem Beispiel eine Enterprise Resource Planning (ERP) Datenquelle 314, eine Kunde Relationship Management (CRM) Datenquelle 316, eine kundenspezifische Datenquelle 318, eine Add-On bzw. Erweiterungs-Datenquelle 320 und eine Funktionsdatenquelle 322. Das System umfasst darüber hinaus ein Rollenservice 323 und ein Objekt Daten Speicher 325. Eine ERP Datenquelle 314 speichert für gewöhnlich Daten, die ausstehende Konten, zahlbare Konten, Inventar, etc. betreffen. Eine CRM Datenquelle 316 speichert für gewöhnlich Daten, die Kundenkontakte, Angebote, Bestellungen, etc. betreffen. Eine kundenspezifische Datenquelle 318 ist eine Datenquelle 108, die nicht als ein übliches kommerzielles Produkt angesehen wird. Ein Geschäft bzw. Unternehmen kann beispielsweise eine kundenspezifische Datenquelle aufweisen, die Echtzeit-Herstellungsinformationen speichert. Einige Datenquellen 108 können einen Zwischenserver für die die Kommunikation verwenden. Die ERP Datenquelle 314 verwendet beispielsweise einen BizTalk Server 324.
Die Add-On Datenquelle 320 speichert Daten, die mit Formularfeldern zusammenhängen, die durch den Nutzer hinzugefügt werden und nicht durch eine der anderen Datenquellen 108 zur Verfügung gestellt werden. Ein Geschäft kann beispielsweise ein Kartenprogramm für häufige Kunden anlassen und muss eine Kartennummer für jeden Teilnehmer speichern. Ein Nutzer kann daher ein Zahlenfeld für häufige Kunden einem vorhandenem Formular hinzufügen, das Altdaten enthält. Da die vorhandene Datenquelle 108 in diesem Beispiel kein Zahlenfeld für häufige Kunden umfasst, werden das Zahlenfeld für häufige Kunden und dazugehörige Daten durch die Add-On Datenquelle 320 gespeichert.
Um Daten in einer bestimmten Datenquelle 108 zu manipulieren, ruft der Objektbroker Prozess 304 vorzugsweise Verfahren ab, die in die assoziierten Datenquelle 108 enthalten sind. Beispielsweise umfasst jede Datenquelle 108 für gewöhnlich Verfahren, um Daten auf/von der Datenquelle 108 (bspw. kann die CRM Datenquelle ein ”LoadContact” Verfahren wie ausführlich nachstehend beschrieben unterstützen) zu speichern/abzufragen. Das System 300 ermöglicht darüber hinaus einem Nutzer to ihre eigenen Funktionen abzufassen. Ein Nutzer hat beispielsweise Bedarf bestimmten Verbrauchern eine Ermäßigung geben. Es kann jedoch sein, das die vorhandene Datenquelle 108 ein Verfahren zum Berechnen der Ermäßigung nicht umfasst. Der Nutzer kann demgemäß eine ”CalcDiscount” Funktion wie nachstehend beschrieben abfassen. Vom Nutzer definierte Funktionen können Daten von mehr als einer Datenquelle 108 verwenden. Die Definitionen für diese Nutzer definierten Funktionen werden anschließend in der Funktions-Datenquelle 322 gespeichert.
Nutzer definierte Funktionen können unter Verwendung eines graphischen Nutzer Schnittstellenwerkzeugs erzeugt werden. Beispielhafte Parameter für eine Nutzer definierte Funktion können durch Auswahl einer graphischen Darstellung des mit einem Geschäftsobjekt zusammenhängenden Parameter definiert werden. Nutzer definierte Funktionen werden vorzugsweise als Code-Ausschnitte gespeichert. Code-Ausschnitte umfassen einen Strukturabschnitt, der die Funktion definiert, und einen Nutzer Schnittstellenabschnitt, der dem Nutzer einen Weg zum Testen der Funktion bereitstellt. Der Strukturabschnitt kann beispielsweise als XML gespeichert werden und der Nutzer Schnittstellenabschnitt kann als HTML in der gleichen Datei gespeichert werden.
Einige Nutzer definierte Funktionen können von Der Client-Geräten 102 ausgeführt werden, wodurch sich die Kommunikation dem Server 110, 114 verringert. Andere Nutzer definierte Funktionen können serverseitiges Ausführen erfordern. Ein Bestimmen wird vorzugsweise vorgenommen, ob eine bestimmte Funktion auf der Client Seite oder der Serverseite ausgeführt werden soll und ein Indikator dieses Bestimmens wird mit dem Funktions-Code-Ausschnitt gespeichert. Nutzer definierte Funktionen, die aus bestimmten, vordefinierten Urformen (bspw. Hinzufügen (add), Multiplizieren (multiply), Schleife (loop), weniger als (less than), etc.) errichtet wurden, können beispielsweise bestimmt werden von dem Client-Gerät 200 ausführbar zu sein, indes andere Nutzer definierte Funktionen, die Datenbanken Lookups (bspw. SQL Statements) umfassen, können bestimmt werden von einem Server 110, 114 ausführbar zu sein.
Aus der Perspektive eines Nutzers werden die Daten von der Datenquelle 108 (ebenso wie Daten, die aus Daten in der Datenquelle 108, bspw. eine Ermäßigung, berechnet werden) unter Verwendung eines oder mehrerer elektronischer Formulare 302, 310, 312 betrachtet. Der Nutzer kann darüber hinaus die Daten manipulieren und/oder Daten mittels der elektronischen Formulare 302, 310, 312 hinzufügen. Formulare 302, 310, 312 können in Seiten 302 kombiniert werden und in einem Formular können Daten aus mehr als einer Datenquelle 108 verwendet werden. Die Kundenbestellseite 302 kombiniert beispielsweise das Kundenkontaktformular 310 und das Bestelllistenformular 312 (wie ausführlich unter Bezug auf die 5 nachstehend beschrieben). Abschnitte der Formulare und/oder gesamte Formulare, die einen Teil einer größeren Seite bilden, können darüber hinaus gesperrt werden, so dass lediglich bestimmte Nutzer den Abschnitt des Formulars oder der Seite andern können.
Um Formulare 302, 310, 312 zu ermöglichen, die Daten aus verschiedenen Datenquellen 108 kombinieren, wird in dem System 300 ein Objektbroker Prozess 304 (ausführlich unter Bezug auf die 6 nachstehend beschrieben) und ein Formular-Prozess 326 (ausführlich unter Bezug auf die 7 nachstehend beschrieben) verwendet. Der Objektbroker Prozess 304 ist in einer Ausführungsform ein ASP Code, der auf dem Objektbroker Server 114 läuft, und der Formular-Prozess 326 ist ein JavaScript, das auf einem Client-Gerät 102 läuft. Der Objektbroker Prozess 304 kompiliert Daten in eine Vielzahl verschiedene native Formate aus den verschiedenen Datenquellen 108 in herkömmliche Geschäftsobjekte 306, 308 (bspw. XML Dateien). Der Objektbroker Prozess 304 akzeptiert darüber hinaus die Daten über die Geschäftsobjekte 306, 308 und speichert die Daten in dem korrekten nativen Format zurück auf die Datenquelle 108.
Bei dem Objektbroker Prozess 304 werden insbesondere mehrere Broker Dienste verwendet, um mit der Datenquelle 108 zu kommunizieren. Ein Broker-Service wird vorzugsweise für jede Datenquelle 108 verwendet. Der Objektbroker Prozess 304 umfasst in diesem Beispiel einen ERP Broker-Service 328, einen CRM Broker-Service 330, einen kundenspezifischen Broker-Service 332, einen Add-On Broker-Service 334 und einen Funktions-Broker-Service 336. Jeder Broker-Service 328, 330, 332, 334, 336 ist ausgestaltet mit der assoziierten Datenquelle 108 unter Verwendung der nativen Formate und Protokolle der Datenquelle zu kommunizieren.
Jeder Broker-Service 328, 330, 332, 334, 336 zeigt anschließend automatisch die Eigenschaften und Verfahren der assoziierten Datenquelle 108 als herkömmliche Eigenschaften und Verfahren 338 zur Verwendung durch die Geschäftsobjekte 306, 308. Der ERP Broker-Service 328 kommuniziert beispielsweise mit der ERP Datenquelle 314 über den BizTalk Server 324 und zeigt Eigenschaften und Verfahren der ERP Datenquelle 314 dem kundenspezifischen Geschäftsobjekt 306 und Bestell-Geschäftsobjekt 308 als XML Dateien. Falls neue Eigenschaften und/oder Verfahren von einer Datenquelle 108 zur Verfügung stehen, ermittelt der assoziiert Broker-Service vorzugsweise diese neuen Eigenschaften und/oder Verfahren und zeigt automatisch die neuen Eigenschaften und/oder Verfahren zur Verwendung durch die Geschäftsobjekte 306, 308. Die Geschäftsobjekte 306, 308 können einige oder alle der gezeigten Eigenschaften und Verfahren 338 umfassen. Jedes Geschäftsobjekt 306, 308 zeigt anschließend dem Formular-Prozess 326 seine einbezogenen Eigenschaften und Verfahren 340.
Der Formular-Prozess 326 ruft Geschäftsobjekt Verfahren 340 als Antwort ab, um Begebenheiten bzw. Termine zu bilden to form Begebenheiten und pflegt Daten aus den Geschäftsobjekt Eigenschaften 340 in die Formulare 302, 310, 312 ein. Ein Nutzer kann beispielsweise einen ”Load” (Lade) Button auf der Kundenbestellseite 302 betätigen, wodurch der Formular-Prozess 326 eines oder mehrere Verfahren 340 abruft, die durch die Geschäftsobjekte 306, 308 gezeigt werden. Dadurch wird wiederum der Objektbroker Prozess 304 veranlasst die geeigneten Daten von einer oder mehreren Datenquellen 108 abzufragen. Die Daten werden anschließend als Eigenschaften der Geschäftsobjekte 306, 308 zurückgegeben, und in dem Formular-Prozess 326 werden die Daten verwendet, um die Formulare 310, 312 zu befüllen.
Der Formular-Prozess 326 kann darüber hinaus Werte zu den Geschäftsobjekt Eigenschaften 340 speichern, und Verfahren abrufen, die neuen/geänderten Daten aufzuweisen, die über den Objektbroker Prozess 304 auf die geeignete Datenquelle 108 zurück gespeichert werden. Ein Formular kann beispielsweise einen neuen Wert für die neue Kundenadresse akzeptieren und ein (UpdateContact) Verfahren zum Aktualisieren des Kontakts abrufen, damit die neue Adresse in der geeigneten Datenquelle 108 gespeichert wird.
Ein ausführlicheres Blockdiagramm, dass diese Verbindungen zwischen der beispielhaften Datenquelle 108 und den beispielhaften Geschäftsobjekten 306, 308 zeigt wird in der 4 dargelegt. Das kundenspezifische Geschäftsobjekt 306 wird in diesem Beispiel mit der ERP Datenquelle 314 und der CRM Datenquelle 316 verbunden. Das Bestell-Geschäftsobjekt 308 wird mit der ERP Datenquelle 314, der Add-On Datenquelle 320 und der Funktions-Datenquelle 322 verbunden. Diese logischen Verbindungen können auf irgendeine geeignete Art definiert sein. Eine graphische Nutzer Schnittstelle kann beispielsweise verwendet werden, um einem Nutzer zu ermöglichen Verbindungslinien bzw. Verbindungen zwischen graphischen Darstellungen der Datenquelle 108 und graphischen Darstellungen der Geschäftsobjekte 306, 308 zu ziehen.
Diese logischen Verbindungen werden von dem Objektbroker Prozess 304 beibehalten. Beispielsweise werden Daten, um das Kundenkontaktformular 310 und das Bestellungslistenformular 312 zu befüllen, in das kundenspezifische Geschäftsobjekt 306 und durch den Objektbroker Prozess 304 aus den Datenquellen 108 in das Bestell-Geschäftsobjekt 308 verbracht. Ähnlich dazu werden durch den Objektbroker Prozess 304 neue und geänderte Daten von dem Kundenkontaktformular 310 und dem Bestellungslistenformular 312 von dem kundenspezifischen Geschäftsobjekt 306 und dem Bestell-Geschäftsobjekt 308 zu der Datenquelle 108 gesendet. Der Role-Service 323 kann darüber hinaus eine reduzierte Objekt Definition basierend auf diesen vollständigen Objekt Definitionen erzeugen. Der Role-Service 323 kann beispielsweise eine Aufgabe (role) n, die mit einem bestimmten Nutzer assoziiert ist, und mehrere autorisierte Eigenschaften und/oder Verfahren abfragen, die mit der Ausgabe assoziiert sind. Unautorisierte Eigenschaften und/oder Verfahren werden anschließend von der Geschäftsobjektdefinition entfernt (bspw. ist es einem Nutzer nicht gestattet zu dem kundenspezifischen Geschäftsobjekt zu schreiben bzw. etwas hinzuzufügen, daher werden das UpdateBalance und UpdateContact Verfahren entfernt).
Das beispielhafte kundenspezifische Geschäftsobjekt 306 umfasst eine Kunden ID (customer ID) Eigenschaft, eine Namen-Eigenschaft, eine Adressen-Eigenschaft, eine Außenstand-Eigenschaft, ein Belastungsausgleichs-Verfahren, ein Verfahren zum Aktualisieren des Kontos, ein Belastungskontakt-Verfahren, und ein Verfahren zum Aktualisieren des Kontakts. Die Kunden ID Eigenschaft in dem kundenspezifischen Geschäftsobjekt 306 wird mit der Kunden ID Eigenschaft in der ERP Datenquelle 314 und/oder der Kunden ID Eigenschaft in der CRM Datenquelle 316 verbunden. Die Namen-Eigenschaft und die Adressen-Eigenschaft in dem kundenspezifischen Geschäftsobjekt 306 werden mit der Namen-Eigenschaft und der Adressen-Eigenschaft in der CRM Datenquelle 316 verbunden. Die Außenstand-Eigenschaft in dem kundenspezifischen Geschäftsobjekt 306 wird mit der Außenstand-Eigenschaft in der ERP Datenquelle 314 verbunden. Das Belastungsausgleichs-Verfahren das Verfahren zum Aktualisieren des Kontos in dem kundenspezifischen Geschäftsobjekt 306 werden mit dem Belastungsausgleichs-Verfahren und dem Verfahren zum Aktualisieren des Kontos in der ERP Datenquelle 314 verbunden. Das Belastungskontakt-Verfahren und das Verfahren zum Aktualisieren des Kontakts in dem kundenspezifischen Geschäftsobjekt 306 werden mit dem Belastungskontakt-Verfahren und dem Verfahren zum Aktualisieren des Kontakts in der CRM Datenquelle 316 verbunden.
Das beispielhafte Bestell-Geschäftsobjekt 308 umfasst eine Bestellnummer-Eigenschaft, eine Kunden ID Eigenschaft, eine Lieferdatum-Eigenschaft, eine Steuer-Eigenschaft, eine Gesamt-Eigenschaft bzw. Summen-Eigenschaft (total property), eine Status-Eigenschaft, ein Verfahren zum Erzeugen einer Bestellung, ein Verfahren zum Bestellen einer Charge (load orders method), ein Verfahren zum Aktualisieren einer Bestellung, ein Verfahren zum Löschen einer Bestellung, ein Verfahren zum Berechnen einer Ermäßigung (calc discount method), und ein Verfahren zum Berechnen einer Steuer (calc tax method). Die Bestellnummer-Eigenschaft und die Status-Eigenschaft in dem Bestell-Geschäftsobjekt 308 werden mit der Bestellnummer-Eigenschaft und der Status-Eigenschaft in der ERP Datenquelle 314 verbunden. Die Kunden ID Eigenschaft in dem Bestell-Geschäftsobjekt 308 wird mit der Kunden ID Eigenschaft in der ERP Datenquelle 314 und/oder der Kunden ID Eigenschaft in der Add-On Datenquelle 320 verbunden. Die Lieferdatum-Eigenschaft, Steuer-Eigenschaft, und Summen-Eigenschaft in dem Bestell-Geschäftsobjekt 308 werden mit der Lieferdatum-Eigenschaft, Steuer-Eigenschaft, und Summen-Eigenschaft in der Add-On Datenquelle 320 verbunden. Das Verfahren zum Erzeugen einer Bestellung, Verfahren zum Bestellen einer Charge, Verfahren zum Aktualisieren einer Bestellung, und Verfahren zum Löschen einer Bestellung in dem Bestell-Geschäftsobjekt 308 werden mit dem Verfahren zum Erzeugen einer Bestellung, Verfahren zum Bestellen einer Charge, Verfahren zum Aktualisieren einer Bestellung, und Verfahren zum Löschen einer Bestellung in der ERP Datenquelle 314 verbunden. Das Verfahren zum Berechnen einer Ermäßigung und das Verfahren zum Berechnen einer Steuer in dem Bestell-Geschäftsobjekt 308 werden mit dem Verfahren zum Berechnen einer Ermäßigung und dem Verfahren zum Berechnen einer Steuer in der Funktions-Datenquelle 322 verbunden. Es ist klar, dass die Bezeichnungen der Eigenschaften und/oder Verfahren in der Datenquelle 108 nicht die gleichen wie die entsprechenden Bezeichnungen der Eigenschaften und/oder Verfahren in den Geschäftsobjekten 306, 308 sein müssen.
Eine ausführlichere Ansicht der Kundenbestellseite 302 und der assoziierten Verbindungen mit dem kundenspezifischen Geschäftsobjekt 306 und dem Bestell-Geschäftsobjekt 308 werden in der 5 gezeigt. Wenn der Nutzer in diesem Beispiel, einen Chargen (load) Button 502 betätigt, ruft die mit dem Formular-Prozess 326 assoziierte Binder-Software das Belastungskontakt-Verfahren des kundenspezifischen Geschäftsobjekt 306 und das Verfahren zum Bestellen einer Charge des Bestell-Geschäftsobjekts 308 ab. Der Formular-Prozess 326 unterstützt bei beiden Verfahrenabrufen den Wert des Kundennummerfelder 504 von dem Kundenkontaktformular 310. Der Formular-Prozess 326 kann wahlweise den Wert des Kundennummerfelder 504 von der Kunden ID Eigenschaft des kundenspezifischen Geschäftsobjekts 306 und/oder dem Bestell-Geschäftsobjekt 308 erhalten. Diese logischen Verbindungen können auf irgendeine geeignete Art definiert sein. Eine graphische Nutzer Schnittstelle kann beispielsweise verwendet werden, um einem Nutzer zu ermöglichen Verbindungslinien zwischen den Formularen 302, 310, 312 und graphischen Darstellungen des Geschäftsobjekts 306, 308 zu ziehen. Der Nutzer kann vorzugsweise Formulare unter Verwendung von lediglich einem Webbrowser entwerfen. Eine asynchrone Java und XML (AJAX) Schnittstelle können beispielsweise verwendet werden.
Wenn der Formular-Prozess 326 das Belastungskontakt-Verfahren des kundenspezifischen Geschäftsobjekt 306 mit dem Wert des Kundennummerfelder 504 als ein Parameter (bspw., unter Verwendung AJAX) abruft bzw. bezeichnet, übersetzt der Objektbroker Prozess 304 den Verfahrensabruf in die native Sprache der assoziierten Datenquelle 108 und fragt die assoziierten Daten von der Datenquelle 108 in deren nativen Format ab. Der CRM Broker-Service 330 aktiviert speziell das native Belastungskontakt-Verfahren der CRM Datenquelle 316 und empfängt den Kontaktnamen und Adresse von der CRM Datenquelle 316 zurück. Der CRM Broker-Service 330 speichert anschließend den Namen und Kontaktdaten in dem kundenspezifischen Geschäftsobjekt 306. Der CRM Broker-Service 330 kann beispielsweise ASP Code sein, der auf dem Objektbroker Server 114 läuft, der eine XML Datei (oder eine andere herkömmliche Datei) an den Formular-Prozess 326 sendet, der JavaScript Code ist, der auf dem Client-Gerät 102 läuft, das das Kundenkontaktformular 310 anzeigt. Wird das kundenspezifische Geschäftsobjekt 306 einmal mit dem neuen Namen und Adressdaten aktualisiert, befüllt der Formular-Prozess 326 das Namensfeld 506 und das Adressfeld 508 des Kundenkontaktformulars 310. Unter Verwendung dieses Verfahrens kann ein HTML Formular ohne Absenden des gesamten Formulars an einen Server und erneuten Übergabe des gesamten HTML Formulars aktualisiert werden.
Der Objektbroker Prozess 304 übersetzt ähnlich dazu, wenn der Formular-Prozess 326 das Verfahren zum Bestellen einer Charge des Bestell-Geschäftsobjekts 308 mit dem Wert des Kundennummerfelder 504 als ein Parameter abruft, den Verfahrensabruf in die native Sprache der assoziierten Datenquelle 108 und fragt die assoziierten Daten von der Datenquelle 108 in deren nativen Format ab. Der ERP Broker-Service 328 aktiviert speziell das native Verfahren zum Bestellen einer Charge der ERP Datenquelle 314 und empfängt eine Liste von Bestellnummern, eine assoziierte Liste der Summen (totals) und eine assoziierte Statusliste von der ERP Datenquelle 314 zurück. Die Daten können beispielsweise als eine Datenbanktabelle zurückgegeben werden. Diese Werte werden schließlich verwendet werden, um die Bestellnummer Spalte 510, die Mengen-Spalte 512 und die Status-Spalte 514 der Bestelltabelle 516 in dem Bestellungslistenformular 312 auszufüllen. Die Lieferdatumsspalte 518 kann jedoch in diesem Beispiel nicht von der ERP Datenquelle 314 geliefert werden, da die ERP Datenquelle 314 diese Information nicht enthält.
Die Lieferdatumsdaten werden in der Add-On Datenquelle 320 (d. h. das Lieferdatumsfeld wurde später von dem Nutzer hinzugefügt) gespeichert. Der Add-On Broker-Service 334 aktiviert demgemäß, wenn der Formular-Prozess 326 das Verfahren zum Bestellen einer Charge des Bestell-Geschäftsobjekts 308 mit dem Wert der Kundennummerfelder 504 als ein Parameter abruft, das Chargen Lieferdatum Verfahren der Add-On Datenquelle 320 und empfängt eine Liste der Lieferdaten und assoziierten Bestellnummern von der Add-On Datenquelle 320 zurück. Der Objektbroker Prozess 304 und/oder der Formular-Prozess 326 korrelieren die Lieferdaten mit den Mengendaten und Statusdaten, die unter Verwendung der Bestellnummer Daten, die beiden Listen gemein sind, von der ERP Datenquelle 314 erhalten wurden.
Der Objektbroker Prozess 304 speichert anschließen die Liste von Bestellnummern, die assoziierte Liste der Lieferdaten, die assoziierte Liste der Summen, und die assoziierte Statusliste in dem Bestell-Geschäftsobjekt 308. Der ERP Broker-Service 328, der Add-On Broker-Service 334, und/oder eine andere Software (bspw. ASP Code, der auf dem Objektbroker Server 114 läuft) kann/können beispielsweise eine XML Datei (oder eine andere herkömmliche Datei) an den Formular-Prozess 326 (bspw. JavaScript, das auf dem Client-Gerät 102 läuft) senden. Wird das Bestell-Geschäftsobjekt 308 einmal mit den neuen Daten aktualisiert, befüllt der Formular-Prozess 326 die Bestelltabelle 516 in dem Bestellungslistenformular 312.
Ein Flussdiagramm eines beispielhaften Objektbroker Prozesses 304 wird in der 6 gezeigt. Der Objektbroker Prozess 304 ist vorzugsweise in einem oder mehreren Softwareprogrammen ausgeführt, die in einem oder mehreren Speichern gespeichert werden und durch einen oder mehrere Prozessoren ausgeführt werden. Der Objektbroker Prozess 304 kann beispielsweise ASP Code (oder irgendeine andere Art von Software) sein, der auf dem Objektbroker Server 114 läuft. Obgleich der Objektbroker Prozess 304 unter Bezug auf das in 6 gezeigte Flussdiagramm beschrieben wird, sollte klar sein, dass zahlreiche andere Verfahren zum Durchführen der mit dem Objektbroker Prozess 304 assoziierten Handlungen verwendet werden können. Die Abfolge von vielen Schritten kann beispielsweise geändert werden und einige der beschriebenen Schritte können optional sein.
Der Objektbroker Prozess 304 empfängt im Allgemeinen herkömmliche Verfahrensabrufe von dem Formular-Prozess 326 und konvertiert die herkömmlichen Verfahrenabrufe in native Verfahrenabrufe. Der Objektbroker Prozess 304 sendet anschließend die nativen Verfahrensabrufe zu der/den assoziiert(en) Datenquelle(n) 108 und empfängt eine oder mehrere native Antworten von der/den Datenquelle(n) 108. Der Objektbroker Prozess 304 konvertiert anschließend die native(n) Antwort(en) in (eine) herkömmliche Antwort(en) und sendet die herkömmliche Antwort(en) an den abrufenden Formular-Prozess 326. Der Objektbroker Prozess 304 empfängt insbesondere einen Verfahrensabruf von dem Formular-Prozess 326 unter Verwendung eines herkömmlichen Protokolls (Block 602). Der herkömmliche Verfahrensabruf ist mit einem Geschäftsobjekt assoziiert und umfasst irgendwelche Eigenschaftswerte (d. h. Parameter), die für dieses Verfahren benötigt werden. Ein Client-Gerät 102 kann beispielsweise die Kundenbestellseite 302 als ein HTML Dokument anzeigen. Unter Verwendung eines onBlur Begebenheitstriggers bzw. Ereignisauslösers kann das Client-Gerät 102 JavaScript Code laufen lassen, der eine XML Datei 604, die ”LoadContact(1234567)” darstellt, über das Internet 116 mittels einer HTTP Anfrage an ein ASP Script sendet, das auf dem Objektbroker Server 114 läuft. Es ist klar, dass irgendwelche geeigneten Protokolle anstelle von HTML, JavaScript, XML, HTTP, und/oder ASP verwendet werden können. Beispielsweise kann VBScript anstelle von JavaScript, und Perl kann anstelle von ASP verwendet werden.
Die beispielhafte XML Anfrage 604 umfasst den ”LoadContact” Verfahrensabruf 606, der durch ein Öffnen ”Method” bzw. Verfahren Tag 608 und ein Schließen ”Method” Tag 610 begrenzt ist. Die beispielhafte XML Anfrage 604 umfasst darüber hinaus den ”customerID” Eigenschaftswert 612, der durch ein Öffnen ”customerID” Tag 614 und ein Schließen ”customerID” Tag 616 begrenzt ist.
Der Objektbroker Prozess 304 leitet anschließend den herkömmlichen Verfahrensabruf zu dem Broker-Service, der mit dem Verfahrensabruf (Block 618) assoziiert ist. Der Objektbroker Prozess 304 kann beispielsweise die XML Datei 604, die den LoadContact Verfahrensabruf 606 enthält, an den CRM Broker-Service 330 senden. Der Broker-Service, der mit dem Verfahrensabruf assoziiert ist, übersetzt anschließend für die assoziierte Datenquelle 108 (Block 620) den Verfahrensabruf von dem herkömmlichen Protokoll zu dem nativen Protokoll. Der CRM Broker-Service 330 kann beispielsweise eine native Anfrage 622 für die CRM Datenquelle 316 von der empfangenen XML Datei 604 bilden. Die native Anfrage 622 kann irgendein Protokoll verwenden. Die native Anfrage 622 kann beispielsweise eine SQL Abfrage sein, der bekannt ist, dass die CRM Datenquelle 316 die Kundenkontaktdaten in einem ”FullName” (vollständiger Name) Feld 624 und ein ”HomeAdresse” (Heimatadresse) Feld 626 einer ”ContactsTable” (Kontakttabelle) 628 beinhaltet, die durch ein ”CustNum” (Kundennummer) Feld 630 indiziert ist.
Der mit dem Verfahrensabruf assoziierte Broker-Service sendet anschließend die native Abfrage zu der assoziierten Datenquelle 108 und empfangt eine native Rückmeldung von der Datenquelle 108 (Block 632). Der CRM Broker-Service 330 kann beispielsweise ein ASP Script sein, das auf dem Objektbroker Server 114 läuft, der die native Anfrage 622 an die CRM Datenquelle 316 als eine SQL Abfrage sendet und eine native Rückmeldung 634 in der Form einer Komma-getrennten Liste empfängt. Die native Rückmeldung 634 umfasst in diesem Beispiel den Name-Wert 634 und den Adress-Wert 636 des Kontakts, was mit dem ”customerID” Eigenschaftswerts 612 assoziiert ist.
Der Broker-Service konvertiert anschließend die native Rückmeldung zu dem herkömmlichen Protokoll (Block 638) zurück. Der CRM Broker-Service 330 kann beispielsweise auf eine SQL Rückmeldung von der CRM Datenquelle 316 warten und eine assoziierte XML Rückmeldung 640 erzeugen. Die XML Rückmeldung 640 umfasst in diesem Beispiel alle Informationen der ursprünglichen XML Anfrage 604 (d. h. den ”LoadContact” Verfahrensabruf 606, der durch ein Öffnen ”Method” Tag 608 und ein Schließen ”Method” Tag 610 begrenzt ist und den ”CustomerID” Eigenschaftswert 612, der durch ein Öffnen ”CustomerID” Tag 614 und ein Schließen ”CustomerID” Tag 616 begrenzt ist). Die XML Rückmeldung 640 umfasst darüber hinaus den Name-Wert 634, der durch ein Öffnen ”Name” Tag 642 und ein Schließen ”Name” Tag 644 begrenzt ist, ebenso wie den Adress-Wert 640, der durch ein Öffnen ”Address” Tag 646 und ein Schließen ”Address” Tag 648 begrenzt ist.
Der Broker-Service sendet anschließend die herkömmliche Rückmeldung zu der Abruffunktion in dem Formular-Prozess 326 (Block 646). Der CRM Broker-Service 330 kann beispielsweise die XML Rückmeldung 640 an ein JavaScript senden, das mit der Kundenbestellseite 302 auf einem Client-Gerät 102 assoziiert ist. Der Formular-Prozess 326 kann anschließend, wie nachstehend beschrieben, die XML Rückmeldung 640 verwenden, um die HTML basierte Kundenbestellseite 302 zu befüllen.
Ein Flussdiagramm eines beispielhaften Formular-Prozess 326 wird in der 7 gezeigt. Der Formular-Prozess 326 ist vorzugsweise als ein oder mehrere Software Programme ausgeführt, das/die in einem oder mehreren Speichern gespeichert und durch einen oder mehrere Prozessoren ausgeführt wird/werden. Der Formular-Prozess 326 kann beispielsweise JavaScript Code (oder irgendeine andere Art von Software) sein, der auf einem Client-Gerät 102 läuft. Obgleich der Formular-Prozess 326 unter Bezug auf des in 7 gezeigte Flussdiagramm beschrieben wird, ist es klar, dass zahlreiche andere Verfahren zum Durchführen der Handlungen bzw. Vorgänge, die mit dem Formular-Prozess 326 assoziiert sind, verwendet werden können. Die Abfolge vieler Schritte kann beispielsweise geändert werden und einige der beschriebenen Schritte können optional sein.
Der Formular-Prozess 326 ermittelt im Allgemeinen Begebenheiten, die mit einem Formular (bspw. die HTML Kundenbestellseite 302) assoziiert sind und sendet herkömmliche Verfahrenabrufe (bspw., XML Anfrage 604) zu dem Objektbroker Prozess 304. Sobald der Formular-Prozess 326 die herkömmliche(n) Rückmeldung(en) (bspw. XML Rückmeldung 640) von dem Objektbroker Prozess 304 zurück empfängt, kann der Formular-Prozess 326 anschließend die herkömmliche(n) Rückmeldung(en) verwenden, um das Formular (bspw. die HTML Kundenbestellseite 302) zu befüllen.
Der Formular-Prozess 326 ermittelt insbesondere eine Begebenheit, die erfordert, das ein Formular und/oder Seite aktualisiert wird (Block 702). Der Formular-Prozess 326 kann beispielsweise JavaScript Code sein, der auf einem Client-Gerät 102 in Assoziation mit der Kundenbestellseite 302 läuft. Sobald ein Nutzer den load bzw. Chargen Button 502 auf dem Kundenkontaktformular 310 betätigt, ermittelt der Formular-Prozess 326 die onClick Begebenheit, die mit dem load Button 502 assoziiert ist und führt einen Teil des JavaScript Codes aus, der mit dieser onClick Begebenheit (d. h. dem Begebenheitsanwender (event handler)) assoziiert ist.
Sobald der Begebenheitsanwender ausgeführt ist, erzeugt der Formular-Prozess 326 einen geeigneten Verfahrensabruf in dem Herkömmlichprotokoll (Block 704). Das Client-Gerät 102 kann beispielsweise JavaScript Code ausführen, der die XML Datei 604 erzeugt, die ”LoadContact(1234567)” darstellt. Die beispielhafte XML Anfrage 604 umfasst wie vorstehend beschrieben den ”LoadContact” Verfahrensabruf 606, der durch ein Öffnen ”Method” Tag 608 und ein Schließen ”Method” Tag 610 begrenzt ist. Die beispielhafte XML Anfrage 604 umfasst darüber hinaus den ”CustomerID” Eigenschaftswert 612, der durch ein Öffnen ”CustomerID” Tag 614 und ein Schließen ”CustomerID” Tag 616 begrenzt ist.
Der Formular-Prozess 326 sendet anschließend den herkömmlichen Verfahrensabruf an den Objektbroker Prozess 304 (Block 706). Das Client-Gerät 102 kann beispielsweise die XML Anfrage 604 über das Internet 116 mittels einer HTTP Anfrage an ein ASP Script senden, das auf dem Objektbroker Server 114 läuft. Der Objektbroker Prozess 304 kommuniziert anschließend mit der assoziierten Datenquelle 108 unter Verwendung der nativen Protokolle und sendet dem Formular-Prozess 326 eine herkömmliche Rückmeldung (Block 708). Das Client-seitige JavaScript, das mit dem Formular-Prozess 326 assoziiert ist, kann beispielsweise die XML Rückmeldung 640 von dem Server-seitigen ASP Script empfangen, das mit dem Objektbroker Prozess 304 assoziiert ist.
Die beispielhafte XML Rückmeldung 640 umfasst wie vorstehend beschrieben alle Informationen der ursprünglichen XML Anfrage 604 (d. h. den ”LoadContact” Verfahrensabruf 606, der durch ein Öffnen ”Method” Tag 608 und ein Schließen ”Method” Tag 610 begrenzt ist, und den ”CustomerID” Eigenschaftswert 612, der durch ein Öffnen ”CustomerID” Tag 614 und ein Schließen ”CustomerID” Tag 616 begrenzt ist). Die XML Rückmeldung 640 umfasst darüber hinaus den Name-Wert 634, der durch ein Öffnen ”Name” Tag 642 und ein Schließen ”Name” Tag 644 begrenzt ist, ebenso wie den Adress-Wert 640, der durch ein Öffnen ”Address” Tag 646 und ein Schließen ”Address” Tag 648 begrenzt ist. Der Formular-Prozess 326 kann anschließend die herkömmliche Rückmeldung verwenden, um das Kundenformular zu befüllen (Block 710). Das Client-seitige JavaScript kann Beispielsweise das Name-Feld 506 und das Adressfeld 508 des HTML basierten Kundenkontaktformulars 310 befüllen.
Eine Workflow Erstellungshilfe 800, die einem Nutzer ein Definieren einer Ressourcenkarte 802 ermöglicht, wird in der 8 gezeigt. Die Workflow Erstellungshilfe 800 umfasst in diesem Beispiel einen Datei Explorer-Abschnitt 804 und eine Entwurfleinwand (design canvas) 806. Der Datei Explorer-Abschnitt 804 ermöglicht dem Nutzer mehrere Dateien aufzufinden und zu organisieren, die mit dem Workflow assoziiert sind. Die Entwurfleinwand 806 ermöglicht dem Nutzer eine graphische Darstellung der Ressourcenkarte 802 zu zeichnen. Eine Ressourcenkarte 802 wird in diesem Beispiel gezeigt, die ein Belegschafts-Objekt 808 und ein Kunden-Objekt 810 umfasst. Das Belegschafts-Objekt 808 und das Kunden-Objekt 810 umfassen jeweils einen oder mehrere Eingabeknoten 812 und einen oder mehrere Ausgabeknoten 814. Eingabeknoten 812 sind mit Ausgabeknoten 814 durch Prozesspfeile 816 verbunden. Ein Hilfs-Prozess 816a und ein Verkaufs-Prozess 816b gehen in diesem Beispiel jeweils aus dem Belegschafts-Objekt 808 hervor und in das Kunden-Objekt 810 ein. Ein Bestell-Prozess 816c geht ähnlich dazu aus dem Kunden-Objekt 810 hervor und in das Belegschafts-Objekt 808 ein.
Durch das Definieren von Workflows im Hinblick auf bekannte Ressourcen (bspw. das Belegschafts-Objekt 808 und das Kunden-Objekt 810) und die Interaktionen zwischen diesen Ressourcen (bspw. benötigt das Kunden-Objekt 810 Unterstützung von dem Belegschafts-Objekt 808), kann der Entwerfer des Workflows jeden Prozess durch Anfangen an einem hohen Niveau und Nachforschen der zugrundeliegenden Prozesse und automatisierten Workflows entdecken und entwerfen.
Die Ressourcenkarten 802 ermöglichen ebenso beim Geschäftsobjektserbe Klassen eines Geschäftsobjekts und die Nachfolgeobjekte jenes Geschäftsobjekts zu zeigen. Nachfolgeobjekte können mit Vorläuferobjekten durch Modifizieren von Eigenschaften, die mit dem Vorläuferobjekt assoziiert sind, und/oder Hinzufügen von Eigenschaften zu dem Vorläuferobjekt assoziiert sein. Ein einzelne Vorläufer-/Nachfolgeobjekt Kombination könnte eine einmalige Link-Definition in einer anderen Ressource auf der Leinwand aufweisen. Das Vorläufer-Kunden-Objekt 810 kann beispielsweise ein Nachfolgeobjekt zur Leitung des Kunden und ein Handelskunden-Nachfolgeobjekt umfassen. Der Verkaufs-Prozess 816b zwischen dem Belegschafts-Objekt 808 und dem Kunden-Objekt 810 kann in Abhängigkeit von der Art des Kunden-Objekts 810 (d. h. ein Verkaufs-Prozess 816b für die Leitung des Kunden 810 und einen anderen Verkaufs-Prozess für Geschäfts-Verbraucher 810) verschieden sein. Das Belegschafts-Objekt 808 kann ähnlich dazu ein Vorläufer Objekt mit Verkaufspersonal und Betreuerstab in Form zweier Nachfolge-Ressourcen sein.
Eine andere Ansicht der Workflow Erstellungshilfe 800 wird in der 9 gezeigt. Die Workflow Erstellungshilfe 800 wird n dieser Ansicht verwendet, um eine Prozesskarte 902 zu erzeugen. Der Hilfs-Prozess 816a wird in diesem Beispiel definiert. Der beispielhafte Hilfs-Prozess 816a umfasst einen Start Schritt 904, einen Zurückweisungs-(rejected)Schritt 906, und einen Bestätigungs-(approved)Schritt 908. In diesem Beispiel muss lediglich einer dieser Schritte 904, 906, 908 durchgeführt werden. Ein neuer Schritt 910 wird platziert bzw. zugeordnet, um einen der drei Schritte 904, 906, 908 auszuwählen. Der neue Schritt 910 umfasst mehrere Aktionen 912 und mehrere entsprechende Ausgabeknoten 814. Der neue Schritt 910 umfasst in diesem Beispiel eine Bestätigungsaktion 914, eine Zurückweisungsaktion 916, und eine Weiterleitaktion (redirect action) 918. Der Nutzer verbindet den zurückgewiesenen Ausgabeknoten 814a mit dem Eingabeknoten 812a des Zurückweisungs-(rejected)Schritt 906 durch Ziehen des Prozessverbinders 816d. Die assoziierte Grundsatzlogik (line logic) wird für den Nutzer automatisch konfiguriert.
Eine andere Prozesskarte 1000 wird in der 10 gezeigt. In dieser beispielhaften Prozesskarte 1000 ist ein Abschnitt 1002 der Prozesskarte 1000 hervorgehoben. Bestätigungsschritt 1004 und ein Benachrichtigungsschritt 1006 sind im Besonderen in einem hervorgehoben Abschnitt 1002 enthalten. Dieser Abschnitt 1002 kann einen örtlich begrenzten Bereich der Prozesskarte 1000 definieren, indes andere Abschnitte der Prozesskarte 1000 (bspw. der Rest der Prozesskarte 1000 in diesem Beispiel) als globale Bereiche angesehen werden. Unter Verwendung einer Prozessnachfolge, ermöglicht diese Lokalisierung bestimmter Prozessbereich einem Prozessinhaber die Kontrolle über den globalen Prozess beizubehalten, wobei es einem anderen Nutzer immer noch ermöglicht ist bestimmte Abschnitte 1002 anzupassen. Der globale Prozess kann beispielsweise festlegen, sobald etwas bestätigt und wohin die Benachrichtigung geleitet wird, wobei allerdings ein Büro in einer Organisation einen Satz von Aktionen als Antwort auf die Bestätigung durchführen und ein anderes Büro in der Organisation einen anderen Satz von Aktionen Antwort auf die Bestätigung durchführen kann. Lokale Prozesse können sogar zusätzliche Prozessschritte beinhalten, die für den örtlich begrenzten Bereich spezifisch sind. Der Prozess 1000 wird unter einer einzelnen Prozessdefinition beibehalten, so dass Änderungen an dem globalen Abschnitt auf alle Instanzen des Prozesses 1000 automatisch angewendet und Änderungen an dem lokalen Abschnitt 1002 lediglich auf die assoziiert Lokalitäten bzw. Örtlichkeiten angewendet werden.
Individuelle Prozessschritte und/oder Abschnitte 1002 können darüber hinaus gesichert werden. Ein Bestätigungsschritt 1008 wird in diesem Beispiel individuell gesichert und der lokale Abschnitt 1002 wird ebenso gesichert. Jeder gesicherte Schritt und jeder gesicherte Abschnitt umfasst ein Sicherungs-Icon 1010, um einen gesicherten Status anzuzeigen. Durch Sichern eines Prozessschritts 1008 und/oder eines Prozessabschnitts 1002, können Prozess Entwerfer die Möglichkeit eines anderen Nutzers begrenzen bestimmte Konfigurationseinstellungen von der definierten und gesicherten Logik zu ändern, Abhängigkeiten hinzuzufügen oder zu entfernen, etc.. Die Sicherungsattribute können ebenso durch Wizards und Templates auf programmatische Art manipuliert werden, was ermöglicht die Implementierungslogik von Bausteinen niedrigerer Ebene zu verstecken oder zu sichern.
Ein gemeinschaftlicher Framework ermöglicht einem Prozess Entwerfer in der Workflow Erstellungshilfe 800 zu arbeiten, um seine Entwurfleinwand 806 mit einem anderen Nutzer über das Netzwerk 116 optisch zu teilen. Ein Prozess Entwerfer kann ebenso eine Sprach- oder Textkonversation mit den anderen Parteien beginnen, um über den Prozess zu diskutieren, der gerade entworfen wird. Der Prozess Entwerfer kann derart einen anderen Nutzer in den Prozessentwurf unter Verwendung von Zusammenarbeits- und die Anwendung teilenden Werkzeugen einbeziehen. Durch Rechtsklick auf die Entwurfleinwand 806 kann der Prozess Entwerfer beispielsweise eine bestimmte Person in der Buchhaltung kontaktieren, um diese Person zu fragen, wer benachrichtigt werden soll, falls ein Kauf bestätigt wird. Textnachrichten und/oder Sprachaufnahmen zwischen Mitarbeitern können ebenso in einer Datenbank zur späteren Überprüfung gespeichert werden. Wenn ein Prozess beispielsweise für einen Neuentwurf evaluiert wird, kann der Prozess Entwerfer einer Mitarbeiterunterhaltung zuhören, um zu bestimmen, ob ein bestimmter Schritt auf die derzeitige Art implementiert wurde.
Jeder Schritt der graphischen Darstellung eines Prozesses umfasst vorzugsweise einen Activity Strip. Ein beispielhafter Activity Strip 1100 wir in der 11 gezeigt. Der Activity Strip 1100 umfasst in diesem Beispiel ein oder mehrere Begebenheits-Icons 1102, die die Begebenheiten darstellen, die mit dem Prozessschritt assoziiert sind. Der Nutzer kann beispielsweise eine Sende E-Mail Begebenheit in einen Prozessschritt ziehen. Ein E-Mail Begebenheits-Icon 1104 wird in einem derartigen Fall dem Activity Strip 1100 hinzugefügt. Falls die Zahl der Begebenheits-Icons 1102 die Breite des Activity Strip 1100 übersteigt, kann der Nutzer Begebenheits-Icons unter Verwendung der Pfeilknöpfe 1106 durchscrollen.
Sobald ein bestimmtes Begebenheits-Icon 1102 ausgewählt wird, wird dem Nutzer ein Setup Wizard gezeigt, um den Abschnitt des Prozesses zu konfigurieren. Jeder Schritt in einem Prozess wird vorzugsweise dem Nutzer als Kubus dargestellt und der Setup Wizard wird zur Ansicht eingeschwenkt bzw. eingeblendet, um eine Wirkung einer einzelnen Entität hervorzurufen, an der der Nutzer arbeitet. Sobald ein Nutzer beispielsweise das E-Mail Begebenheits-Icon 1104 betätigt, ändert bzw. dreht sich der Activity Strip 1100 in einen E-Mail Begebenheits-Setup Wizard 1200. Eine teilweise gedrehte Ansicht eines beispielhaften E-Mail Begebenheits-Setup Wizard 1200 wird in der 12 gezeigt. Eine vollständig gedrehte Ansicht des gleichen Setup Wizard 1200 wird in der 13 gezeigt. Der E-Mail Setup Wizard 1200 kann verwendet werden, um dynamisch erstellte E-Mails zu entwerfen, die von einem oder mehreren Workflow Prozessen verwendet werden. Der in der 10 gezeigte Benachrichtigungs-Schritt 1006 des Bestätigungs-Prozesses 1000 umfasst beispielsweise eine Ausgabe 814, die eine automatische E-Mail Nachricht sein kann. Der E-Mail Setup Wizard 1200 kann verwendet werden, um zu entwerfen wie diese E-Mail Nachricht erstellt wird.
Der E-Mail Setup Wizard kann einen Bezugs-(reference)wizard verwenden, der einem Nutzer ermöglicht, einen Prozess zu verwenden, während ein anderer Prozess entworfen wird. Ein Bezugswizard kann beispielsweise einem Nutzer ermöglichen irgendein Verfahren in irgendeinem .NET Assembly, Web Service oder WCF Service als Teil eines beim Entwerfen eines Prozesses abrufen.
Der Setup Wizard 1200 umfasst vorzugsweise einen Hauptanzeigeabschnitt 1202 und einen Weiter (next) Button 1204. Die Hauptanzeigeabschnitt 1202 zeigt eine Seite des Setup Wizards 1200. Der Weiter Button 1204 bringt den Hauptanzeigeabschnitt 1202 zur nächsten Seite des Setup Wizards 1200. Ein zuvor erfolgt (previous) Button (nicht gezeigt) ändert den Hauptanzeigeabschnitt 1202, um die vorherige Seite des Setup Wizards 1200 anzuzeigen.
Der Setup Wizard 1200 umfasst ebenso eine Seitenpalette 1206. Die Seitenpalette 1206 umfasst mehrere Thumbnails bzw. Minaturansichten 1208 bis 1220. Jeder der Thumbnails 1208 bis 1220 stellt eine der Seiten in dem Setup Wizard 1200 dar. Der Nutzer kann durch Klicken des assoziierten Thumbnails schnell zu irgendeiner Seite in dem Setup Wizard 1200 springen bzw. wechseln. Wenn ein Nutzer zu einer bestimmten Seite in dem Setup Wizard 1200 spring, wird der Hauptanzeigeabschnitt 1202 neu entworfen, um diese Seite wiederzugeben.
Der Nutzer kann darüber hinaus schnell ein Popup irgendeiner Seite in dem Setup Wizard 1200 durch Ziehen eines Cursors über den assoziierten Thumbnail ansehen ohne zu dieser Seite (d.h. ohne Darstellen der Seiteninhalte in dem Hauptanzeigeabschnitt 1202) zu springen. Die dritte Seite 1212 des beispielhaften E-Mail Setup Wizards 1200 wird beispielsweise in der 14 als ein Popup angezeigt. Die dritte Seite 1212 des Setup Wizards 1200 umfasst in diesem Beispiel eine Subjekt-Eingabefeld 1402 und ein Körper-(body)Eingabefeld 1404. Das Subjekt-Eingabefeld 1402 des E-Mail Setup Wizards 1200 wird verwendet, um die Betreffzeile der automatischen E-Mail zu definieren. Das Körper-Eingabefeld 1404 des E-Mail Setup Wizards 1200 wird verwendet, um den Körper der automatischen E-Mail zu definieren. Irgendwelche Werte, die in eine Seite des Prozess Setup Wizards 1200 eingegeben werden, sind in der Popup Ansicht zu sehen. Falls der Nutzer beispielsweise ”Approval Report” bzw. Bestätigungsbericht in das Subjekt-Eingabefeld 1402 der dritten Seite 1212 des E-Mail Setup Wizards 1200 eingeben hatte, würde ”Approval Report” in dem Subjekt-Eingabefeld 1402 des Popup Fensters zu sehen sein. Der Nutzer kann derart Werte auf verschiedenen Seiten des Setup Wizards 1200 eingeben, die mit anderen Einträgen konsistent sind, ohne die Notwendigkeit sich an diese anderen Einträge zu erinnern und/oder die derzeitige Seite zu verlassen.
Ein Flussdiagramm eines beispielhaften Setup Wizard Prozesses 1500 wird in der 15 gezeigt. Der Setup Wizard Prozess 1500 ist vorzugsweise als ein oder mehrere Softwareprogrammen ausgestaltet, die in einem oder mehreren Speichern gespeichert und von einem oder mehreren Prozessoren ausgeführt werden. Obgleich der Setup Wizard Prozess 1500 unter Bezug auf das in 15 gezeigte Flussdiagramm beschrieben wird, ist es klar, dass zahlreiche andere Verfahren zum Durchführen der Handlungen, die mit dem Setup Wizard Prozess 1500 assoziiert sind, verwendet werden können. Die Reihenfolge vieler Schritte kann beispielsweise geändert werden und einige der beschriebenen Schritte können optional sein.
Der Prozess 1500 fangt an, sobald ein Client-Gerät 102 eine Begebenheit ermittelt, die mit einer graphischen Darstellung eines Prozessschritts 1008 (Block 1502) assoziiert ist. Der Nutzer kann beispielsweise auf einen Setup Button in dem Activity Strip 1100 klicken. Das Client-Gerät 102 stellt als Antwort eine animierte Sequenz dar (Block 1504). Das Client-Gerät kann beispielsweise den Activity Strip beim Drehen in drei Dimensionen zeigen, um eine E-Mail Setup Wizard ”side” bzw. Seite eines Kubus darzustellen. Der Nutzer bekommt derart ein visuelles Feedback, dass die zwei Objekte (bspw. der Activity Strip 1100 und der E-Mail Setup Wizard 1200) zueinander in Beziehung stehen.
Der Setup Wizard umfasst mehrere Setup Seiten in einer Thumbnailpalette 1206 und eine derzeitige Setup Seite in einem Hauptanzeigeabschnitt 1202 (Block 1506). Auf der ersten Seite eines E-Mail Setup Wizards kann beispielsweise der Nutzer gefragt werden, die E-Mail Adresse des Empfängers und das Thema der E-Mail Nachricht einzugeben. Während das Client-Gerät 102 Setup Wizard Seiten anzeigt und Setup Informationen von dem Nutzer erhält, überwacht das Client-Gerät 102 ebenso für mehrere Begebenheiten, wie beispielsweise Mausbewegungen und Mausklicken.
Falls eine erste Art einer Begebenheit, die mit einem der Thumbnail Bilder 1208–1220 assoziiert ist, ermittelt wird (Block 1508), zeigt das Client-Gerät 102 vorzugsweise eine größere Version des assoziierten Thumbnail Bildes (Block 1510). Falls der Nutzer beispielsweise den Mauscursor über ein bestimmtes Thumbnail Bild 1208–1220 bewegt, kann ein Popup Fenster 1212, das eine größere Version dieses Thumbnail Bilds zeigt, angezeigt werden. Die größere Version des Thumbnail Bilds ist vorzugsweise ein anderes Fenster 1212, das kleiner als der Hauptanzeigeabschnitt 1202 ist (vgl. 14). Irgendeine Art eines, geeigneten Bilds kann jedoch verwendet werden. Die größere Version des Thumbnail Bilds kann beispielsweise den Hauptanzeigeabschnitt 1202 ”temporarily” bzw. zeitweise ersetzen.
Falls eine zweite Art einer Begebenheit, die mit einem der Thumbnail Bilder 1208–1220 assoziiert ist, ermittelt wird (Block 1512), entfernt das Client-Gerät 102 vorzugsweise die größere Version des assoziierten Thumbnail Bilds (Block 1514). Falls der Nutzer den Mauscursor beispielsweise aus einem bestimmten Thumbnail Bild bewegt, kann das Popup Fenster entfernt werden, das die größere Version dieses Thumbnail Bilds zeigt. Falls die größere Version des Thumbnail Bilds ein anderes Fenster ist, wird dieses Fenster von der Anzeige entfernt und der Gehalt ”beneath” bzw. unterhalb des entfernten Fensters wird neu entworfen. Falls die größere Version des Thumbnail Bilds den Hauptanzeigeabschnitt 1202 ersetzte, werden die vorherigen Inhalte des Hauptanzeigeabschnitt 1202 (bspw. die derzeitige Setup Seite) in dem Hauptanzeigeabschnitt 1202 neu entworfen.
Die größere Version des Thumbnail Bilds zeigt ebenso irgendwelche Setup Informationen, die von dem Nutzer zuvor eingegeben wurden. Falls der Nutzer beispielsweise die Empfänger E-Mail Adresse auf der ersten Seite des Setup Wizards eingibt, auf eine andere Seite des Setup Wizards bewegt, und anschließend die einzugebende E-Mail Adresse ohne Zurückscrollen bis zu der ersten Seite wieder aufrufen will, kann der Nutzer die Maus einfach über den ersten Thumbnail rollen bzw. bewegen, um die einzugebende Information wieder aufzurufen.
Falls eine dritte Art einer Begebenheit, die mit einem der Thumbnail Bilder 1208–1220 assoziiert ist, ermittelt wird (Block 1516), ersetzt das Client-Gerät 102 vorzugsweise das Hauptanzeigebild mit einer unverkleinerten Version des assoziierten Thumbnail Bilds (Block 1518). Falls der Nutzer beispielsweise mit der Maus auf ein bestimmtes Thumbnail Bild klickt, springt der Hauptanzeigeabschnitt 1202 vorzugsweise auf diese Seite in dem Setup Wizard. Im Gegensatz zu der Maus im voranstehenden Beispiel, lässt ein Entfernen der Maus von dem Thumbnail den Hauptanzeigeabschnitt 1202 nicht auf die vorherige Seite zurückkehren (d. h., der Nutzer bewegte zu dieser Setup Seite im Gegensatz zu einem einfachen zeitweisen Überprüfen dieser Setup Seite).
Der Nutzer kann jederzeit eine oder mehrere Setup Optionen (Block 1520) eingeben und die Setup Optionen werden gespeichert (Block 1522). Falls der Nutzer den Setup Wizard verlässt (Block 1524), läuft der Prozess 1508–1520 eines Überprüfens auf Nutzer Aktionen und Setup Optionen erneut ab.
Obgleich das dynamische Geschäftsobjekt ein nützliches Werkzeug bei derzeitigen Organisationen sein kann, kann auf es nicht einfach von Remote-Client-Geräten zugegriffen und weiterverarbeitet werden, wenn erst einmal ein dynamisches Geschäftsobjekt erzeugt wurde. Manche vorhandenen Technologien erfordern, dass zuvor das Geschäftsobjekt durch vorhandene Web Service Technologien weiterverarbeitet werden kann, ein Endpunkt definiert werden muss. Ein Endpunkt wird verwendet, um die Interaktionserfordernisse zwischen dem Client-Gerät und dem Geschäftsobjekt zu spezifizieren. Das Client-Gerät sendet beispielsweise eine Nachricht an den Endpunkt des Geschäftsobjekts, wenn es das Geschäftsobjekt verwenden möchte, und die Nachricht wird gemäß den Informationen formatiert, die durch den Endpunkt spezifiziert werden. Ein Geschäftsobjekt kann zahlreich Endpunkte aufweisen, die verschiedene Wege für Clients ermöglichen, um dieses Objekt weiterzuverarbeiten. Andere vorhandene Technologien können einen voreingestellten Endpunkt bereitstellen, wobei der Nutzer irgendwelche Parameter oder Einstellungen des Endpunkts nicht konfigurieren kann.
Ein Endpunkt wird für gewöhnlich durch eine Adresse, ein Binding und einen Contract definiert. Eine Adresse ist die Stelle, an der der Endpunkt liegt. Eine Binding spezifiziert, wie ein Geschäftsobjekt weiterverabeitet werden kann, wie beispielsweise Protokoll- oder Codierungsinformationen. Einen Contract für jedes Objekt führt die Operationen auf, denen das Geschäftsobjekt ausgesetzt ist (exposed by). Alle diese Informationen müssen spezifiziert werden bevor ein Geschäftsobjekt von einem Remote-Client-Gerät verwendet werden kann.
Heutzutage vorhandene Vorgehensweisen werfen mehrere Schwierigkeiten auf. Der Contract muss in einigen Fällen für jedes Objekt von Hand erzeugt werden. Da der Endpunkt den Contract umfasst, wird der Endpunkt ebenso für jedes Objekt von Hand erzeugt. Das Erzeugen eines Contract (and daher des Endpunkts) von Hand kann teuer und zeitraubend sein und ist empfänglich gegenüber einem Nutzerfehler. Der Endpunkt kann ferner ablaufen, falls er nicht aktualisiert wird sobald das Geschäftsobjekt aktualisiert wird, und der Nutzer kann sich auf Endpunktinformation verlassen, die das Geschäftsobjekt nicht genau darstellen.
Das vorliegende System stellt Clients Geschäftsobjekte über Endpunkte zu Verfügung, worin die Endpunkte dynamisch erzeugt werden. Es besteht daher kein Bedarf einen Endpunkt von Hand zu erzeugen. Die Endpunkte können auf einem Server gespeichert werden. Mit Objekten assoziierte Endpunkte werden automatisch erzeugt, wenn die Geschäftsobjekte erzeugt werden, oder die Endpunkte können erzeugt werden, wenn das Geschäftsobjekt abgefragt wird. Die Endpunkte werden in einer Ausführungsform basierend auf Konfigurationskriterien erzeugt, die dem Nutzer ermöglichen verschiedene Isolierungsnivaus auf die Endpunkte anwenden, wie nachstehend ausgeführt wird. Ob Konfigurationskriterien verwendet werden oder nicht, es besteht kein Bedarf Endpunktinformationen von Hand erzeugen, da der Endpunkt automatisch erzeugt wird, wenn das Geschäftsobjekt von einem Client-Gerät abgefragt oder erzeugt wird. Client-Geräte können mit dem dynamischen Endpunkt kommunizieren und Contracts verwenden, die mit den Geschäftsobjekten assoziiert sind, obgleich die Contracts von Hand erzeugt wurden. Die Geschäftsobjekt Eigenschaften können durch Contractsdaten offengelegt und Geschäftsobjekt Verfahren können durch Betriebsdaten offengelegt werden.
Das vorliegende System befreit Ressourcen und verbessert die Wirksamkeit, da neue Objekte entworfen, eingesetzt und weiterverarbeitet werden können ohne die Notwendigkeit Endpunkte zu erzeugen. Client-Geräte werden lediglich benötigt, um über die dynamischen Endpunkte Bescheid zu wissen und damit zu verbinden. Client-Geräte können daher Objekte ohne irgendeine Notwendigkeit zur Contract-Erzeugung, Erstellung, oder Veröffentlichung verwenden. Die Endpunktinformationen, wie beispielsweise einen Contract, werden durch den gleichen Service erzeugt, der die Geschäftsobjekte erzeugt. Die Endpunktinformationen sind daher vollständig und mit dem Geschäftsobjekt kompatibel, und erfordern keine zusätzliche Einbeziehung eines Programmierers oder von Programmierwerkzeugen. Da der Endpunkt ferner beim Erzeugen oder Abfragen des Geschäftsobjekts erzeugt wird, kann der Endpunkt eine Integration in neue Umgebungen ermöglichen, die nicht vorhanden waren, als das Geschäftsobjekt entworfen wurde.
Ein Geschäftsobjekt kann in einer Ausführungsform periodisch aktualisiert werden, um neue Versionen zu erzeugen. Bei statischen Contracts, würde jede neue Version des Geschäftsobjekts ein Aktualisieren des Contracts auf dem Server erfordern, so dass die Clients das Geschäftsobjekt weiterverarbeiten können. Der Contract (oder die Endpunktinformation) veraltet andernfalls und der Client weist nicht mehr langer den neuesten oder genauesten Contract auf, um das Geschäftsobjekt weiterzuverarbeiten. Diese Schwierigkeit wird in dem vorliegenden System durch die Verwendung von Contracts vermieden, die dynamisch erzeugt werden. Da das vorliegende System dynamische Contracts verwendet, veraltet der Contract niemals. Falls die Geschäftsobjekte modifiziert werden, wird der Contract automatisch modifiziert oder aktualisiert. Das Client-Gerät oder der Verbraucher fährt fort auf die einzelne bekannte Entität zu zeigen – den dynamischen Endpunkt – und der dynamische Endpunkt erhält Informationen und Wissen über die Geschäftsobjekte, Prozesse und Ressourcen des Systems. Der dynamische Endpunkt fährt fort Contracts für die anderen Objekte in dem System zu erzeugen, während neue Objekte noch hinzugefügt oder vorhandene Objekte modifiziert werden.
Vorherige Versionen von Endpunkten werden in einer Ausführungsform erhalten, während neue Endpunkte noch erzeugt werden. Dies kann von Nutzen sein, wenn ein Client-Gerät unter Verwendung einer spezifischen Version eines Contracts oder Endpunkts auswählt oder erfordert, selbst wenn ein neuer Contract oder Endpunkt erzeugt wurde.
Der Server erstellt und veröffentlicht in einer Ausführungsform Contracts für alle Objekte, die auf dem Server erhalten oder gespeichert werden. Der Server erstellt und veröffentlicht durch Ausschließen einiger Geschäftsobjekte in einer Ausführungsform Contracts für lediglich eine Untergruppe des Geschäftsobjekte, die auf dem Server gespeichert werden. Die Untergruppe kann basierend auf Konfigurationskriterien bestimmt werden.
Die Kriterien können Wahlweise zur gleichen Zeit bestimmt werden, an der der Server Contracts erstellt und veröffentlicht. Dies ermöglicht einem Nutzer grobe Kontrolle (granular controll) über die dynamische Beschaffenheit des Systems auszuüben.
Der dynamische Endpunktgenerator kann beispielsweise ein Gattungssystem implementieren. Jedes Objekt weist in einer Ausführungsform einen einmaligen Endpunkt auf. Jedes Geschäftsobjekt wird in einer Ausführungsform in einer Gattung platziert, und jede Gattung weist einen einmaligen Endpunkt auf. Wenn zahlreiche Geschäftsobjekte die gleiche Gattung (und daher den gleichen Endpunkt) teilen, können diese Geschäftsobjekte von dem dynamischen Endpunktgenerator ausgewählt oder deselektiert werden. Dies ermöglicht einem Nutzer lediglich bestimmte Gattungen von Geschäftsobjekten dynamisch zu aktualisieren.
Ein Nutze, der beispielsweise an einem Projekt arbeitet, kann alle dieses Projekt betreffenden Geschäftsobjekte unter einer Gattung platzieren. Der Nutzer kann lediglich diese Gattung (und daher den Endpunkt) auswählen und der dynamische Endpunktgenerator wird die Contracts für die Geschäftsobjekte dynamisch aktualisieren, die zu dieser Gattung gehören. Andere Geschäftsobjekte in anderen Gattungen werden von dem dynamischen Endpunktgenerator ausgeschlossen, was die Zahl an Geschäftsobjekten verringert, die dynamisch aktualisiert werden, und daher die Speicherkapazität, Wiederherstellungszeit, und Startzeit verringert. Der Nutzer kann Untergattungen erzeugen und auswählen Contracts für Objekte dynamisch zu erzeugen, die zu bestimmten Untergattungen gehören. Der Nutzer kann daher genau kontrollieren, welche Geschäftsobjekte dynamisch aktualisiert werden sollen.
Die 16 ist ein Screenshot einer Ausführungsform eines Systems 1600, in dem ein dynamischer Endpunktgenerator 1602 implementiert ist, um einer Geschäftsobjekt Anwendung 1604 zu ermöglichen Geschäftsobjekte weiterzuverarbeiten. Zahlreiche Geschäftsobjekte werden auf einem Geschäftsobjekte Server 1606 gespeichert. Der Geschäftsobjekte Server 1606 umfasst beispielsweise ein kundenspezifisches Geschäftsobjekt 1608, ein Bereich Geschäftsobjekt 1610, ein Produkt Geschäftsobjekt 1612, ein Angestellten Geschäftsobjekt 1614 und andere Geschäftsobjekts 1616. Die Geschäftsobjekte kommunizieren mit der Geschäftsobjekt Datenquelle 1618. Das System erzeugt in einer Ausführungsform einen Endpunkt, wenn das Geschäftsobjekt erzeugt wird.
Das System hat in einer Ausführungsform keine Contracts für irgendeines der Geschäftsobjekte erzeugt, und erzeugt lediglich Endpunkte, wenn die Geschäftsobjekte angefragt werden. Eine Organisation kann beispielsweise die Notwendigkeit aufweisen den Vornamen, den Familiennamen und die Sozialversicherungsnummer ihrer Verbraucher zu speichern. Ein Nutzer spezifiziert diese Felder, wenn das kundenspezifische Geschäftsobjekt 1608 definiert wird.
Die Geschäftsobjekt Anwendung 1604 kann eine Interaktion mit dem Kundenspezifischen Geschäftsobjekt 1608 benötigen. Die Geschäftsobjekt Anwendung 1604 möchte beispielsweise einen neuen Kunden unter Verwendung des Kundenspezifischen Geschäftsobjekts 1608 erzeugen. Die Geschäftsobjekt Anwendung 1604 weist jedoch die Endpunktinformation für das Kundenspezifische Geschäftsobjekt 1608 nicht auf. Wenn die Geschäftsobjekt Anwendung 1604 nach einer Kommunikation mit dem Kundenspezifischen Geschäftsobjekt 1608 das Kundenspezifische Geschäftsobjekt 1608 anfordert oder es weiterverarbeiten möchte, sendet sie eine Anfrage an den dynamischen Endpunktgenerator 1602. Der dynamische Endpunktgenerator 1602 erstellt automatisch und veröffentlicht Endpunktinformation, einschließlich einen Daten Contract für das Kundenspezifische Geschäftsobjekt 1608. Die Geschäftsobjekt Anwendung 1604 kann daher das Kundenspezifische Geschäftsobjekt 1608 weiterzuverarbeiten, obgleich das Kundenspezifische Geschäftsobjekt 1608 vorher keinen Endpunkt aufwies. Der dynamische Endpunktgenerator 1602 erzeugt in einer Ausführungsform einen Endpunkt, wenn ein Geschäftsobjekt erzeugt wird.
Nachdem die Geschäftsobjekt Anwendung 1604 das Kundenspezifische Geschäftsobjekt 1608 weiterverarbeitet, wird in einer Ausführungsform die Definition des kundenspezifischen Geschäftsobjekts 1608 modifiziert. Die Organisation kann beispielsweise nun ein Speichern der Adresse ihrer Verbraucher zusätzlich zu dem Vornamen, dem Familiennamen und der Sozialversicherungsnummer ihrer Verbraucher erfordern. Die Adressinformation kann von einer anderen Datenbank als die Datenbanken abgerufen werden, in denen der Vorname, Familienname und die Sozialversicherungsnummer gespeichert sind. Ein Nutzer modifiziert die Definition des kundenspezifischen Geschäftsobjekts 1608. Wenn das Kundenspezifische Geschäftsobjekt 1608 aktualisiert wird, wird die neue Eigenschaft des kundenspezifischen Geschäftsobjekts 1608 erneut veröffentlicht und der dynamische Endpunktgenerator 1602 wird über die Modifikation des Kundenspezifischen Geschäftsobjekts 1608 automatisch benachrichtigt. Der dynamische Endpunktgenerator 1602 aktualisiert seine eigene Informationen und veröffentlicht einen aktualisierten Endpunkt für das Kundenspezifische Geschäftsobjekt 1608. Die Geschäftsobjekt Anwendung 1604 weist daher immer die aktuellsten Endpunktinformationen für das Kundenspezifische Geschäftsobjekt 1608 auf.
Die Geschäftsobjekte werden in einer Ausführungsform einem Client-Gerät mittels einer Webinfrastruktur, wie beispielsweise Windows Communication Foundation (WCF), dargelegt, die ein Teil des.NET Frameworks ist. Das Client-Gerät kann herkömmliche WCF Vorrichtungen verwenden. Der Contract oder Endpunkt wird in einem Beispiel in einem deklarativen Format erzeugt. Das deklarative Format kann XML sein. Die Contracts werden in einer Ausführungsform in der Form herkömmlicher Web Service Definition Language (WSDL) Modelle veröffentlicht. Alternativ können die Endpunkte oder Contracts unter Verwendung Representational State Transfer (REST) veröffentlicht werden, wie beispielsweise Implementieren von XML, dem Atom Syndication Format und/oder Publishing Protocoll (Atom), oder JavaScript Object Notation (JSON). Die Endpunkte können Secure Sockets Layer (SSL) oder Transport Layer Sicherungs-(TSL)Support umfassen.
Die 17 ist ein Flussdiagramm, das einen beispielhaften Prozess 1700 eines Erzeugens, Einsetzens und Veröffentlichens eines Geschäftsobjekts, automatisches Erzeugen eines dynamischen Endpunkts für das Geschäftsobjekt, und Ermöglichen eines Client-Geräts zeigt das Geschäftsobjekt unter Verwendung des dynamischen Endpunkts weiterzuverarbeiten. Der Prozess 1700 ist vorzugsweise in einem oder mehreren Softwareprogrammen ausgeführt, die in einem oder mehreren Speichern gespeichert werden und von einem oder mehreren Prozessoren ausgeführt werden. Der Prozess 1700 kann beispielsweise JavaScript Code (oder irgendeine andere Art an Software) sind, die auf einem Client-Gerät 102 läuft. Obgleich der Prozess 1700 unter Bezug auf das in 17 gezeigte Flussdiagramm beschrieben wird, ist es klar, dass irgendein anderes Verfahren zum Durchführen der mit dem Prozess 1700 assoziierten Handlungen verwendet werden kann. Die Reihenfolge irgendeines Schritts kann beispielsweise geändert werden, und einige der beschriebenen Schritte können optional sein. Einige Schritte können ebenso kombiniert werden, um einen Schritt zu bilden.
Im Allgemeinen, wird ein neues Geschäftsobjekt erzeugt, erzeugt der dynamische Endpunktgenerator automatisch Endpunktinformationen für das Geschäftsobjekt, und ein Client-Gerät kann das Geschäftsobjekt ohne die Notwendigkeit weiterverarbeiten einen Contract oder andere Endpunktinformationen, wie beispielsweise einen Contract, für das Geschäftsobjekt von Hand zu erzeugen.
Eine Erstellungshilfe kann insbesondere verwendet werden, um ein neues Produkte Geschäftsobjekt zu erzeugen, und das Geschäftsobjekt wird anschließend eingesetzt und auf einem Server 192.168.1.38:7 veröffentlicht. Ein dynamischer Endpunk ”http://dlx.denallix.com:8000/Demo” wird für das Geschäftsobjekt erzeugt. Ein Remote-Client-Gerät ProductsSvcClient kann mit dem Endpunkt kommunizieren, so dass der Endpunkt dem Client-Gerät Binding Informationen, Metadaten, Daten und Verfahrens-Contracts bereitstellt. Das Client-Gerät kann Verfahren, wie beispielsweise ProductsSvc_Create, ProductsSvc_Save, ProductsSvc_Delete, ProductsSvc_Load, und ProductsSvc_GetList verwenden, die mit dem Produkte Geschäftsobjekt assoziiert sein können. Das Client-Gerät ProductsSvcClient verarbeitet das Produkte Geschäftsobjekt weiter, und erzeugt Produktberichte, ACME Widgets und ACME Gadgets unter Verwendung eines oder aller Verfahren.
Der Nutzer kann wie in der 18 gezeigt eine Erstellungshilfe 1800 verwenden, um ein neues Geschäftsobjekt zu erzeugen. Das Werkzeug umfasst Templates 1802, um Projekte, Prozesse oder Geschäftsobjekte zu erzeugen. Falls der Nutzer ein neues, leeres Geschäftsobjekt erzeugen möchte, wählt der Nutzer das Geschäftsobjekt Template 1804 aus. Alternativ kann der Nutzer auf andere neulich verwendete Geschäftsobjekte, wie beispielsweise Kunde 1806 und Angestellte 1808, zugreifen und wiederverwenden. Der Nutzer betätigt anschließend den Erzeugen Button, um das neue Geschäftsobjekt mit der Bezeichnung Produkte 1810 zu erzeugen.
Jedes Geschäftsobjekt ist für gewöhnlich mit Eigenschaften und Verfahren assoziiert. Die 19 zeigt, dass in einem Beispiel das Produkte Geschäftsobjekt 1810 fünf voreingestellte Verfahren 1902 aufweist, die der Nutzer unter Verwendung des Produkte Geschäftsobjekts 1810 abrufen kann. Die Verfahren sind Teil eines SmartBox Service 1904, der dem Nutzer zur Verfügung steht. Andere Dienste können dem Nutzer ebenfalls zur Verfügung stehen, und der Nutzer kann Dienste zahlreicher Quellen verwenden und kombinieren. Das neue Produkte Geschäftsobjekt 1810 weist keine Eigenschaften 1906 auf, die bislang mit ihm assoziiert sind.
Der Nutzer kann Eigenschaften hinzufügen, die das Geschäftsobjekt definieren. Die 20 zeigt, dass das Produkt Geschäftsobjekt 1810 durch die ProduktID 2002, den Name 2004, und die Gattung 2006 Eigenschaften definiert ist. Andere Eigenschaften können dem Nutzer ebenso zur Verfügung stehen, und der Nutzer kann Eigenschaften zahlreicher Quellen verwenden und kombinieren. Die ProduktID 2002 wird als die Schlüsseleigenschaft aufgeführt, da der ProduktID Wert für jedes Produkt einmalig ist. Sind einmal die Produkte Geschäftsobjekt Verfahren 1902 und Eigenschaften 1906 definiert, kann das Geschäftsobjekt 1810 wie in der 21 gezeigt in einem Server eingesetzt werden.
Wird einmal ein Geschäftsobjekt eingesetzt, muss es veröffentlicht werden. Durch die Veröffentlichung eines Geschäftsobjekts, kann es von Kunden entdeckt werden, die das Geschäftsobjekt verwenden möchten. Die 22 ist ein Screenshot eines Beispiels einer Veröffentlichung des Produkte Geschäftsobjekts 1810 auf dem 192.168.1.38:7 Server 2202. Steht das Geschäftsobjekt einmal auf dem Server zur Verfügung, wird ein dynamischer Endpunkt automatisch erzeugt, so dass das Geschäftsobjekt von einem Kunden weiterverarbeitet werden kann.
Der Nutzer kann in einer Ausführungsform die Wahl haben zahlreiche Einstellungen zu konfigurieren, die einen Endpunkt betreffen, wie beispielsweise ob ein Endpunkt für ein Geschäftsobjekt aktiviert ist, ob das Geschäftsobjekt davon ausgeschlossen ist Endpunkte aufzuweisen, ob Isolierung für den Endpunkt verwendet wird und ob kundenspezifische Bindings für den Endpunkt verwendet werden.
Die 23 zeigt ein beispielhaftes Flussdiagramm 2300 eines Konfigurierens von Endpunktinformationen für ein Geschäftsobjekt als Antwort auf ein Erzeugen und Veröffentlichen eines Geschäftsobjekts. Ein SmartObject Geschäftsobjekt wird in Schritt 2302 veröffentlicht. Der dynamische Endpunktgenerator überprüft anschließend, ob Endpunkte in den Konfigurationskriterien in Schritt 2304 aktiviert sind. Falls Endpunkte nicht aktiviert sind, wird wie in Schritt 2306 gezeigt ein Endpunkt nicht erzeugt. Falls Endpunkte aktiviert sind, überprüft der dynamische Endpunktgenerator, ob das Geschäftsobjekt davon ausgeschlossen ist an einer Serveraktualisierung teilzunehmen oder ob keine Endpunkte erzeugt werden sollen, wie in Schritt 2308 gezeigt wird. Falls das Geschäftsobjekt ausgeschlossen ist, wir ein Endpunkt wie in Schritt 2310 gezeigt nicht erzeugt. Falls das Geschäftsobjekt nicht ausgeschlossen ist, fährt in Schritt 2312 der dynamische Endpunktgenerator fort einen Endpunkt für das Geschäftsobjekt erzeugen.
Um einen Endpunkt zu erzeugen, lädt der dynamische Endpunktgenerator in einer Ausführungsform die Definition des Geschäftsobjekts und bildet die Datentypen auf Endpunkt unterstützte Datentypen in Schritt 2314 ab. Der dynamische Endpunktgenerator erzeugt in Schritt 2316 Contractsdaten für jeden Geschäftsobjekt Datentyp. Der dynamische Endpunktgenerator erzeugt in Schritt 2318 Betriebsdaten und/oder Bindings für jedes Geschäftsobjekt Verfahren. Der dynamische Endpunktgenerator erzeugt in Schritt 2320 einen Servicecontract für jede Gattung in dem Gattungssystem. Der dynamische Endpunktgenerator erzeugt beispielsweise Endpunkte nicht nur für das Geschäftsobjekt, das in Schritt 2302 veröffentlicht wird, sondern für alle Geschäftsobjekte, die zur gleichen Gattung wie das Geschäftsobjekt gehören, oder für alle Gattungen, die von dem dynamischen Endpunktgenerator erkannt werden.
Ein Nutzer kann in Schritt 2322 konfigurieren, ob Isolierung für den Endpunkt verwendet werden soll. Falls Isolierung nicht verwendet werden soll, wird anschließend der/die gemeinsam genutzter Speicher/Anwendungsdomäne in Schritt 2324 entfernt (unloaded). Ein Nutzer kann in Schritt 2326 konfigurieren, ob kundenspezifische Bindings verwendet werden sollten. Falls kundenspezifische Bindings verwendet werden sollten, wird anschließend ein Endpunkt in dem gemeinsam genutzten Speicher mit kundenspezifischen Sicherungs-Bindings in Schritt 2328 erzeugt. Falls kundenspezifische Bindings nicht verwendet werden sollten, wird anschließend ein Endpunkt in dem gemeinsam genutzten Speicher mit getrennten Sicherungs-Bindings in Schritt 2330 erzeugt.
Falls Isolierung in Schritt 2322 verwendet werden soll, wird anschließend eine isolierte Speicher/Anwendungsdomäne in Schritt 2332 erzeugt. Ein Nutzer kann in Schritt 2338 konfigurieren, ob kundenspezifische Bindings verwendet werden sollten. Falls kundenspezifische Bindings verwendet werden sollten, wird anschließend ein Endpunkt in einem isolierten Speicher mit kundenspezifischen Sicherungs-Bindings in Schritt 2336 erzeugt. Falls kundenspezifische Bindings nicht verwendet werden sollten, wird anschließend ein Endpunkt in einem isolierten Speicher mit getrennten Sicherungs-Bindings in Schritt 2338 erzeugt.
Die Konfigurationskriterien können vorher festgelegt werden oder sie können spezifiziert werden, wenn der Endpunkt erzeugt wird. Die Konfiguration kann an zahlreichen verschiedenen Niveaus durchgeführt werden. Ein Nutzer kann beispielsweise in der Lage sein an dem Dienste Niveau, an einem WCF/REST Protokoll Niveau, oder an einem geführten Niveau zu konfigurieren. Unter Verwendung dieser drei Niveaus zum Konfigurieren, kann ein Nutzer genau den Bereich und wie ein Endpunkt zu erzeugen ist grob steuern.
Die Dienstekonfiguration steuert die voreingestellte Funktionalität der Dienste, einschließlich ob Dienste aktiviert sind abzulaufen oder nicht, oder ob der Endpunktgenerator bestimmte Begebenheiten berücksichtigen wird, wie beispielsweise die Erzeugung eines neuen Geschäftsobjekts. Die WCF/REST Konfiguration ermöglicht einem Nutzer das Leistungsvermögen der voreingestellten Dienste aufzuheben und eine Endpunkt Adresse für den Endpunkttyp, bspw. WCF oder REST, zu spezifizieren.
Die Tabelle 1 stellt ein Bespiel eines beispielhafen Codes für eine voreingestellte Konfiguration dar, worin Endpunkte aktiviert sind.
Tabelle 1
Gesteuerte Endpunkt Konfiguration ermöglicht einem Nutzer nicht nur lediglich einen statischen Endpunkt für ein spezifisches Geschäftsobjekt oder eine Gattung von Geschäftsobjekten zu spezifizieren, sondern ebenso einen isolierten Endpunkt mit seiner eigenen Adresse zu erzeugen. Ohne die gesteuerte Endpunkt Konfiguration, würden alle erzeugten Endpunkte unter einer einzelnen Adresse, bspw. http://dlx.denallix.com:8000/Demo, gespeichert werden, und der Ort jedes Geschäftsobjekts würde an diese Adresse angehängt sein. Ein Nutzer kann mit gesteuerter Endpunkt Konfiguration Adressen für bestimmte Endpunkte spezifizieren, was ein Isolieren solcher Endpunkte ermöglicht.
Ein Endpunkt kann auf mindestens drei Arten isoliert werden: Wenn er in einer anderen Speicherkapazität als andere Endpunkte gespeichert wird, wenn er in einem anderen Uniform Resource Identifier (URI) als andere Endpunkte lokalisiert ist, und wenn die Sicherungs-Bindings auf dem WCF/REST Protokoll Niveau verschieden sind.
Ein Isolieren von Endpunkten in einer anderen Speicherkapazität ermöglicht ein Implementieren einer Sicherungsgrenze um kritische Endpunkte, und ermöglicht ebenso ein Isolieren von Endpunkten, die individuell aktualisiert werden sollen, oder die von ein Aktualisierung ausgenommen werden sollen wenn andere Endpunkte aktualisiert werden. Ein Isolieren von Endpunkten von einer Aktualisierung kann von Nutzen sein, wenn das assoziierte Objekt häufig modifiziert wird. Oder, ein Nutzer kann lediglich wünschen einen spezifischen Endpunkt zu aktualisieren, wie es der Fall sein kann, wenn assoziierte Objekte entwickelt oder implementiert werden. Lediglich ein Endpunkt wird in einer Ausführungsform zur dynamischen Erzeugung isoliert.
Eine zweite Art an Isolierung, die durch gesteuerte Endpunkt Konfiguration ermöglicht wird, ist die URI Isolierung, die ein Zugreifen eines zu isolierenden Endpunkts ermöglicht. Ein Nutzer kann beispielsweise in der Lage sein alle öffentlichen Endpunkte in einem gemeinsamen URI zu hosten, aber in der Lage sein bestimmte private Endpunkte an einem anderen URI zu hosten. Um auf diese privaten Endpunkte zuzugreifen, muss ein Client-Gerät den spezifischen URI kennen. Das Endecken und Zugreifen von Endpunkten kann daher isoliert werden.
Eine dritte Art an Isolierung, die durch gesteuerte Endpunkt Konfiguration ermöglicht wird, ist die Sicherungs-Binding Isolierung, die ein Zugreifen eines zu isolierenden Endpunkts basierend auf der Binding Konfiguration ermöglicht. Ein Nutzer kann beispielsweise in der Lage sein alle öffentlichen WCF und REST Endpunkte unter Verwendung eines gemeinsamen Sicherungs-Bindings für WCF und REST Protokolle zu hosten, allerdings in der Lage sein bestimmte private Endpunkte unter Verwendung einer einmaligen Sicherungs-Binding Konfiguration für WCF oder REST Protokolle zu hosten.
Die zahlreichen Niveaus an Konfigurationseinstellungen ermöglichen in einer Ausführungsform das Erbe von Konfigurationsparametern. Die Dienstekonfiguration hebt in einer Ausführungsform voreingestellte Einstellungen auf, WCF/REST Konfiguration hebt Dienstekonfigurationseinstellungen (so dass ein Nutzer alle die Endpunkte konfigurieren kann, die zu Endpunkten vom WCF/REST Typ passen) auf, und gesteuerte Endpunkt Konfiguration hebt WCF/REST Konfigurationseinstellungen (so dass ein Nutzer individuelle Geschäftsobjekte oder Gattungen von Geschäftsobjekten konfigurieren kann) auf. Jedes folgende Niveau einer Konfiguration- von der Servicekonfiguration über WCF/REST Konfiguration zu gesteuerter Endpunkt Konfiguration reichend- betrifft eine stärkere Logik, die Bedingungen an die Endpunkte, so wie sie erzeugt werden, verstärkt.
Die Tabelle 2 stellt einen beispielhaften Pseudo-Code für Einstellungskonfigurationsoptionen in einer Ausführungsform bereit.
Tabelle 2
Die Tabelle 3 zeigt ein Beispiel unter Verwendung der Endpunktkonfigurationsoptionen, worin WCF Endpunkte eine voreingestellte Service Niveau Konfiguration weitergeben bzw. vererben, REST Endpunkte die voreingestellte Service Niveau Konfiguration aufheben, und gesteuerte Endpunkte die voreingestellte Service Niveau Konfiguration ebenso aufheben.
Tabelle 3
Der dynamische Endpunktgenerator erzeugt in einer Ausführungsform einen Endpunkt für ein Geschäftsobjekt automatisch, sobald das Geschäftsobjekt erzeugt wird. Der dynamische Endpunktgenerator lädt eine Definition des Geschäftsobjekts und iteriert durch die Definition. Die Geschäftsobjektdefinition kann Eigenschaften und Verfahren umfassen. Die Objekt Definition wird auf jede Art auf Endpunkt abgebildet, der, wie beispielsweise WCF oder REST, unterstützt wird, Eigenschaften werden auf Contractsdaten abgebildet, und Verfahren werden auf Betriebsdaten abgebildet. Das Verfahren kann Signaturen aufweisen, die das Verfahren beschreiben. Verfahrenssignaturen können beispielsweise einen Minimalsatz an Informationen definieren, den ein Verfahren zum richtigen Funktionieren benötigt, wie beispielsweise die Eingabe und Ausgabe Datentypen eines Verfahrens.
Der dynamische Endpunktgenerator stellt sicher, das die Signaturen für das Geschäftsobjekt Verfahren Eingaben und Ausgaben umfasst, die durch jede Art an Endpunkt unterstützt werden. Falls nicht, erzeugt der dynamische Endpunktgenerator solche Signaturen für jedes Geschäftsobjekt Verfahren.
Die 24 bis 27 zeigen ein Beispiel eines Weiterverarbeitens eines dynamischen Endpunkts, der für ein Geschäftsobjekt erzeugt wurde. Ein Service muss in einem Beispiel gestartet werden, bevor irgendein Client den Endpunkt verwenden kann. Der Service ist für die Umgebung spezifisch, in der sich der Client aufhält. Ein Client kann anschließend den Service aufrufen und das Verfahren verwendet, das Teil des Service ist.
Die 24 zeigt, dass ein Service ProductsSvc 2402 an dem Endpunkt ”http://dlx.denallix.com:8000/Demo” 2404 Clients ermöglichen wird, die Verfahren ProductsSvc_Create 2406, ProductsSvc_Save 2408, ProductsSvc_Delete 2410, ProductsSvc_Load 2412, und ProductsSvc_GetList 2414 zu verwenden, die mit dem Produkte Geschäftsobjekt 1810 assoziiert sind.
Die 25 zeigt, dass der dynamische Endpunktgenerator eine Seite 2500 bei endpoints.xml erzeugt, die alle WCF und REST Endpunkte aufführt, die basierend auf der derzeitigen Konfiguration erzeugt wurden. Seite 2500 kann aktualisiert werden, immer wenn ein neues oder aktualisiertes Geschäftsobjekt eingesetzt wird, das einen Neustart des Servers verursacht.
Die 26 zeigt einen beispielhaften Code 2602, der verwendet werden kann, um zu Testen, ob ein Service arbeitet. Ein ProductsSvcClient 2604 benannter Client kann die Dienste verwenden, die an dem Endpunkt ”http://dlx.denallix.com:8000/Demo” 2404 verfügbar sind. Die 27 zeigt den Endpunkt 2404 in WSDL, der automatisch erzeugt wird, so dass die Clients das Produkte Objekt 1810 und das Verfahren 1902 verwenden können, das mit dem Produkte Objekt 1810 assoziiert ist. Die 27 führt ein Beispiel einer Adresse 2702, eines Bindings 2704, und eines Contracts 2706 für den Endpunkt 2404 für das Produkte Objekt 1810 auf. Ein Client kann das Produkte Geschäftsobjekt 1810 ohne die Notwendigkeit weiterverarbeiten, das die Endpunktinformation von Hand erzeugt wird.
Die 28 ist ein Screenshot eines Beispiels eines Erzeugens einer neuen Client-Geräte Anwendung 2800. Der Client kann irgendeine Schnittstelle verwenden, die in dem .NET Framework 2802, wie beispielsweise eine Windows Formulare (Windows Forms) Nutzer Schnittstelle 2804, zur Verfügung steht. Andere Schnittstellen 2806 stehen ebenso zur Verfügung. Der Client kann beispielsweise irgendein Framework verwenden, das Endpunkte, wie beispielsweise Java, JavaScript, oder HTML 5, weiterverarbeitet.
Der Client 2800 abonniert in einer Ausführungsform einen Service, der mit dem Produkte Geschäftsobjekt 1810 assoziiert ist, bevor er das Produkte Geschäftsobjekt 1810 weiterverarbeiten kann. Die 29 ist ein Screenshot eines Beispiels des Clients 2800, der eine Service Referenz 2902 hinzufügt.
Die 30 ist ein Screenshot eines Beispiels des Clients 2800, der mit einem Geschäftsobjekt 1810 unter Verwendung eines dynamischen Endpunkts 2404 kommuniziert. Der Client 2800 kann insbesondere auf die Operationen 2406, 2408, 2410, 2412, und 2414 zugreifen, die mit dem Produkte Objekt 1810 assoziiert sind. Ein Client 2800 kann in einer Ausführungsform versuchen ein Geschäftsobjekt unter Verwendung eines Entdeckensfeatures 3002 zu entdecken. Das Geschäftsobjekt weist noch nicht einen Endpunkt oder einen Contract auf, der von dem Client verwendet werden kann. Nachdem der Client in einer Ausführungsform versucht, ein Geschäftsobjekt aus der Ferne zu entdecken, erstellt und veröffentlicht der Server Contracts für das Geschäftsobjekt, nach dem der Client angefragt hat.
In der 30 kann der Client 2800, sobald der Client 2800 den Service ProductsSvc 2402 an dem Endpunkt ”http://dlx.denallix.com:8000/Demo” 2404 hinzufügt, alle Operationen ProductsSvc_Create 2406, ProductsSvc_Save 2408, ProductsSvc_Delete 2410, ProductsSvc Load 2412, und ProductsSvc_GetList 2414 verwenden, die mit dem Produkte Geschäftsobjekt 1810 assoziiert sind.
Die 31 ist ein Screenshot eines Beispiels von Geschäftsobjekt Metadaten, die einem Client-Gerät zur Verfügung gestellt werden. Der Client ProductsSvcClient 2604 kann in diesem Beispiel auf Produkt Geschäftsobjekt Metadaten 3102 zugreifen – insbesondere, da das Name Feld in dem Format Produkte.Name vom Stringtyp ist.
32 ist ein Screenshot eines Beispiels von Geschäftsobjekt Daten und Verfahren, die einem Client-Gerät zur Verfügung gestellt werden. Der Client ProductsSvcClient 2604 kann in diesem Beispiel die Produkt Geschäftsobjekt Daten 3202 und Produkt Geschäftsobjekt Verfahren 1902 verwenden.
Die 33 bis 35 zeigen Beispiele eines Client-Geräts unter Verwendung und Weiterverarbeitung eines Geschäftsobjekts, das in einem WCF Endpunkt offengelegt wurde. Die 33 ist ein Screenshot eines Beispiels des Client-Geräts, das unter Verwendung des Produkt Geschäftsobjekts 1810 neue Produkteaufnahme ACME Widgets 3302 erzeugt. Bevor die Aufnahme erzeugt wird, liegen in dem Aufnahmebereich 3304 kein Produktberichte vor. Wird der Erzeuge Produkt Button 3306 einmal betätigt, wir ein neues Produkt, wie in der 34 gezeigt, erzeugt.
Die 34 ist ein Screenshot eines Beispiels eines neuen Produkt, das ACME Widgets 3302 mit einem Productld von 1 genannt ist. Der Aufnahmebereich 3304 führt nun ACME Widgets 3302 als eine Aufnahme auf. Das Produkte Geschäftsobjekt 1810 kann erneut verwendet werden, um zahlreiche Produkte zu erzeugen. Die 35 ist beispielsweise ein Screenshot eines Beispiels eines anderen neuen Produkts, das ACME Gadgets 3502 mit einem Productld von 2 genannt ist. Der Aufnahmebereich 3304 zeigt sowohl ACME Widgets 3302 als auch ACME Gadgets 3502. Sowohl die Produkte ACME Widgets 3302 und ACME Gadgets 3502 werden unter Verwendung einer Ausführungsform eines dynamischen Endpunkts erzeugt.
Die 36 bis 39 zeigen Beispiele eines Client-Geräts unter Verwendung und Weiterverarbeitens eines Geschäftsobjekt, das in einem REST Endpunkt veröffentlicht wird, um zu zeigen wie ACME Gadgets unter Verwendung eines REST Endpunkts erzeugt werden könnten. Die 36 ist ein Screenshot eines Beispiels eines Client-Geräts unter Verwendung des GetList Verfahrens 2414 in XML. Das GetList Verfahren 2414 ist ein Verfahren für das Produkte Geschäftsobjekt 1810. Die Verwendung des GetList Verfahren 2414 zeigt, dass anfänglich ein Produkt Geschäftsobjekt ACME Widgets 3302 vorliegt.
Die 37 ist ein Screenshot eines Beispiels eines Erzeugens eines Produkt Geschäftsobjekts 1810 unter Verwendung des Erzeugen-(create)Verfahrens 2406. Die 37 zeigt das Erzeugen eines neuen Produkt Geschäftsobjekts, das ACME Gadgets 3502 genannt wird.
Die 38 ist ein Screenshot eines Beispiels der Verwendung des GetList Verfahrens 2414, erneut nachdem ACME Gadgets 3502 erzeugt wurden. Die 38 zeigt, dass das GetList Verfahren 2414 nun zu zwei Produkt Geschäftsobjekten führt: ACME Widgets 3302 und ACME Gadgets 3502.
Die 39 ist ein Screenshot eines Beispiels der Verwendung des GetList Verfahrens 2414 in einem Atom Feed. Die 39 zeigt, dass das GetList Verfahren 2414 zu zwei Reihen an Produkt Geschäftsobjekten für die Objekte ACME Widgets und ACME Gadgets in einem Atom Feed führt.
Irgendeine Geschäftsressource kann in einer Ausführungsform einem Client durch einen dynamischen Endpunkt zur Verfügung gestellt werden. Geschäftsobjekte, Prozesse oder Arbeitslisten können beispielsweise durch einen dynamischen Endpunkt offengelegt werden.
Entwickler haben unter Verwendung der offenbarten Systeme einen Plattformfreien, sofortigen dynamischen Zugriff auf irgendein Geschäftsobjekt. In einer Ausführungsform, werden herkömmlich gefertigte (backend) Systeme, wie beispielsweise SAP, Siebel, Oracle DB, Oracle EBS, und SQL durch den dynamischen Endpunkt offengelegt. Proprietäre gefertigte (backend) Systeme können in einen Ausführungsform, beispielsweise unter der Verwendung von Adaptern, offengelegt werden. Adapter erleichtern ein Offenlegen von Objekten, die auf proprietären Systemen gespeichert werden.
Der Fachmann wird insgesamt bereitwillig anerkennen, dass Verfahren und Vorrichtung zum dynamischen Erzeugen, Entdecken, Zugreifen und Weiterverarbeiten von Geschäftsobjekten offenbart wurden. Die vorstehend aufgeführt Beschreibung wurde zum Zweck der Darstellung und Beschreibung dargelegt. Von ihr ist nicht beabsichtigt vollständig zu sein oder die Erfindung auf die beispielhaften, offenbarten Ausführungsformen zu begrenzen. Irgendwelche Modifikationen und Variationen sind im Lichte der vorstehend aufgeführten Lehre möglich. Es ist beabsichtigt, das der Bereich der Erfindung nicht durch diese ausführliche Beschreibung der Beispiele, sondern eher durch die beigefügten Ansprüche, begrenzt wird.
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 Nicht-Patentliteratur

http://dlx.denallix.com:8000/Demo [0133]
http://dlx.denallix.com:8000/Demo [0146]
http://dlx.denallix.com:8000/Demo [0157]
http://dlx.denallix.com:8000/Demo [0163]

Claims

Computerlesbares Medium, auf dem Instruktionen zum Erzeugen eines dynamischen Endpunkts gespeichert sind, die einem Client-Gerät ermöglichen ein Geschäftsobjekt weiterzuverarbeiten, wobei der Endpunkt eine Adresse, eine Binding, und einen Contract umfasst, wobei die Instruktionen ein Computergerät veranlassen: Laden einer Definition des Geschäftsobjekts, wobei die Definition Eigenschaften und Verfahren aufweist; Iterieren durch die Definition; und Zuordnen der Definition zu Endpunkt-unterstützten Protokollen, wobei das Zuordnen umfasst: (i) Zuordnen der Geschäftsobjekt Eigenschaften zu Contractsdaten, (ii) Zuordnen der Geschäftsobjekt Verfahren zu Betriebsdaten; und (iii) Sicherstellen, dass Geschäftsobjekt Verfahrensignaturen Endpunkt-unterstützte Eingaben und Ausgaben aufweisen; wobei der Endpunkt als Antwort auf mindestens eines von (a) die Client-Gerät fragt das Geschäftsobjekt ab, (b) das Geschäftsobjekt wird erzeugt und (c) das Geschäftsobjekt wird aktualisiert, erzeugt wird.
Computerlesbares Medium nach Anspruch 1, worin die Instruktionen ferner bewirken, dass das Computergerät .NET Endpunkte zur Verwendung in einem WCF Framework erzeugt und Atom, XML, und JSON Endpunkte zur Verwendung in einem REST Framework erzeugt,
Computerlesbares Medium nach Anspruch 1, worin das Geschäftsobjekt zu einer Kategorie gehört, und der Endpunkt für die Kategorie erzeugt wird.
Computerlesbares Medium nach Anspruch 1, worin die Instruktionen ferner bewirken, dass das Computergerät den Endpunkt basierend auf einer Konfiguration erzeugt.
Computerlesbares Medium nach Anspruch 4, worin die Konfiguration umfasst Dienstekonfiguration, WCF Konfiguration, REST Konfiguration, und gesteuerte Konfiguration.
Computerlesbares Medium nach Anspruch 5, worin gesteuerte Konfiguration Konfigurieren umfasst, ob ein statischer Endpunkt für das Geschäftsobjekt erzeugt wird und ob der Endpunkt isoliert ist.
Computerlesbares Medium nach Anspruch 6, worin das Isolieren mindestens eines von (i) Speicherisolierung, (ii) Adresse Isolierung und (iii) Sicherungs-Binding Isolierung umfasst.
Computerlesbares Medium nach Anspruch 6, worin Konfigurieren des Isolierens Konfigurieren mindestens eines von (i) ob ein Server alle Endpunkte auf dem Server neu installiert oder (ii) ob der Server weniger als alle die Endpunkte auf dem Server neu installiert, erlaubt.
System zum Erzeugen eines dynamischen Endpunkts, der einem Client-Gerät ermöglicht ein Geschäftsobjekt weiterzuverarbeiten, worin der Endpunkt eine Adresse, eine Binding, und einen Contract umfasst, umfassend einen Prozessor, der aufgebaut ist, bei dem System zu bewirken: Laden einer Definition des Geschäftsobjekts, worin die Definition Eigenschaften und Verfahren aufweist; Iterieren durch die Definition; und Zuordnen der Definition zu Endpunkt-unterstützten Protokollen, worin das Zuordnen umfasst: (i) Zuordnen der Geschäftsobjekt Eigenschaften zu Contractsdaten, (ii) Zuordnen der Geschäftsobjekt Verfahren zu Betriebsdaten, und (iii) Sicherstellen, dass das Geschäftsobjekt Verfahrensignaturen Endpunkt-unterstützte Eingaben und Ausgaben aufweisen; worin der Endpunkt als Antwort auf mindestens eines von (a) die Client-Gerät fragt das Geschäftsobjekt ab, (b) das Geschäftsobjekt wird erzeugt, und (c) das Geschäftsobjekt wird aktualisiert, erzeugt wird.
System nach Anspruch 9, worin der Prozessor strukturiert ist ferner zu bewirken, dass das System .NET Endpunkte zur Verwendung in einem WCF Framework erzeugt und Atom, XML, und JSON Endpunkte zur Verwendung in einem REST Framework erzeugt.
System nach Anspruch 9, worin das Geschäftsobjekt zu einer Kategorie gehört, und der Endpunkt für die Kategorie erzeugt wird.
System nach Anspruch 9, worin der Prozessor aufgebaut ist ferner zu bewirken, dass das System den Endpunkt basierend auf einer Konfiguration erzeugt.
System nach Anspruch 12, worin die Konfiguration Dienstekonfiguration, WCF Konfiguration, REST Konfiguration, und gesteuerte Konfiguration umfasst.
System nach Anspruch 13, worin gesteuerte Konfiguration Konfigurieren umfasst, ob ein statischer Endpunkt für das Geschäftsobjekt erzeugt wird und ob der Endpunkt isoliert ist.
System nach Anspruch 14, worin das Isolieren mindestens eines von (i) Speicherisolierung, (ii) Adresse Isolierung und (iii) Sicherungs-Binding Isolierung umfasst.
System nach Anspruch 14, worin Konfigurieren des Isolierens Konfigurieren mindestens eines von (i) ob ein Server alle Endpunkte auf dem Server neu installiert, oder (ii) ob der Server weniger als alle die Endpunkte auf dem Server neu installiert, ermöglicht.