DE60029349T2

DE60029349T2 - Anordnung für die auf komponenten basierte durchführung von aufgaben während der bearbeitung von versicherungsansprüchen

Info

Publication number: DE60029349T2
Application number: DE60029349T
Authority: DE
Inventors: V. George Bethlehem GUYAN; H. Robert Minneapolis PISH; Carles Chicago MUNTADA
Original assignee: Accenture LLP
Current assignee: Accenture LLP
Priority date: 1999-05-04
Filing date: 2000-05-04
Publication date: 2007-07-05
Anticipated expiration: 2020-05-05
Also published as: US20030145124A1; EP1688880A3; CA2371703C; US7617240B2; DE60029349D1; WO2000067181A3; EP2336961A1; EP1688880A2; WO2000067181A2; ATE333127T1; ES2267534T3; EP1250667B1; AU4701900A; EP2336961B1; EP1250667A2; CA2371703A1

Description

GEBIET DER ERFINDUNG
Die vorliegende Erfindung bezieht sich auf eine Vorrichtung zum Betreiben von komponentenbasierter Software, die zum Auswählen von Tasks bzw. Aufgaben in der Lage ist. Insbesondere bezieht sie sich auf eine Aufgabenverwaltung zum Handhaben einer Aufgabe während einer Versicherungsanspruchsverarbeitung unter Nutzung eines Computersystems.
HINTERGRUND DER ERFINDUNG
Computer sind im Leben heutzutage eine Notwendigkeit geworden. Sie treten weltweit in fast jedem Büro und Haushalt auf. Eine repräsentative Hardwareumgebung ist in einer 1 gemäß dem Stand der Technik dargestellt, die einen typischen Hardwareaufbau einer Workstation mit einer Zentraleinheit 110 wie beispielsweise einem Mikroprozessor und einer Anzahl von über einen Systembus 112 gegenseitig verbundenen anderen Einheiten veranschaulicht. Die in der 1 gezeigte Workstation weist einen Schreib-Lese-Speicher mit wahlfreiem Zugriff (RAM) 114, einen Nur-Lese-Speicher (ROM) 116, einen E/A-Adapter 118 zum Verbinden von Peripherievorrichtungen wie beispielsweise Plattenspeichereinheiten 120 mit dem Bus 112, einen Benutzerschnittstellenadapter 122 zum Verbinden einer Tastatur 124, einer Maus 126, eines Lautsprechers 128, eines Mikrophons 132 und/oder anderer Benutzerschnittstellenvorrichtungen wie beispielsweise eines (nicht gezeigten) Berührungsbildschirms mit dem Bus 112, einen Kommunikationsadapter 134 zum Verbinden der Workstation mit einem Kommunikationsnetz (zum Beispiel einem Datenverarbeitungsnetz) und einen Anzeigenadapter 136 zum Verbinden des Bus 112 mit einer Anzeigevorrichtung 138 auf. Die Workstation hat typischerweise darauf resident ein Betriebssystem wie beispielsweise das Betriebssystem (OS) Microsoft Windows NT oder Windows/95, das Betriebssystem IBM OS/2, das MAC OS oder das Betriebssystem UNIX.
Eine objektorientierte Programmierung (OOP) ist zunehmend zum Entwickeln von komplexen Anwendungen verwendet worden. Während die OOP sich zu der Hauptströmung des Softwareentwurfs und der Softwareentwicklung hin bewegt, erfordern verschiedene Softwarelösungen eine Anpassung, um die Vorteile der OOP auszunutzen. Es besteht ein Bedarf daran, diese Prinzipien der OOP auf eine Mitteilungsübermittlungsschnittstelle eines elektronischen Mitteilungsübermittlungssystems derart anzuwenden, dass ein Satz von OOP-Klassen und -Objekten für die Mitteilungsübermittlungsschnittstelle bereitgestellt werden kann.
Die OOP ist ein Prozess des Entwickelns von Computersoftware unter Verwendung von Objekten einschließlich der Schritte des Analysierens des Problems, Entwerfens des Systems und Aufbauens des Programms. Ein Objekt ist ein Softwarepaket, das sowohl Daten als auch eine Sammlung von zugehörigen Strukturen und Prozeduren enthält. Da es sowohl Daten als auch eine Sammlung von Strukturen und Prozeduren enthält, kann man es sich als eine autarke Komponente vorstellen, die keine anderen zusätzlichen Strukturen, Prozeduren oder Daten zum Durchführen ihrer spezifischen Aufgabe benötigt. Die OOP betrachtet daher ein Computerprogramm als eine Sammlung von als Objekte bezeichneten, in hohem Maße autonomen Komponenten, von denen jede für eine spezifische Aufgabe verantwortlich ist. Dieses Konzept des Packens von Daten, Strukturen und Prozeduren zusammen in eine Komponente oder ein Modul wird als Einkapselung bezeichnet.
Im Allgemeinen sind OOP-Komponenten wieder verwendbare Softwaremodule, die eine Schnittstelle, die einem Objektmodell entspricht, bieten und auf die während der Laufzeit durch eine Komponentenintegrationsarchitektur zugegriffen wird. Eine Komponentenintegrationsarchitektur ist ein Satz von Architekturmechanismen, die es Softwaremodulen in verschiedenen Prozessräumen ermöglichen, Fähigkeiten oder Funktionen jedes anderen zu nutzen. Dies wird im Allgemeinen getan, indem ein gemeinsames Komponentenobjektmodell angenommen wird, auf dem die Architektur aufzubauen ist. Es ist lohnend, an diesem Punkt zwischen einem Objekt und einer Klasse von Objekten zu unterscheiden. Ein Objekt ist ein einzelnes Beispiel für die Klasse von Objekten, die häufig einfach als eine Klasse bezeichnet wird. Eine Klasse von Objekten kann als ein Plan, aus dem viele Objekte erzeugt werden können, betrachtet werden.
Die OOP ermöglicht es dem Programmierer, ein Objekt zu erzeugen, das ein Teil eines anderen Objekts ist. Zum Beispiel soll ein einen Kolbenmotor darstellendes Objekt eine Zusammensetzungsbeziehung mit dem einen Kolben darstellenden Objekt haben. In der Realität umfasst ein Kolbenmotor einen Kolben, Ventile und viele andere Komponenten; die Tatsache, dass ein Kolben ein Element eines Kolbenmotors ist, kann in der OOP durch zwei Objekte logisch und semantisch dargestellt werden.
Die OOP ermöglicht auch eine Erzeugung eines Objekts, das "von" einem anderen Objekt "abhängt". Wenn zwei Objekte vorhanden sind, wobei eines einen Kolbenmotor darstellt und das andere einen Kolbenmotor, bei dem der Kolben aus Keramik ist, darstellt, dann ist die Beziehung zwischen den zwei Objekten nicht die der Zusammensetzung. Ein Keramikkolbenmotor bildet keinen Kolbenmotor. Vielmehr ist er lediglich eine Art von Kolbenmotor, die eine Beschränkung mehr als der Kolbenmotor hat; sein Kolben ist aus Keramik. In diesem Fall wird das den Keramikkolbenmotor darstellende Objekt als ein abgeleitetes Objekt bezeichnet, und es erbt alle die Aspekte des den Kolbenmotor darstellenden Objekts und fügt eine weitere Beschränkung oder ein weiteres Detail zu ihm hinzu. Das den Keramikkolbenmotor darstellende Objekt "hängt von" dem den Kolbenmotor darstellenden Objekt "ab". Die Beziehung zwischen diesen Objekten wird als Vererbung bezeichnet.
Wenn das Objekt oder die Klasse, das oder die den Keramikkolbenmotor darstellt, alle die Aspekte der den Kolbenmotor darstellenden Objekte erbt, erbt es die in der Kolbenmotorklasse definierten thermischen Kennwerte eines Standardkolbens. Das Keramikkolbenmotorobjekt überschreibt diese jedoch mit keramikspezifischen thermischen Kennwerten, die typischerweise von den mit einem Metallkolben verbundenen thermischen Kennwerten verschieden sind. Es springt über das Original und verwendet sich auf Keramikkolben beziehende neue Funktionen. Verschiedene Arten von Kolbenmotoren haben verschiedene Kennwerte, aber sie können die gleichen mit ihnen verbundenen zugrunde liegenden Funktionen haben (zum Beispiel wie viele Kolben in dem Motor, Zündsequenzen, Schmierung usw.). Zum Zugreifen auf jede von diesen Funktionen in einem beliebigen Kolbenmotorobjekt würde ein Programmierer die gleichen Funktionen mit den gleichen Namen benennen, aber jeder Typ von Kolbenmotor kann verschiedene/übergehende Realisierungen von Funktionen hinter dem gleichen Namen haben. Diese Fähigkeit zum Verstecken von verschiedenen Realisierungen einer Funktion hinter dem gleichen Namen wird als Polymorphismus bezeichnet, und sie vereinfacht eine Kommunikation zwischen Objekten sehr.
Mit den Konzepten der Zusammensetzungsbeziehung, der Einkapselung, der Vererbung und des Polymorphismus kann ein Objekt so ziemlich alles in der realen Welt darstellen. Faktisch ist die logische Wahrnehmung der Realität die einzige Grenze bei einem Bestimmen der Arten von Dingen, die bei objektorientierter Software Objekte werden können. Einige typische Kategorien stellen sich dar wie folgt:

• Objekte können physische Objekte wie beispielsweise Automobile in einer Verkehrsflusssimulation, elektrische Komponenten in einem Schaltungsentwurfsprogramm, Länder in einem Volkswirtschaftsmodell oder Flugzeuge in einem Luftverkehrssteuerungssystem darstellen.
• Objekte können Elemente der Computer-Benutzer-Umgebung wie beispielsweise Fenster, Menüs oder graphische Objekte darstellen.
• Ein Objekt kann ein Inventar wie beispielsweise eine Personaldatei oder eine Tabelle der Breiten und Längen von Städten darstellen.
• Ein Objekt kann benutzerdefinierte Datentypen wie beispielsweise Zeit, Winkel und komplexe Zahlen oder Punkte auf der Ebene darstellen.

Mit dieser enormen Fähigkeit eines Objekts zum Darstellen so ziemlich jeder logisch trennbaren Dinge ermöglicht es die OOP dem Softwareentwickler, ein Computerprogramm zu entwerfen und realisieren, das ein Modell von einigen Aspekten der Realität ist, ob die Realität eine physische Einheit, ein Prozess, ein System oder eine Zusammensetzung von Dingen ist. Da das Objekt alles darstellen kann, kann der Softwareentwickler ein Objekt erzeugen, das in der Zukunft in einem größeren Softwareprojekt als eine Komponente verwendet werden kann.
Wenn 90% eines neuen OOP-Softwareprogramms aus geprüften, vorhandenen Komponenten bestehen, die aus vorher vorhandenen wieder verwendbaren Objekten ausgebildet werden, dann müssen nur die übrig bleibenden 10% des neuen Softwareprojekts von Grund auf geschrieben und getestet werden. Da 90% bereits aus einem Inventar von eingehend getesteten wieder verwendbaren Objekten kamen, beträgt der potentielle Bereich, in dem ein Fehler seinen Ursprung haben könnte, 10% des Programms. Folglich ermöglicht es die OOP Softwareentwicklern, Objekte aus anderen, vorher aufgebauten Objekten aufzubauen.
Dieser Prozess ähnelt komplexen Maschinen, die aus Baugruppen und Unterbaugruppen aufgebaut werden, eng. OOP-Technologie bildet daher eine Softwaretechnik dahingehend, dass Software aus vorhandenen Komponenten, die als Objekte für den Entwickler verfügbar sind, aufgebaut wird, mehr wie eine Hardwaretechnik aus. All dies läuft auf eine verbesserte Qualität der Software sowie eine erhöhte Geschwindigkeit ihrer Entwicklung hinaus.
Die WO 91/08453 A beschreibt ein Computersystem für eine Programmcodeentwicklungsumgebung. Das System empfängt eine in einem Datenarchiv bzw. einer Datenablage gespeicherte höhere Regelsprachenprogrammiersprache zusammen mit in einer zentralen Ablage gespeicherten Modellierungsdaten. Das System gibt die gespeicherten Daten und die gespeicherte Regelsprache in eine Systemerzeugungseinheit zum Erzeugen eines natürlichen Programmquellcodes in einer durch verschiedene Hardwareeinheiten unterstützten Sprache ein und assembliert und kompiliert daraufhin den Code. Das System weist Entwicklungswerkbankmodule auf, um es dem Programmierer zu ermöglichen, eine Einheit und Beziehungen zu bestimmen sowie Regeln, Komponenten, Ansichten, gespeicherte und Fensterfelder einzugeben, die in einer Datenablage gespeichert sind und in das endgültige ausführbare Programm integriert werden.
POTEL M: "MVP: Model-View-Presenter – The Taligent Programming Model for C++ and Java" Taligent Inc. 1996 beschreibt ein offenes Klassenprogrammiermodell für objektorientierte Rahmen, das eine Programmierung in zwei grundlegenden Konzepten begrifflich erfasst: Datenverwaltung und Benutzerschnittstelle. Die Datenverwaltung schließt ein Modellieren von Datenübersichten, ein Auswählen von Datenuntermengen und ein Identifizieren von Operationen, die bei den Daten durchgeführt werden können, ein. Die Benutzerschnittstelle schließt ein Betrachten der Daten, benutzereingeleitete Aktionen, die auf die Daten einwirken, und ein Darstellen der auf die Daten abgebildeten Interaktionen ein. Es wird ferner beschrieben, wie diese Aktionen bei der Datenverwaltung und der Benutzerschnittstelle abhängig von der in Client-Server-Umgebungen bestimmten Aufteilung verschieden liegen können.
ZUSAMMENFASSUNG DER ERFINDUNG
Ein Ziel der vorliegenden Erfindung besteht darin, eine Vorrichtung zum Betreiben von komponentenbasierter Software, die zum Auswählen von Aufgaben in der Lage ist, bereitzustellen, was einen aufwendigen, zeitraubenden Prozess, bevor ein Code geschrieben wird, vermeidet.
Gemäß der Erfindung wird dieses Ziel durch eine Vorrichtung mit den Merkmalen des Patentanspruchs 1 erreicht.
Vorteilhafte weitere Entwicklungen sind in den abhängigen Patenansprüchen definiert.
Gemäß der Erfindung weist die Vorrichtung ein Computerprogramm zum Betreiben von komponentenbasierter Software, die zum Handhaben von versicherungsbezogenen Aufgaben in der Lage ist, auf. Das Programm weist eine Datenkomponente, die Daten unter Nutzung einer Vielzahl von Funktionen speichert, wiedergewinnt und manipuliert, auf. Ferner ist eine Clientkomponente, die einen Clientkomponentenadapter, der Daten zu/von der Datenkomponente sendet und empfängt, aufweist, bereitgestellt. Die Clientkomponente weist auch ein Geschäftsobjekt, das als ein Daten-Cache dient und eine Logik zum Manipulieren der Daten aufweist, auf. Es ist auch eine Benutzerschnittstellensteuerungseinrichtung bzw. Benutzerschnittstellensteuerungseinheit enthalten, die dazu eingerichtet ist, durch einen Benutzer erzeugte Ereignisse unter Nutzung des Geschäftsobjekts zum Speichern von Daten im Cache und des Clientkomponentenadapters zum letztendlichen Persistentmachen von Daten in einer Datenablage zu handhaben. In Verwendung ermöglicht es die Clientkomponente einem Benutzer, Aufgaben zu definieren, die bei ihrem Abschluss ein versicherungsbezogenes Ziel erreichen. Darüber hinaus ist der Benutzer dazu in der Lage, Regeln einzugeben, die vorschreiben, welche Aufgaben basierend auf einem Satz von vorbestimmten Ereignissen ausgewählt werden sollten. Daraufhin werden Ereignisse aus einer beliebigen Quelle wie beispielsweise einer gemeinsamen Ereigniswarteschlange empfangen. Schließlich werden basierend auf den empfangenen Ereignissen Aufgaben ausgewählt und ausgegeben.
BESCHREIBUNG DER ZEICHNUNGEN
Die vorhergehenden Ziele sowie Ausgestaltungen und Vorteile werden anhand der folgenden ausführlichen Beschreibung eines bevorzugten Ausführungsbeispiels der Erfindung unter Bezugnahme auf die Zeichnungen besser verstanden, in denen:
1 gemäß dem Stand der Technik ein schematisches Diagramm der vorliegenden Erfindung zeigt; und
2A ein Blockschaltbild eines Ausführungsbeispiels der vorliegenden Erfindung zeigt.
2B ein Flussdiagramm zeigt, das darstellt, wie Komponenten gemäß einem Ausführungsbeispiel der vorliegenden Erfindung allgemein arbeiten.
2C ein Flussdiagramm zeigt, das darstellt, wie die UI-Steuerungseinrichtung bzw. UI-Steuerungseinheit gemäß einem Ausführungsbeispiel der vorliegenden Erfindung arbeitet.
2D ein Flussdiagramm zeigt, das die Interaktionen zwischen dem CCA, der CCI und der Serverkomponente gemäß einem Ausführungsbeispiel der vorliegenden Erfindung darstellt.
3 den Lebenszyklus einer typischen Benutzerschnittstelle und die Standardverfahren, die zu dem Fensterverarbeitungsrahmen gehören, zeigt.
4 eine Veranschaulichung zeigt, die darstellt, wie verschiedene Sprachen neu gestrichen (repainted) und neu kompiliert werden.
5 ein Blockschaltbild eines Architekturobjekts zeigt.
6 eine Veranschaulichung zeigt, die das physische Layout von CodierungDecodierung-Tabellen bzw. CodeDecode-Tabellen gemäß einem Ausführungsbeispiel der vorliegenden Erfindung darstellt.
7 ein Logikdiagramm gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zeigt.
8 ein Blockschaltbild des Sicherheitsrahmens und seiner Komponenten zeigt.
9 eine Veranschaulichung zeigt, die die Beziehungen zwischen dem Sicherheitselement und anderen Elementen darstellt.
10 eine Veranschaulichung der Verhandlungskomponente eines Ausführungsbeispiels der vorliegenden Erfindung zeigt;
11 ein Flussdiagramm der durch die Organisationskomponente eines Ausführungsbeispiels der vorliegenden Erfindung ausgeführten Operationen zeigt;
12 eine Veranschaulichung der Teilnehmerkomponente eines Ausführungsbeispiels der vorliegenden Erfindung zeigt;
13 ein Flussdiagramm der durch die Aufgabenassistentenkomponente eines Ausführungsbeispiels der vorliegenden Erfindung ausgeführten Operationen zeigt;
14 eine Veranschaulichung der Ereignisverarbeitungseinheit zusammen mit anderen Komponenten des Systems gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zeigt; und
15 eine Veranschaulichung der Aufgabeneinheit gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zeigt.
OFFENBARUNG DER ERFINDUNG
Programmiersprachen beginnen, die OOP-Prinzipien wie beispielsweise Verkapselung, Vererbung, Polymorphismus und Zusammensetzungsbeziehung voll zu unterstützen. Mit dem Erscheinen der Sprache C++ haben viele kommerzielle Softwareentwickler die OOP angenommen. C++ ist eine OOP-Sprache, die einen schnellen, maschinell ausführbaren Code bietet. Überdies ist C++ für Projekte sowohl der kommerziellen Anwendung als auch der Systemprogrammierung geeignet. Einstweilen scheint C++ unter vielen OOP-Programmierern die populärste Wahl zu sein, aber es ist eine Unmenge von anderen OOP-Sprachen wie beispielsweise Smalltalk, Common Lisp Object System (CLOS) und Eiffel vorhanden. Zusätzlich werden herkömmlicheren populären Computerprogrammiersprachen wie beispielsweise Pascal OOP-Fähigkeiten hinzugefügt.
Die Vorteile von Objektklassen können zusammengefasst werden wie folgt:

• Objekte und ihre entsprechenden Klassen zerlegen komplexe Programmierprobleme in viele kleinere, einfachere Probleme.
• Eine Einkapselung erzwingt durch die Organisation von Daten in kleine, unabhängige Objekte, die miteinander kommunizieren können, eine Datenabstraktion. Die Einkapselung schützt die Daten in einem Objekt vor einer zufälligen Beschädigung, aber ermöglicht es anderen Objekten, durch ein Aufrufen der Mitgliedsfunktionen und -strukturen des Objekts mit den Daten zu interagieren.
• Eine Unterklassifizierung (Subclassing) und eine Vererbung ermöglichen es, Objekte durch ein Ableiten von neuen Arten von Objekten aus den in dem System verfügbaren Standardklassen zu erweitern und modifizieren. Somit werden neue Fähigkeiten erzeugt, ohne dass ganz von vorne angefangen werden muss.
• Ein Polymorphismus und eine Mehrfachvererbung ermöglichen es verschiedenen Programmierern, charakteristische Merkmale von vielen verschiedenen Klassen zu mischen und anzupassen und spezialisierte Objekte, die immer noch auf voraussagbare Weisen mit zugehörigen Objekten arbeiten können, zu erzeugen.
• Klassenhierarchien und Eindämmungshierarchien stellen einen flexiblen Mechanismus zum Modellieren von Objekten der realen Welt und der Beziehung zwischen ihnen bereit.
• Bibliotheken von wieder verwendbaren Klassen sind in vielen Situationen verwendbar, aber sie haben auch einige Beschränkungen. Zum Beispiel:
• Komplexität. In einem komplexen System können die Klassenhierarchien für zugehörige Klassen äußerst verwirrend werden, mit vielen dutzenden oder sogar hunderten von Klassen.
• Ablauf der Steuerung. Ein mit der Hilfe von Klassenbibliotheken geschriebenes Programm ist immer noch für den Ablauf der Steuerung verantwortlich (das heißt es muss die Interaktionen zwischen allen den aus einer speziellen Bibliothek erzeugten Objekten steuern). Der Programmierer muss entscheiden, welche Funktionen für welche Arten von Objekten zu welchen Zeiten aufzurufen sind.
• Verdoppelung der Anstrengung. Obwohl Klassenbibliotheken es Programmierern ermöglichen, viele kleine Stücke von Code zu verwenden und wieder zu verwenden, setzt jeder Programmierer die Stücke auf eine verschiedene Weise zusammen. Zwei verschiedene Programmierer können abhängig von hunderten von kleinen Entscheidungen, die jeder Programmierer nebenbei trifft, den gleichen Satz von Klassenbibliotheken zum Schreiben von zwei Programmen verwenden, die genau dasselbe tun, aber deren interne Struktur (das heißt deren Entwurf) ziemlich verschieden sein kann. Unvermeidlich enden ähnliche Stücke von Code damit, dass sie ähnliche Dinge auf leicht verschiedene Weisen tun und nicht so gut zusammenarbeiten wie sie sollten.

Klassenbibliotheken sind sehr flexibel. Während Programme komplexer werden, sind mehr Programmierer gezwungen, grundlegende Lösungen für grundlegende Probleme immer wieder neu zu erfinden. Eine relativ neue Erweiterung des Klassenbibliothekskonzepts besteht darin, einen Rahmen von Klassenbibliotheken zu haben. Dieser Rahmen ist komplexer und besteht aus bedeutsamen Sammlungen von zusammenarbeitenden Klassen, die sowohl die kleinen Muster als auch große Mechanismen, die die gemeinsamen Anforderungen und den gemeinsamen Entwurf in einem spezifischen Anwendungsbereich realisieren, erfassen. Sie wurden zuerst aus den an einem Anzeigen von Menüs, Fenstern, Dialogfeldern und anderen Standardbenutzerschnittstellenelementen für Personal Computer beteiligten Arbeiten für Programmierer von freien Anwendungen entwickelt.
Rahmen repräsentieren auch eine Änderung der Weise, in der Programmierer über die Interaktion zwischen dem Code, den sie schreiben, und durch andere geschriebenem Code nachdenken. In den frühen Tagen der prozeduralen Programmierung rief der Programmierer durch das Betriebssystem bereitgestellte Bibliotheken auf, um bestimmte Aufgaben durchzuführen, aber grundsätzlich lief das Programm die Seite herunter vom Anfang bis zum Ende ab, und der Programmierer war einzig und allein für den Ablauf der Steuerung verantwortlich. Dies war für ein Ausdrucken von Gehaltsschecks, ein Berechnen einer mathematischen Tabelle oder ein Lösen anderer Probleme mit einem Programm, das auf genau eine Weise ablief, passend.
Die Entwicklung von graphischen Benutzerschnittstellen begann diesen prozeduralen Programmierungsaufbau umzukrempeln. Diese Schnittstellen ermöglichen es dem Benutzer eher als eine Programmlogik, das Programm anzusteuern und zu entscheiden, wann gewisse Aktionen durchgeführt werden sollten. Heutzutage erreicht die meiste Software für Personal Computer dies mittels einer Ereignisschleife, die die Maus, die Tastatur und andere Quellen von externen Ereignissen überwacht und die passenden Teile des Codes des Programmierers gemäß Aktionen, die der Benutzer durchführt, aufruft. Der Programmierer bestimmt nicht mehr die Reihenfolge, in der Ereignisse auftreten. Stattdessen wird ein Programm in getrennte Stücke aufgeteilt, die zu nicht voraussagbaren Zeiten und in einer nicht voraussagbaren Reihenfolge aufgerufen werden. Indem die Steuerung auf diese Weise an Benutzer abgetreten wird, erzeugt der Entwickler ein Programm, das viel leichter zu verwenden ist. Dennoch rufen einzelne Stücke des durch den Entwickler geschriebenen Programms immer noch durch das Betriebssystem bereitgestellte Bibliotheken auf, um gewisse Aufgaben zu erfüllen, und der Programmierer muss immer noch den Ablauf der Steuerung in jedem Stück, nachdem es durch die Ereignisschleife aufgerufen ist, bestimmen. Anwendungscode "sitzt" immer noch "oben auf" dem System.
Selbst Ereignisschleifenprogramme verlangen von Programmierern, viel Code zu schreiben, bei dem es nicht nötig sein sollte, ihn für jede Anwendung getrennt zu schreiben. Das Konzept eines Anwendungsrahmens bringt das Ereignisschleifenkonzept weiter. Statt sich mit allen den praktischen Grundlagen des Aufbauens von grundlegenden Menüs, Fenstern und Dialogfeldern zu befassen und daraufhin diese Dinge alle zum Zusammenarbeiten zu veranlassen fangen Anwendungsrahmen verwendende Programmierer hier mit arbeitendem Anwendungscode und grundlegenden Benutzerschnittstellenelementen an. Anschließend bauen sie von dort aus auf, indem sie einige der generischen Fähigkeiten des Rahmens durch die spezifischen Fähigkeiten der beabsichtigten Anwendung ersetzen.
Anwendungsrahmen verringern die gesamte Menge von Code, die ein Programmierer von Grund auf schreiben muss. Da jedoch der Rahmen wirklich eine generische Anwendung ist, die Fenster anzeigt, ein Kopieren und Einfügen unterstützt usw., kann der Programmierer auch die Steuerung in einem größeren Maße abgeben als es Ereignisschleifenprogramme erlauben. Der Rahmencode kümmert sich um beinahe die ganze Ereignishandhabung und den ganzen Ablauf der Steuerung, und der Code des Programmierers wird nur aufgerufen, wenn der Rahmen ihn benötigt (zum Beispiel zum Erzeugen oder Manipulieren einer proprietären Datenstruktur).
Ein ein Rahmenprogramm schreibender Programmierer gibt nicht nur die Steuerung an den Benutzer ab (wie es auch für Ereignisschleifenprogramme zutrifft), sondern gibt auch den detaillierten Ablauf der Steuerung in dem Programm an den Rahmen ab. Dieser Ansatz ermöglicht die Erzeugung von komplexeren Systemen, die im Gegensatz zu isolierten Programmen, die maßgeschneiderten Code haben und für ähnliche Probleme immer wieder erzeugt werden, auf interessante Weisen zusammenarbeiten.
Somit ist wie vorstehend erläutert ein Rahmen grundsätzlich eine Sammlung von zusammenarbeitenden Klassen, die eine wieder verwendbare Entwurfslösung für einen gegebenen Problembereich bilden. Er weist typischerweise Objekte auf, die ein vorgegebenes Verhalten bereitstellen (zum Beispiel für Menüs und Fenster), und Programmierer verwenden ihn, indem sie einiges von dem vorgegebenen Verhalten vererben und ein anderes Verhalten übergehen, so dass der Rahmen Anwendungscode zu den passenden Zeiten aufruft.
Es sind drei Hauptunterschiede zwischen Rahmen und Klassenbibliotheken vorhanden:

• Verhalten gegen Protokoll. Klassenbibliotheken sind im Wesentlichen Sammlungen von Verhalten, die du aufrufen kannst, wenn du die einzelnen Verhalten in deinem Programm möchtest. Ein Rahmen stellt demgegenüber nicht nur ein Verhalten, sondern auch das Protokoll oder den Satz von Regeln, die die Weisen, auf die Verhalten kombiniert werden können, leiten einschließlich Regeln dafür, was ein Programmierer bereitstellen soll, gegen das, was der Rahmen bereitstellt, bereit.
• Aufruf gegen Übergehen. Mit einer Klassenbibliothek instanziiert der Programmierer Objekte und ruft ihre Mitgliedsfunktionen auf. Es ist möglich, Objekte mit einem Rahmen auf die gleiche Weise zu instanziieren und aufzurufen (das heißt den Rahmen als eine Klassenbibliothek zu behandeln), aber um den wieder verwendbaren Entwurf eines Rahmens voll auszunutzen, schreibt ein Programmierer typischerweise Code, der übergeht und durch den Rahmen aufgerufen wird. Der Rahmen verwaltet den Ablauf der Steuerung zwischen seinen Objekten. Ein Schreiben eines Programms umfasst eher ein Aufteilen von Verantwortlichkeiten unter den verschiedenen Stücken von Software, die durch den Rahmen aufgerufen werden, als ein Bestimmen, wie die verschiedenen Stücke zusammenarbeiten sollten.
• Realisierung gegen Entwurf. Mit Klassenbibliotheken verwenden Programmierer nur Realisierungen wieder, wohingegen sie mit Rahmen einen Entwurf wieder verwenden. Ein Rahmen verkörpert die Weise, auf die eine Familie von zusammengehörigen Programmen oder Stücken von Software arbeitet. Er stellt eine generische Entwurfslösung dar, die an eine Vielfalt von spezifischen Problemen in einem gegebenen Bereich angepasst werden kann. Ein einzelner Rahmen kann zum Beispiel die Weise verkörpern, auf die eine Benutzerschnittstelle arbeitet, wenn auch zwei mit dem gleichen Rahmen erzeugte verschiedene Benutzerschnittstellen ziemlich verschiedene Schnittstellenprobleme lösen können.

Somit können durch die Entwicklung von Rahmen für Lösungen für verschiedene Probleme und Programmieraufgaben bedeutsame Verringerungen der Entwurfs- und Entwicklungsanstrengung für Software erreicht werden. Ein bevorzugtes Ausführungsbeispiel der Erfindung nutzt Hypertext Markup Language (HTML) zum Realisieren von Dokumenten auf dem Internet zusammen mit einem universellen sicheren Kommunikationsprotokoll für ein Transportmedium zwischen dem Client und der Newco. HTTP oder andere Protokolle können ohne ein übermäßiges Experimentieren leicht an die Stelle von HTML gesetzt werden. Informationen über diese Produkte sind in T. Berners-Lee, D. Connoly, "RFC 1866: Hypertext Markup Language – 2.0" (Nov. 1995); und R. Fielding, H. Frystyk, T. Berners-Lee, J. Gettys und J. C. Mogul, "Hypertext Transfer Protocol – HTTP/1.1: HTTP Working Group Internet Draft" (2. Mai 1996) verfügbar. HTML ist ein einfaches Datenformat, das zum Erzeugen von Hypertext- Dokumenten, die von einer Plattform zu einer anderen portierbar sind, verwendet wird. HTML-Dokumente sind SGML-Dokumente mit einer generischen Semantik, die für ein Darstellen von Informationen aus einem breiten Spektrum von Bereichen passend sind. HTML ist durch die globale Informationsinitiative des World-Wide Web seit 1990 in Verwendung gewesen. HTML ist eine Anwendung des ISO-Standards 8879; 1986 Information Processing Text and Office Systems; Standard Generalized Markup Language (SGML).
Bis heute sind Web-Entwicklungswerkzeuge in ihrer Fähigkeit zum Erzeugen von dynamischen Web-Anwendungen die sich von einem Client zu einem Server erstrecken und mit vorhandenen Rechenbetriebsmitteln zusammenarbeiten, begrenzt gewesen. Bis vor kurzem ist HTML die bei der Entwicklung von Web-basierten Lösungen verwendete dominierende Technologie gewesen. HTML hat sich jedoch in den folgenden Bereichen als unzulänglich erwiesen:

• Schlechte Leistung;
• Beschränkte Benutzerschnittstellenfähigkeiten;
• Kann nur statische Web-Seiten produzieren;
• Fehlen von Interoperabilität mit vorhandenen Anwendungen und Daten; und
• Unfähigkeit zum Skalieren.

Die Sprache Java von Sun Microsystem löst viele der Probleme auf der Clientseite durch ein:

• Verbessern der Leistung auf der Clientseite;
• Ermöglichen der Erzeugung von dynamischen Echtzeit-Web-Anwendungen; und
• Bereitstellen der Fähigkeit zum Erzeugen einer breiten Vielfalt von Benutzerschnittstellenkomponenten.

Mit Java können Entwickler robuste Benutzerschnittstellen-Komponenten (UI-Komponenten) erzeugen. Angepasste "Widgets" (zum Beispiel Echtzeitaktienlaufschriften, animierte Icons bzw. Symbole usw.) können erzeugt werden, und die Leistung auf der Clientseite wird verbessert. Anders als HTML unterstützt Java den Gedanken der Validierung auf der Clientseite und des Abladens einer passenden Verarbeitung auf den Client für eine verbesserte Leistung. Dynamische Echtzeit-Web-Seiten können erzeugt werden. Unter Verwendung der vorstehend angeführten angepassten UI-Komponenten können auch dynamische Web-Seiten erzeugt werden.
Die Sprache Java von Sun hat sich als eine durch die Industrie anerkannte Sprache zum "Programmieren des Internets" herausgestellt. Sun definiert Java als: "eine einfache, objektorientierte, verteilte, interpretierte, robuste, sichere, architekturneutrale, portierbare, leistungsstarke, multithreading-fähige, dynamische, schlagwortverträgliche, universelle Programmiersprache. Java unterstützt eine Programmierung für das Internet in der Form von plattformunabhängigen Java-Applets." Java-Applets sind kleine, spezialisierte Anwendungen, die der Java-Anwendungsprogrammierschnittstelle (Java-API) von Sun entsprechen, die es Entwicklern ermöglicht, "interaktiven Inhalt" zu Web-Dokumenten hinzuzufügen (zum Beispiel einfache Animationen, Seitenverziehrungen, einfache Spiele usw.). Applets laufen in einem Java-kompatiblen Browser (zum Beispiel Netscape Navigator) ab, indem Code von dem Server zu dem Client kopiert wird. Von einem Sprachstandpunkt aus basiert der Kernmerkmalssatz von Java auf C++. Die Java-Literatur von Sun gibt an, dass Java grundsätzlich "C++ mit Erweiterungen von objektivem C für eine dynamischere Verfahrenslösung" ist.
Eine andere Technologie, die eine ähnliche Funktion wie JAVA bereitstellt, wird durch Microsoft und ActiveX-Technologien (ActiveX Technologies) bereitgestellt, um Entwicklern und Web-Entwerfern Mittel zum Aufbauen von dynamischem Inhalt für das Internet und Personal Computer zu geben. ActiveX weist Werkzeuge zum Entwickeln einer Animation, einer dreidimensionalen virtuellen Realität, eines Videos und von anderem Multimediainhalt auf. Die Werkzeuge verwenden Internet-Standards, arbeiten auf mehreren Plattformen und werden durch über 100 Firmen unterstützt. Die Aufbaublöcke der Gruppe werden als ActiveX-Controls bzw. ActiveX-Steuerungen bezeichnet, kleine, schnelle Komponenten, die es Entwicklern ermöglichen, Teile von Software in Hypertext-Markup-Language-Seiten (HTML-Seiten) einzubetten. ActiveX-Steuerungen arbeiten mit einer Vielfalt von Programmiersprachen einschließlich Microsoft Visual C++, Borland Delphi, Microsoft Visual Basic Programmiersystem und in der Zukunft dem Entwicklungswerkzeug von Microsoft für Java, dessen Codename "Jakarta" ist. ActiveX-Technologien schließen auch einen ActiveX-Serverrahmen ein, der es Entwicklern ermöglicht, Serveranwendungen zu erzeugen. Ein Durchschnittsfachmann erkennt leicht, dass ActiveX ohne ein übermäßiges Experimentieren an die Stelle von JAVA gesetzt werden könnte, um die Erfindung in die Praxis umzusetzen.
Ausführliche Beschreibung
Ein Ausführungsbeispiel der vorliegenden Erfindung ist ein serverbasierter Rahmen, der eine komponentenbasierte Architektur nutzt. Mit Bezug auf die 2A weist ein Ausführungsbeispiel der vorliegenden Erfindung ein Architekturobjekt 200, ein Anwendungsobjekt 202, ein Benutzerschnittstellenformular 204, eine Benutzerschnittstellensteuerungseinrichtung bzw. Benutzerschnittstellensteuerungseinheit 206, einen Clientkomponentenadapter 208, eine COM-Komponentenschnittstelle 210 und eine Serverkomponente 222 auf.
Im Allgemeinen arbeiten die Komponenten der vorliegenden Erfindung wie in der 2B gezeigt. In einem Schritt 230 werden Daten in einem Objekt der Komponente gespeichert. In einem Schritt 232 werden Funktionen, die das Objekt manipulieren, mit den Objektdaten eingekapselt. Später können in einem Schritt 234 die gespeicherten Objektdaten unter Nutzung der Funktionen des Schritts 232 durch andere Komponenten manipuliert werden.
Architekturobjekt
Das Architekturobjekt 200 stellt ein leicht zu verwendendes Objektmodell bereit, das die Komplexität der Architektur auf dem Client verschleiert. Das Architekturobjekt 200 stellt rein technische Dienste bereit und enthält nicht irgendeine Geschäftslogik oder irgendeinen Funktionscode. Es wird auf dem Client als der einzige Zugriffspunkt für alle Architekturdienste verwendet.
Auf der Serverseite wird das Architekturobjekt 200 durch einen Satz von in Standard-VB-Modulen enthaltenen globalen Funktionen unterstützt.
Das Architekturobjekt 200 ist für ein Bereitstellen aller Clientarchitekturdienste (das heißt Codetabellenzugriff, Fehlerprotokollierung usw.) und eines einzelnen Eingangspunkts für Architekturdienste verantwortlich. Das Architekturobjekt ist auch dafür verantwortlich, es der Architektur zu ermöglichen, dass sie als eine autonome Einheit vorhanden ist, so dass es ermöglicht wird, interne Änderungen an der Architektur mit minimalen Auswirkungen auf die Anwendung auszubilden.
Das Architekturobjekt 200 stellt eine Codeverwaltungseinheit, ein Clientprofil, eine Textverwaltungseinheit, eine ID-Verwaltungseinheit, eine Registrierdatenbankverwaltungseinheit, eine Protokollverwaltungseinheit, eine Fehlerverwaltungseinheit und eine Sicherheitsverwaltungseinheit bereit. Die Codeverwaltungseinheit liest Codes aus einer lokalen Datenbank auf dem Client, führt die Codes in Objekte und macht sie für die Anwendung verfügbar. Das Clientprofil stellt Informationen über den derzeit angemeldeten Benutzer bereit. Die Textverwaltungseinheit stellt verschiedene Textmanipulationsdienste wie beispielsweise ein Suchen und Ersetzen bereit. Die ID-Verwaltungseinheit erzeugt eindeutige IDs und Zeitstempel. Die Registrierdatenbankverwaltungseinheit kapselt einen Zugriff auf die Systemregistrierdatenbank ein. Die Protokollverwaltungseinheit schreibt Fehler- oder Informationsnachrichten in das Nachrichtenprotokoll. Die Fehlerverwaltungseinheit stellt einen leichten Weg zum Speichern bzw. Sichern und Neuvorbringen eines Fehlers bereit. Und die Sicherheitsverwaltungseinheit bestimmt, ob der derzeitige Benutzer zum Durchführen gewisser Aktionen autorisiert ist oder nicht.
Anwendungsobjekt
Das Anwendungsobjekt 202 hat ein Verfahren zum Einleiten jeder Geschäftsoperation in der Anwendung. Es verwendet ein spätes Binden zum Instanziieren von Ziel-UI-Steuerungseinheiten, um eine Autonomie zwischen Fenster bereitzustellen. Dies ermöglicht es verschiedenen Steuerungseinheiten, das Anwendungsobjekt 202 ohne ein statisches Verknüpfen mit jeder UI-Steuerungseinrichtung bzw. UI-Steuerungseinheit in der Anwendung zu verwenden.
Wenn es eine UI-Steuerungseinheit öffnet, ruft das Anwendungsobjekt 202 die Architekturinitialisierungs-, Klasseninitialisierungs- und Formularinitialisierungsmitgliedsfunktionen auf.
Das Anwendungsobjekt 202 hält eine Liste von jedem aktiven Fenster, so dass es die Anwendung in dem Fall eines Fehlers schließen bzw. ausschalten kann. Wenn ein Fenster sich schließt, teilt es dies dem Anwendungsobjekt 202 mit und wird aus der Liste von aktiven Fenstern des Anwendungsobjekts 202 entfernt.
Das Anwendungsobjekt 202 ist für ein Instanziieren jeder UI-Steuerungseinheit 206, ein Leiten von Daten/Geschäftskontext zu der Ziel-UI-Steuerungseinheit 206 und ein Aufrufen von Standarddiensten wie beispielsweise Steuerungseinheit initialisieren, Formular initialisieren und Architektur initialisieren verantwortlich. Das Anwendungsobjekt 202 verfolgt auch, welche Fenster aktiv sind, so dass es den Ausschaltprozess koordinieren kann.
UI-Formular
Die primäre Verantwortlichkeit des UI-Formulars 204 besteht darin, wichtige Ereignisse zu seiner Steuerungseinheit 206 weiterzuleiten. Es bleibt größtenteils unintelligent und enthält so wenig Logik wie möglich. Die meisten Ereignishandhabungseinheiten bei dem Formular delegieren die Arbeit einfach, indem sie Verfahren auf der Steuerungseinheit 206 des Formulars aufrufen.
Das UI-Formular 204 gibt seine eigenen Steuerungen nie frei oder sperrt sie, sondern bittet seine Steuerungseinheit 206, es stattdessen zu tun. Eine Logik ist nur dann in dem UI-Formular 204 enthalten, wenn sie eine sehr einfache Feldmaskierung oder kleinere visuelle Details umfasst.
Das UI-Formular 204 präsentiert eine leicht zu verwendende, graphische Schnittstelle für den Benutzer und informiert seine Steuerungseinheit 206 über wichtige Benutzeraktionen. Das UI-Formular 204 kann auch eine grundlegende Datenvalidierung (zum Beispiel eine Datentypvalidierung) durch eine Eingabemaskierung bereitstellen. Darüber hinaus ist das UI-Formular für ein intelligentes Ändern seiner Größe, ein Starten einer kontextempfindlichen Hilfe und ein Ausladen von sich selbst verantwortlich.
Benutzerschnittstellensteuerungseinheit
Jede UI-Steuerungseinheit 206 weist einen Satz von Standardverfahren zur Initialisierung, zum Freigeben und zum Sperren von Steuerungen bei seinem UI-Formular 204, zum Validieren von Daten in dem Formular, zum Gewinnen von Daten aus dem UI-Formular 204 und zum Ausladen des UI-Formulars 204 auf.
UI-Steuerungseinheiten 206 enthalten die Mehrheit der Logik zum Manipulieren von Geschäftsobjekten 207 und Verwalten des Aussehens ihres UI-Formulars 204. Falls ihr Formular nicht nur zum Lesen ist, verfolgt die UI-Steuerungseinheit 206 auch, ob sich Daten in dem UI-Formular 204 geändert haben oder nicht, um unnötige Datenbankschreibvorgänge zu vermeiden, wenn der Benutzer sich entscheidet, zu sichern. Darüber hinaus verfolgen Steuerungseinheiten von Hilfsfenstern (wie dem Dateispeicherungsdialogfeld in Microsoft Word) ihre aufrufende UI-Steuerungseinheit 206, so dass sie es mitteilen können, wenn sie zum Schließen bereit sind.
Die 2C zeigt ein Flussdiagramm, das darstellt, wie die UI-Steuerungseinheit bei einem Ausführungsbeispiel der vorliegenden Erfindung arbeitet. In einem Schritt 236 werden durch einen Benutzer Daten in einem UI-Formular eingetragen. In einem Schritt 238 interpretiert die UI-Steuerungseinheit die in das UI-Formular eingetragenen Daten. In einem Schritt 240 platziert die UI-Steuerungseinheit die passenden Daten in einem später zu nutzenden und wiederzugewinnenden Geschäftsobjekt.
Eine UI-Steuerungseinheit 206 definiert eine logische Arbeitseinheit (LUW bzw. Logical Unit of Work). Falls eine LUW mehr als eine UI-Steuerungseinheit 206 umfasst, wird die LUW als ein getrenntes Objekt realisiert.
Die UI-Steuerungseinheit 206 ist für ein Handhaben von durch den mit dem UI-Formular 204 interagierenden Benutzer erzeugten Ereignissen und ein Bereitstellen einer komplexen Feldvalidierung und einer feldüberschreitenden Validierung in einer logischen Arbeitseinheit verantwortlich. Die UI-Steuerungseinheit 206 enthält auch die Logik zum Interagieren mit Geschäftsobjekten 207 und erzeugt nötigenfalls neue Geschäftsobjekte 207. Schließlich interagiert die UI-Steuerungseinheit 206 zum Hinzufügen, Wiedergewinnen, Modifizieren oder Löschen von Geschäftsobjekten 207 mit Clientkomponentenadaptern 208 und handhabt alle Fehler auf der Clientseite.
Geschäftsobjekte
Die primäre Funktionalität des Geschäftsobjekts (BO bzw. Business Object) 207 besteht darin, als ein Datenhalter zu fungieren, der es ermöglicht, Daten unter Verwendung eines objektbasierten Programmiermodells quer über Benutzerschnittstellensteuerungseinheiten 206 gemeinsam zu nutzen.
BOs 207 führen eine Validierung bei ihren Attributen durch, da sie dazu eingerichtet werden, die Integrität der Informationen, die sie enthalten, aufrechtzuerhalten. BOs 207 zeigen auch andere Verfahren als Zugreifer bzw. Accessoren zum Manipulieren ihrer Daten, wie beispielsweise Verfahren zum Ändern des Lebenszykluszustands eines BOs 207 oder zum Ableiten des Werts eines berechneten Attributs.
In vielen Fällen wird ein BO 207 seine eigene Tabelle in der Datenbank und sein eigenes Fenster für Betrachtungs- oder Bearbeitungsoperationen haben.
Geschäftsobjekte 207 enthalten Informationen über eine einzelne Geschäftseinheit und erhalten die Integrität der Informationen aufrecht. Das BO 207 kapselt Geschäftsregeln, die zu der einzelnen Geschäftseinheit gehören, ein und erhält Beziehungen mit anderen Geschäftsobjekten aufrecht (zum Beispiel enthält ein Anspruch eine Sammlung von Ergänzungen). Schließlich stellt das BO 207 sich auf den Status der Informationen, die es enthält, beziehende zusätzliche Eigenschaften bereit (wie beispielsweise ob die Informationen sich geändert haben oder nicht), stellt nötigenfalls eine Validierung von neuen Daten bereit und berechnet Attribute, die aus anderen Attributen abgeleitet werden (wie beispielsweise einen vollen Namen, der aus einem Vornamen, einer mittleren Initiale und einem Nachnamen abgeleitet wird).
Clientkomponentenadapter
Clientkomponentenadapter (CCAs) 208 sind für ein Wiedergewinnen, ein Hinzufügen, ein Aktualisieren und ein Löschen von Geschäftsobjekten in der Datenbank verantwortlich. CCAs 208 verbergen das Speicherformat und den Ort von Daten vor der UI-Steuerungseinheit 206. Die UI-Steuerungseinheit 206 sorgt sich nicht darum, wo oder wie Objekte gespeichert sind, da der CCA 208 sich darum kümmert.
Der CCA 208 führt in durch den Server zurückgegebenen Datensatzgruppen enthaltene Daten in Geschäftsobjekte 207. CCAs 208 maskieren alle Fernanforderungen von der UI-Steuerungseinheit 206 an eine spezifische Komponente und fungieren als ein "Haken" ("hook") für Dienste wie beispielsweise eine Datenkomprimierung und eine Datenverschlüsselung.
COM-Komponentenschnittstelle
Eine COM-Komponentenschnittstelle (CCI) 210 ist ein "Vertrag" für durch eine Komponente bereitgestellte Dienste. Durch ein "Realisieren" einer Schnittstelle (CCI) 210 verspricht eine Komponente, alle die durch die CCI 20 definierten Dienste bereitzustellen.
Die CCI 210 ist keine physische Einheit (weshalb sie mit einer gestrichelten Linie dargestellt ist). Der einzige Grund für ihr Vorhandensein besteht darin, die Weise zu definieren, in der eine Komponente sich für andere Objekte zeigt. Sie weist die Signaturen oder Kopfteile aller der öffentlichen Eigenschaften oder Verfahren, die eine Komponente bereitstellen wird, auf.
Zum Realisieren einer CCI 210 zeigt eine Serverkomponente einen Satz von speziell genannten Verfahren, ein Verfahren für jedes bei der Schnittstelle definierte Verfahren. Diese Verfahren sollten nichts tun außer die Anforderung an ein privates Verfahren auf der Komponente, das die reale Arbeit tun wird, zu delegieren.
Die CCI 210 definiert einen Satz von durch eine Komponente bereitgestellten zugehörigen Diensten. Die CCI ermöglicht es jeder Komponente, sich hinter der Schnittstelle zu "verbergen", um die durch die Schnittstelle definierten Dienste durch ein "Realisieren" der Schnittstelle durchzuführen.
Serverkomponente
Serverkomponenten 222 sind grobkörnig und transaktionsorientiert. Sie sind für eine maximale Effizienz entworfen.
Serverkomponenten 222 kapseln den ganzen Zugriff auf die Datenbank ein und definieren Geschäftstransaktionsgrenzen. Darüber hinaus sind Serverkomponenten 222 dafür verantwortlich, sicherzustellen, dass Geschäftsregeln während Datenzugriffsoperationen Folge geleistet wird.
Eine Serverkomponente 222 führt Datenzugriffsoperationen im Auftrag von CCAs 208 oder anderen Komponenten durch und nimmt durch ein Kommunizieren mit anderen Serverkomponenten 222 an sich über Serverkomponenten 222 erstreckenden Transaktionen teil. Die Serverkomponente 222 ist durch mehrere Eingangspersönlichkeiten (front end personalities) (zum Beispiel aktive Serverseiten) zugänglich und enthält eine zum Aufrechterhalten der Integrität von Daten in der Datenbank entworfene Geschäftslogik.
Die 2D zeigt ein Flussdiagramm, das die Interaktionen zwischen dem CCA, der CCI und der Serverkomponente gemäß einem Ausführungsbeispiel der vorliegenden Erfindung darstellt. In einem Schritt 242 wird eine Anforderung zum Platzieren von durch einen Client erzeugten Daten in der Serverdatenbank ausgebildet. In einem Schritt 244 werden die Daten unter Nutzung einer CCI 210 zu der Serverkomponente 222 transferiert. In einem Schritt 246 speichert die Serverkomponente 222 die Daten in der Serverdatenbank.
GESCHÄFTSREGELPLATZIERUNG
Überblick
Die Verteilung von Geschäftsregeln quer über Reihen bzw. Ränge (tiers) der Anwendung beeinflusst direkt die Robustheit und Leistung des Systems als Ganzes. Geschäftsregeln können in die folgenden Abschnitte kategorisiert werden: Beziehungen, Berechnungen und Geschäftsereignisse.
Beziehungen zwischen Geschäftsobjekten
Geschäftsobjekte 207 sind dafür verantwortlich, andere Geschäftsobjekte 207, mit denen sie verbunden sind, zu kennen.
Beziehungen zwischen BOs 207 werden durch den CCA 208 während des Führungsprozesses aufgebaut. Wenn zum Beispiel ein CCA 208 ein Anspruchs-BO 207 aufbaut, wird er nötigenfalls auch die Sammlung von Ergänzungen aufbauen.
Berechnete Geschäftsdaten
Auf Attributen des Geschäftsobjekts 207 basierende Berechnungen umfassende Geschäftsregeln sind in den Geschäftsobjekten 207 selbst codiert. Ein voller Name eines Teilnehmers ist ein gutes Beispiel für ein berechnetes Attribut. Statt die Steuerungseinheiten zu zwingen, jedes Mal, wenn sie den vollen Namen anzeigen möchten, den Vornamen, die mittlere Initiale und den Nachnamen zu verketten, wird ein berechnetes Attribut, das diese Logik durchführt, auf dem Geschäftsobjekt gezeigt. Auf diese Weise muss der Code zum Zusammensetzen des vollen Namens nur einmal geschrieben werden und kann durch viele Steuerungseinheiten 206 verwendet werden.
Ein anderes Beispiel für ein berechnetes Attribut ist das Anzeigedatum einer wiederholten Aufgabe. Wenn eine Aufgabe mit einer Wiederholungsregel abgeschlossen wird, muss ein neues Anzeigedatum bestimmt werden. Dieses Anzeigedatum wird basierend auf dem Datum, an dem die Aufgabe abgeschlossen wurde, und der durch die Wiederholungsregel definierten Frequenz der Wiederholung berechnet. Die Logik zum Berechnen des neuen Anzeigedatums in das Aufgaben-BO 207 zu legen stellt sicher, dass sie nur einmal codiert wird.
Antworten auf Geschäftsereignisse
Geschäftsregeln, die sich auf Systemereignisse beziehen und keine Benutzerinteraktion umfassen, werden auf den Serverkomponenten durchgeführt.
Ein Abschluss einer Aufgabe ist ein größeres Ereignis in dem System. Wenn eine Aufgabe abgeschlossen wird, stellt das System zuerst sicher, dass der die Aufgabe abschließende Ausführende zu dem Anspruch hinzugefügt wird. Nachdem die Aufgabe in der Datenbank als abgeschlossen markiert ist wird daraufhin überprüft, um zu sehen, ob die Aufgabe eine Wiederholungsregel hat. Falls dem so ist, wird eine andere Aufgabe erzeugt und zu der Datenbank hinzugefügt. Schließlich wird die Ereigniskomponente benachrichtigt, da es sein kann, dass die Aufgabeneinheit auf den Aufgabenabschluss reagieren muss.
Es wird das Szenario in Betracht gezogen, dass die Logik zum Durchführen dieser Regel auf der UI-Steuerungseinheit 206 platziert wäre.
Die Steuerungseinheit 206 ruft die Ausführendenkomponente auf, um zu sehen, ob der die Aufgabe abschließende Ausführende zu dem Anspruch hinzugefügt worden ist. Wenn der Ausführende nicht zu dem Anspruch hinzugefügt worden ist, dann ruft die Steuerungseinheit 206 die Ausführendenkomponente wieder auf, um ihn hinzuzufügen.
Als Nächstes ruft die Steuerungseinheit 206 die Aufgabenkomponente auf, um die Aufgabe in der Datenbank als abgeschlossen zu markieren. Falls die Aufgabe eine Wiederholungsregel hat, berechnet die Steuerungseinheit 206 das Datum, an dem die Aufgabe neu anzuzeigen ist, und ruft die Aufgabenkomponente wieder auf, um eine neue Aufgabe hinzuzufügen. Zum Schluss ruft die Steuerungseinheit 206 die Ereigniskomponente auf, um die Aufgabeneinheit von dem Aufgabenabschluss zu benachrichtigen.
Die vorstehende Realisierung erfordert in ihrem schlechtesten Fall fünf Netzumläufe. Darüber hinaus muss jede andere Steuerungseinheit 206 oder Serverkomponente 222, die eine Aufgabe abschließen möchte, diese Logik nochmals codieren. Ein Durchführen dieser Regel in der Aufgabenserverkomponente 222 verringert die Anzahl von Netzumläufen und beseitigt die Notwendigkeit, die Logik mehr als einmal zu codieren.
Antworten auf Benutzerereignisse
Alle Antworten auf Benutzerereignisse werden durch die Steuerungseinheit 206 koordiniert. Die Steuerungseinheit 206 ist für Aktionen wie beispielsweise ein Freigeben oder Sperren von Steuerungen bei seinem Formular, ein Anfordern einer Autorisierung von der Sicherheitskomponente oder ein Ausbilden von Aufrufen zu dem CCA 208 verantwortlich.
Autorisierung
Die ganze Logik zum Gewähren einer Autorisierung ist im Innern der Sicherheitskomponente eingekapselt.
Steuerungseinheiten 206 und Komponenten 222 müssen die Sicherheitskomponente fragen, ob der derzeitige Benutzer zum Ausführen gewisser Geschäftsoperationen in dem System autorisiert ist. Die Sicherheitskomponente wird gemäß einer vordefinierten Sicherheitslogik ja oder nein antworten.
Zusammenfassung
FENSTERVERARBEITUNGSRAHMEN
Der Vorgabefensterrahmen stellt eine Vorgabefensterverarbeitung für jedes in dem System enthaltene Fenster bereit. Diese Vorgabeverarbeitung unterstützt den Entwickler bei einem Entwickeln von robusten, wartbaren UIs, standardisiert gemeinsame Prozesse (wie beispielsweise eine Formularinitialisierung) und erleichtert eine glatte Integration mit Architekturdiensten.
Die 3 zeigt den Lebenszyklus einer typischen Benutzerschnittstelle und die Standardverfahren, die zu dem Fensterverarbeitungsrahmen 300 gehören.
Der Fensterverarbeitungsrahmen 300 umfasst das Folgende:
Fensterinitialisierung 302;
Fenstersicherungsverarbeitung 304;
Fenstersteuerungszustandsverwaltung 306;
Fensterdatenvalidierung 308;
Fensterausschaltverarbeitung 310.
Fensterinitialisierungsverarbeitung 302: Nach einem Erzeugen einer Steuerungseinheit 206 für das gewünschte Fenster ruft das Anwendungsobjekt 202 einen Satz von Standardinitialisierungsfunktionen auf der Steuerungseinheit 206 auf, bevor das Formular 204 für den Benutzer angezeigt wird. Ein Standardisieren dieser Funktionen macht die UIs überall in der Anwendung homogener, während eine gute Funktionszerlegung gefördert wird.
Fenstersicherungsverarbeitung 304: Zu jeder Zeit, zu der ein Benutzer einen beliebigen Formulartext aktualisiert oder ein Element zu einem Listenfeld hinzufügt, markiert die UI-Steuerungseinheit 206 das Formular als "dirty" bzw. "schmutzig". Dies ermöglicht es der UI-Steuerungseinheit 206, zu bestimmen, ob Daten sich geändert haben, wenn das Formular sich schließt, und den Benutzer zum Übertragen oder Verlieren seiner Änderungen aufzufordern.
Fenstersteuerungszustandsverwaltung 306: Ein Freigeben und Sperren von Steuerungen und Menüoptionen ist ein sehr komplexer Teil des Aufbauens einer UI. Die Logik, die den Zustand von Steuerungen modifiziert, ist zur Wartbarkeit an einer einzelnen Stelle eingekapselt.
Fensterdatenvalidierung 308: Wann immer sich in einem Formular Daten ändern, können Validierungsregeln gebrochen werden. Die Steuerungseinheit ist dazu in der Lage, die Änderungen zu erfassen, die Daten zu validieren und den Benutzer zum Korrigieren von ungültigen Einträgen aufzufordern.
Fensterausschaltverarbeitung 310: Der Fensterausschaltrahmen stellt einen klaren Beendungsweg für jede UI in dem Fall eines Fehlers bereit. Dies verringert das Risiko von Speicherlecks und allgemeinen Schutzverletzungen.
Vorteile
Standardisierte Verarbeitung: Ein Standardisieren der Fensterverarbeitung erhöht die Homogenität der Anwendung. Dies stellt sicher, dass alle Fenster in der Anwendung für die Endbenutzer in einer konsistenten Art und Weise funktionieren, was bewirkt, dass die Anwendung leichter zu verwenden ist. Es verkürzt auch die Lernkurve für Entwickler und erhöht die Wartbarkeit, da alle Fenster in einer konsistenten Art und Weise codiert sind.
Vereinfachte Entwicklung: Entwickler können die in dem Fensterverarbeitungsrahmen dokumentierten besten Praktiken wirksam einsetzen, um erfolgreiche Entwurfs- und Codierungsentscheidungen zu treffen. Darüber hinaus stellt eine Hülle bzw. Shell einen "konservierten" ("canned") Code bereit, der Entwicklern während der Codierungsanstrengung einen Vorsprung gibt.
Geschichtete Architektur: Da mehrere Architekturmodule eine standardisierte Verarbeitung für jedes Anwendungsfenster bereitstellen, kann die Kernlogik für jedes Systemfenster geändert werden, indem einfach Modifikationen bei einer einzelnen Prozedur ausgebildet werden.
Fensterinitialisierung 302
Zum Öffnen eines neuen Fensters erzeugt das Anwendungsobjekt 202 die Steuerungseinheit 206 des Zielfensters und ruft eine Folge von Verfahren auf der Steuerungseinheit 206 auf, um sie zu initialisieren. Das Aufrufen dieser Verfahren, ArchInitClass, InitClass, InitForm und ShowForm, ist nachstehend veranschaulicht.
ArchInitClass
Der Hauptzweck der ArchInitClass-Funktion besteht darin, der Zielsteuerungseinheit 206 mitzuteilen, wer sie aufruft. Das Anwendungsobjekt 202 "führt die Einführungen aus", indem es eine Bezugnahme auf sich selbst und eine Bezugnahme auf die aufrufende Steuerungseinheit 206 zu der Zielsteuerungseinheit 206 leitet. Darüber hinaus dient es als ein Haken in die Steuerungseinheit 206 zum Hinzufügen von Architekturfunktionalität in der Zukunft.
InitClass
Diese Funktion stellt einen Weg für das Anwendungsobjekt 202 zum Zuweisen irgendwelcher Daten zu der Zielsteuerungseinheit 206, die sie zum Ausführen ihrer Verarbeitung benötigt, bereit. An diesem Punkt kann die Zielsteuerungseinheit 206 bestimmen, in welcher "Betriebsart" sie sich befindet. Typische Formularbetriebsarten schließen eine Hinzufügungsbetriebsart, eine Bearbeitungsbetriebsart und eine Betrachtungsbetriebsart ein. Falls das Fenster sich in der Hinzufügungsbetriebsart befindet, erzeugt es bei diesem Verfahren ein neues BO 207 des passenden Typs.
InitForm
Die InitForm-Prozedur jeder Steuerungseinheit 206 koordiniert eine Initialisierung des Formulars 204, bevor es angezeigt wird. Da die Initialisierung häufig ein Prozess mit mehreren Schritten ist, erzeugt InitForm das Fenster und delegiert daraufhin den Großteil der Initialisierungslogik an Helferverfahren, die jeweils einen einzigen Zweck haben, um den Regeln der guten Funktionszerlegung zu folgen. Zum Beispiel ist die Logik zum Bestimmen des Zustands eines Formulars 204 basierend auf Benutzeraktionen und relevanten Sicherheitsbeschränkungen und zum Bewegen zu dem Zustand in dem BestimmeFormularZustand-Verfahren bzw. DetermineFormState-Verfahren eingekapselt.
PopulateForm
PopulateForm ist ein privates Verfahren, das für ein Füllen des Formulars mit Daten während der Initialisierung verantwortlich ist. Es wird durch das InitForm-Verfahren genau einmal aufgerufen. PopulateForm wird zum Füllen von Kombinationsfeldern in einem Formular204, zum Gewinnen der Details eines Objekts für ein Bearbeitungsfenster oder zum Anzeigen von Objekten, die bereits durch den Benutzer ausgewählt worden sind, wie bei dem folgenden Beispiel verwendet.
ShowForm
Das ShowForm-Verfahren zentriert das neu initialisierte Formular 204 einfach und zeigt es an.
Fenstersteuerungszustandsverwaltung 306
Es ist häufig notwendig, Steuerungen in einem Formular 204 im Ansprechen auf Benutzeraktionen freizugeben oder zu sperren. Dieser Abschnitt beschreibt die durch die komponentenbasierte Architektur für MTS (CBAM) zum wirkungsvollen Verwalten dieses Prozesses angewendeten Muster.
Formularbetriebsart
Es ist hilfreich, zwischen einer Formularbetriebsart und einem Formularzustand zu unterscheiden. Eine Formularbetriebsart gibt den Grund dafür, dass das Formular 204 aufgerufen worden ist, an. Häufig werden Formulare 204 für mehr als einen Zweck verwendet. Ein übliches Beispiel ist die Verwendung des gleichen Formulars zum Betrachten, zum Hinzufügen und zum Bearbeiten eines speziellen Typs von Objekt wie beispielsweise einer Aufgabe oder einem Anspruch. In diesem Fall würden die Betriebsarten des Formulars Betrachten, Hinzufügen und Aktualisieren einschließen.
Die Betriebsarten eines Formulars 204 werden auch dazu verwendet, auf der Zugriffsstufe des derzeitigen Benutzers basierenden Sicherheitsbeschränkungen zu entsprechen. Zum Beispiel ist die Aufgabenbibliothek ein Fenster, das einen Zugriff auf Aufgabenvorlagen basierend auf der Rolle des derzeitigen Benutzers begrenzt. Sie kann eine Bibliothekarsbetriebsart und eine Nichtbibliothekarsbetriebsart haben, um die Tatsache widerzuspiegeln, dass es einem Nichtbibliothekarsbenutzer nicht erlaubt werden kann, Aufgabenvorlagen zu bearbeiten. Auf diese Weise helfen Betriebsarten dabei, der Anforderung Geltung zu verschaffen, dass gewisse Steuerungen in dem Formular 204 gesperrt bleiben, sofern der Benutzer nicht eine gewisse Zugriffsstufe hat.
Es ist nicht immer für ein Formular 204 notwendig, eine Betriebsart zu haben; ein Formular könnte so einfach sein, dass es nur eine Betriebsart – die Vorgabebetriebsart – haben würde. Selbst wenn es nicht unmittelbar notwendig ist, kann es in diesem Fall vorteilhaft sein, das Formular "betriebsartbewusst" ("mode-aware") auszubilden, so dass es leicht erweitert werden kann, sollte der Bedarf entstehen.
Formularzustand
Ein Formular 204 wird eine Anzahl von verschiedenen Zuständen für jede Betriebsart haben, wobei ein Zustand eine eindeutige Kombination von freigegebenen/gesperrten, sichtbaren/unsichtbaren Steuerungen ist. Wenn ein Formular 204 sich zu einem anderen Zustand bewegt, wird zumindest eine Steuerung freigegeben oder gesperrt oder auf irgendeine Weise modifiziert.
Ein Hauptunterschied zwischen der Formularbetriebsart und dem Formularzustand besteht darin, dass die Betriebsart bestimmt wird, wenn die Steuerungseinheit 206 initialisiert wird, und konstant bleibt, bis die Steuerungseinheit 206 endet. Der Zustand wird bestimmt, wenn das Fenster sich initialisiert, aber wird im Ansprechen auf Benutzeraktionen ständig neu ausgewertet.
Handhaben von UI-Ereignissen
Wenn der Wert einer Steuerung in dem Formular 204 sich ändert, ist es notwendig, den Zustand der Steuerungen in dem Formular (ob sie freigegeben/gesperrt oder sichtbar/unsichtbar sind oder nicht usw.) neu auszuwerten. Falls ein Ändern des Werts einer Steuerung bewirken könnte, dass der Zustand einer zweiten Steuerung sich ändert, wird eine Ereignishandhabungseinheit für das passende Ereignis der ersten Steuerung geschrieben.
Die folgende Tabelle listet gemeinsame Steuerungen und die Ereignisse, die ausgelöst werden, wenn ihr Wert sich ändert, auf.
Die Ereignishandhabungseinheit ruft das DetermineFormState-Verfahren auf der Steuerungseinheit 206 auf.
Einstellen des Zustands von Steuerungen
Es ist wesentlich für eine Wartbarkeit, dass der Prozess des Einstellens des Zustands von Steuerungen von dem Prozess zum Einstellen der Werte der Steuerungen getrennt ist. Das DetermineFormState-Verfahren auf der Steuerungseinheit 206 erzwingt diese Trennung zwischen einem Einstellen des Zustands von Steuerungen und einem Einstellen ihrer Werte.
DetermineFormState ist das einzige Verfahren, das den Zustand jeder der Steuerungen in dem Formular 204 modifiziert. Da Steuerungszustandsanforderungen so komplex sind und so weit variieren, ist dies die einzige durch den Architekturrahmen ausgebildete Beschränkung.
Nötigenfalls werden Parameter zu der DetermineFormState-Funktion geleitet, um als "Hinweise" oder "Anhaltspunkte" zum Bestimmen des neuen Zustands des Formulars 204 zu fungieren. Für komplexe Formulare ist es hilfreich, die DetermineFormState-Funktion in eine Anzahl von Helferfunktion, die jeweils eine Gruppe von zugehörigen Steuerungen in dem Formular handhaben oder das Formular 204 zu einem anderen Zustand bewegen, zu zerlegen.
Beispiel
Das Bearbeitungs-/Hinzufügungs-/Betrachtungsaufgabenfenster hat drei Betriebsarten: Bearbeiten, Hinzufügen und Betrachten. In der Hinzufügungsbetriebsart ist alles in dem Formular bearbeitbar. Ein paar Details werden in der Bearbeitungsbetriebsart gesperrt bleiben, da sie nur einmal eingestellt werden sollten, wenn die Aufgabe hinzugefügt wird. In sowohl der Hinzufügungsbetriebsart als auch der Bearbeitungsbetriebsart kann die Wiederholungsregel bearbeitet werden. Ein Freigeben eines Bearbeitens der Wiederholungsregel sperrt immer das manuelle Bearbeiten der Fälligkeits- und Anzeigedaten der Aufgabe. In der Betrachtungsbetriebsart sind nur die Kategorie Kombinationsfeld und privates Ankreuzfeld freigegeben.
Fensterdatenvalidierung 308
Die Fensterdatenvalidierung ist der Prozess, durch den Daten in dem Fenster hinsichtlich Fehlern, Inkonsistenzen und einer richtigen Formatierung untersucht werden. Es ist um der Konsistenz willen wichtig, diesen Prozess bei allen Fenstern der Anwendung ähnlich oder identisch zu realisieren.
Typen der Validierung
Eingabemaskierung
Die Eingabemaskierung ist die erste Verteidigungslinie. Sie umfasst eine Reihenuntersuchung (üblicherweise Zeichen für Zeichen) der Daten, wie sie eingetragen werden, um den Benutzer sogar daran zu hindern, ungültige Daten einzutragen. Die Eingabemaskierung kann programmatisch oder über ein spezielles maskiertes Textfeld ausgeführt werden, jedoch befindet sich die Logik immer in dem Formular und wird aufgerufen, wann immer ein maskiertes Feld sich ändert.
Einzelfeldbereichsüberprüfung
Die Einzelfeldbereichsüberprüfung bestimmt die Gültigkeit des Werts eines Felds in dem Formular durch ein Vergleichen desselben mit einem Satz von gültigen Werten. Die Einzelfeldbereichsüberprüfung kann über ein Kombinationsfeld, eine Drehschaltfläche oder programmatisch in dem Formular ausgeführt werden und wird aufgerufen, wann immer sich das bereichsüberprüfte Feld ändert.
Feldüberschreitende Validierung
Die feldüberschreitende Validierung vergleicht die Werte von zwei oder mehr Feldern, um zu bestimmen, ob eine Validierungsregel erfüllt oder gebrochen wird, und tritt gerade vor einem Sichern (oder einem Suchen) auf. Die feldüberschreitende Validierung kann auf der Steuerungseinheit 206 oder dem Geschäftsobjekt 207 ausgeführt werden, jedoch ist es vorzuziehen, die Logik auf dem Geschäftsobjekt 207 zu platzieren, wenn die Validierungslogik durch mehrere Steuerungseinheiten 206 gemeinsam genutzt werden kann.
Ungültige Daten werden während des Eingabeprozesses so früh wie möglich abgefangen und zurückgewiesen. Die Eingabemaskierung und die Bereichsüberprüfung stellen die erste Verteidigungslinie bereit, gefolgt von der feldüberschreitenden Validierung, wenn das Fenster sichert (oder sucht).
Einzelfeldvalidierung
Die ganze Einzelfeldvalidierung wird über eine Sorte von Eingabemaskierung erreicht. Masken, die Textfeldern beigefügt sind, werden zum Validieren des Typs oder des Formats von Daten, die eingetragen werden, verwendet. Kombinationsfelder und Drehschaltflächen können ebenfalls zum Beschränken des Benutzers auf gültige Wahlmöglichkeiten verwendet werden. Falls keines von diesen ausreichend ist, kann eine kleine Menge von Logik auf der Ereignishandhabungseinheit des Formulars platziert werden, um die Maskierungsfunktionalität wie beispielsweise ein Halten eines Werts unter einer gewissen Schwelle oder ein Heraushalten von Apostrophen aus einem Textfeld durchzuführen.
Feldüberschreitende Validierung
Wenn der Benutzer OK oder Sichern anklickt, ruft das Formular das SindFormulardatenGültig bzw. IsFormDataValid auf der Steuerungseinheit auf, um die feldüberschreitende Validierung (zum Beispiel verifizieren, dass ein Anfangsdatum kleiner als ein Enddatum ist durchzuführen. Falls das Geschäftsobjekt 207 Validierungsregeln enthält, kann die Steuerungseinheit 206 ein Verfahren auf dem Geschäftsobjekt 207 aufrufen, um sich zu vergewissern, dass die Regeln nicht verletzt werden.
Falls ungültige Daten durch die Steuerungseinheit 206 erfasst werden, wird sie den Benutzer mit einem Nachrichtenfeld und falls möglich der Angabe, welches Feld oder welche Felder fehlerhaft sind, benachrichtigen. Unter keinen Umständen wird das Fenster eine Validierung durchführen, wenn der Benutzer versucht, abzubrechen.
Beispiel
Fenstersicherungsverarbeitung 304
Die Fenster-"Sicherungsverarbeitung" umfasst ein Verfolgen von Änderungen bei Daten in einem Formular 204 und ein Ansprechen auf durch den Benutzer eingeleitete Sicherungs- und Abbruchereignisse.
Verfolgen von Änderungen bei Formulardaten
Jedes Fenster in der CBAM-Anwendung enthält ein Feld in seinem entsprechenden Steuerungsobjekt, das als der Dirty-Zustandsmerker bzw. Schmutzzustandsmerker bekannt ist. Der Schmutzzustandsmerker wird auf wahr eingestellt, wann immer ein Endbenutzer Daten in dem Fenster modifiziert. Dieses Feld wird durch die UI-Steuerungseinheit 206 abgefragt, um zu bestimmen, wenn ein Benutzer bei einem Abbruch aufgefordert werden sollte oder ob bei einer Fensterschließung eine Fernprozedur aufgerufen werden sollte.
Die Anwendungs-Shell stellt eine Standardverarbeitung für jedes eine OK- oder Sichern-Schaltfläche enthaltende Fenster bereit.
Sichern
Die Vorgabesicherungsverarbeitung ist in der UI-Steuerungseinheit 206 realisiert wie folgt:
Die UI-Steuerungseinheit wird benachrichtigt, dass die OK-Schaltfläche angeklickt worden ist. Daraufhin überprüft die Steuerungseinheit 206 ihren Schmutzzustandsmerker. Falls der Zustandsmerker dirty bzw. schmutzig ist, ruft die Steuerungseinheit 206 das FormularAbfragen-Verfahren bzw. InterrogateForm-Verfahren zum Wiedergewinnen von Daten aus dem Formular 204 auf und ruft eine Serverkomponente 222 zum Speichern des Geschäftsobjekts 207 in der Datenbank auf. Wenn der Schmutzzustandsmerker nicht eingestellt ist, dann ist keine Sicherung notwendig. Das Fenster wird daraufhin geschlossen.
Abbrechen
Wenn der Benutzer ein Fenster abbricht, untersucht die UI-Steuerungseinheit 206 unmittelbar den Schmutzzustandsmerker. Falls der Zustandsmerker auf wahr eingestellt ist, wird der Benutzer dahingehend aufgefordert, dass seine Änderungen verloren werden, falls er sich entscheidet, das Fenster zu schließen.
Sobald er aufgefordert ist, kann der Benutzer sich dazu entschließen, das Schließen des Fensters fortzusetzen und seine Änderungen zu verlieren, oder kann sich entscheiden, nicht zu schließen und das Arbeiten fortzusetzen.
Fensterausschaltverarbeitung 310
In dem Fall eines Fehlers ist es manchmal notwendig, ein Fenster auszuschalten oder die ganze Anwendung zu beenden. Es ist entscheidend, dass alle Fenster dem Ausschaltprozess folgen, um die GPFs zu vermeiden, die gewöhnlich mit einem unrichtigen Beenden verbunden sind. Es folgt, wie das Fenster/die Anwendung ausgeschaltet wird.
Ausschaltbereich
Der Bereich des Ausschaltens ist so klein wie möglich. Falls ein Fehler in einer Steuerungseinheit 206 auftritt, der den Rest der Anwendung nicht beeinflusst, wird nur das Fenster ausgeschaltet. Falls ein Fehler auftritt, der die ganze Anwendung gefährdet, ist ein Weg zum schnellen Schließen jedes offenen Fensters in der Anwendung vorhanden. Die Fensterausschaltstrategie ist dazu in der Lage, sich auf beide Typen von Ausschalten einzustellen.
Ausschalten
Um zu wissen, welche Fenster ausgeschaltet werden müssen, verfolgt die Architektur, welche Fenster offen sind. Wann immer das Anwendungsobjekt 202 eine Steuerungseinheit 206 erzeugt, ruft es seine RegCTLR-Funktion auf, um die Steuerungseinheit 206 zu einer Sammlung von offenen Steuerungseinheiten hinzuzufügen. Wann immer ein Fenster sich schließt, teilt es desgleichen dem Anwendungsobjekt 202 mit, dass es sich schließt, indem es die UnRegCTLR-Funktion des Anwendungsobjekts 202 aufruft, und das Anwendungsobjekt 202 entfernt die sich schließende Steuerungseinheit 206 aus seiner Sammlung. In dem Fall eines Fehlers führt das Anwendungsobjekt 202 Schleifen durch seine Sammlung von offenen Steuerungseinheiten aus, wobei es jeder Steuerungseinheit mitteilt, dass sie sich "stilllegen" ("quiesce") oder unmittelbar ausschalten soll.
AllgemeineFehlerHandhabungseinheit
Die AllgemeineFehlerHandhabungseinheit (GeneralErrorHandler) ist ein Verfahren in MArch.bas, das als der Eingangspunkt in dem Fehlerhandhabungsmechanismus der Architektur fungiert. Eine Komponente oder eine Steuerungseinheit wird die AllgemeineFehlerHandhabungseinheit aufrufen, wenn sie auf irgendeinen Typ von unerwartetem oder unbekanntem Fehler stößt. Die AllgemeineFehlerHandhabungseinheit wird einen Wert zurückgeben, der angibt, was die Komponente oder Steuerungseinheit tun sollte: (1) bei der Zeile, die den Fehler ausgelöst hat, fortsetzen (2) bei der Anweisung nach der Zeile, die den Fehler ausgelöst hat, fortsetzen (3) die Funktion beenden (4) stilllegen (5) die ganze Anwendung ausschalten.
Zum Verhindern von rekursiven Aufrufen hält die AllgemeineFehlerHandhabungseinheit eine Sammlung von Steuerungseinheiten, die sich in dem Prozess des Ausschaltens befinden. Falls sie durch die gleiche Steuerungseinheit 206 zweimal nacheinander aufgerufen wird, ist sie dazu in der Lage, die Schleife zu erfassen und zu umgehen. Wenn die Steuerungseinheit 206 schließlich endet, ruft sie die UnRegisterError-Funktion auf, um die AllgemeineFehlerHandhabungseinheit wissen zu lassen, dass sie sich ausgeschaltet und aus der Sammlung von Steuerungseinheiten entfernt hat.
Ausschaltprozess
Nachdem ihr durch die AllgemeineFehlerHandhabungseinheit mitgeteilt worden ist, was zu tun ist, kann die mit einem Fehler beaufschlagte Steuerungseinheit 206 versuchen, die Anweisung, die den Fehler verursacht hat, auszuführen, fortzufahren als ob nichts passiert wäre, die derzeitige Funktion zu beenden, ihre Stilllegungsfunktion aufzurufen, um sich selbst auszuschalten, oder das Ausschaltverfahren auf dem Anwendungsobjekt 202 aufzurufen, um die ganze Anwendung auszuschalten.
Zusätzliche Standardverfahren
Suchen
Steuerungseinheiten 206, die Suchfenster verwalten, haben ein öffentliches Verfahren namens Find<Noun>s wobei <Noun> der Typ des Objekts, nach dem gesucht wird, ist. Dieses Verfahren wird in der Ereignishandhabungseinheit für die Finde-Nun-Schaltfläche aufgerufen.
Sichern
Jede Steuerungseinheit 206, die ein Bearbeitungsfenster verwaltet, hat ein als Sichern bzw. Save bezeichnetes öffentliches Verfahren, das Änderungen sichert, die der Benutzer bei den Daten in dem Formular 204 ausbildet. Dieses Verfahren wird durch die Ereignishandhabungseinheiten für sowohl die Sichern-Schaltfläche als auch die OK-Schaltfläche aufgerufen (wenn/falls die OK-Schaltfläche Änderungen vor einem Schließen sichern muss).
Schließen
Ein VB-Fenster wird durch den Benutzer auf mehrere Weisen geschlossen: über das Steuerungsfeld in der oberen linken Ecke, die X-Schaltfläche in der oberen rechten Ecke oder die Schließen-Schaltfläche. Wenn das Formular sich schließt, ist das einzige Verfahren, das ohne Rücksicht auf die Weise, in der das Schließen eingeleitet wurde, immer aufgerufen wird, die QueryUnload-Ereignishandhabungseinheit des Formulars 204.
Hierdurch kann kein standardmäßiges Schließungsverfahren vorhanden sein. Jede Verarbeitung, die auftreten muss, wenn ein Fenster sich schließt, ist in dem QueryUnload-Verfahren auf der Steuerungseinheit 206 (das durch die QueryUnload-Ereignishandhabungseinheit des Formulars aufgerufen wird) auszuführen.
Die VB-Anweisung, Lade Mich Aus bzw. Unload Me, erscheint in der Ereignishandhabungseinheit der Schließen-Schaltfläche, um den Ausladeprozess manuell einzuleiten. Auf diese Weise ahmt die Schließen-Schaltfläche die Funktionalität des Steuerungsfelds und der X-Schaltfläche nach, so dass der Schließungsprozess ohne Rücksicht darauf, wie der Benutzer das Schließen ausgelöst hat, jedes Mal auf die gleiche Weise gehandhabt wird. Die Ereignishandhabungseinheit der OK-Schaltfläche führt auch die Anweisung Unload Me aus, aber ruft zuerst das Sicherungsverfahren auf der Steuerungseinheit auf, um irgendwelche anhängigen Änderungen zu sichern.
GESCHÄFTSOBJEKTE
Geschäftsobjekte 207 sind für ein Enthalten von Daten, ein Aufrechterhalten der Integrität der Daten und ein Zeigen von Funktionen, die bewirken, dass die Daten leicht zu manipulieren sind, verantwortlich. Wann immer eine Logik zu einem einzelnen BO 207 gehört, ist sie ein Kandidat dafür, in dem BO platziert zu werden. Dies stellt sicher, dass sie nicht für jede Steuerungseinheit 206, die sie benötigt, einmal codiert wird. Es folgen einige Standardbeispiele für eine Geschäftsobjektlogik.
Geschäftslogik: Verwalten von Lebenszykluszustand
Überblick
Der "Zustand" eines Geschäftsobjekts 207 ist der Satz von allen seinen Attributen. Der Lebenszykluszustand bezieht sich nur auf ein einzelnes Attribut (oder eine kleine Gruppe von Attributen), das bestimmt, wo in seinem Lebenszyklus sich das BO 207 befindet. Die Lebenszykluszustände einer Aufgabe sind zum Beispiel Offen, Abgeschlossen, Zurückgesetzt oder Fehler. Geschäftsziele umfassen üblicherweise ein Bewegen eines BO zu seinem endgültigen Zustand hin (das heißt, Abgeschlossen für eine Aufgabe, Geschlossen für eine Ergänzung usw.).
Häufig sind Beschränkungen bei einer Bewegung eines BO durch seinen Lebenszyklus vorhanden. Eine Aufgabe kann sich zum Beispiel nur zu dem Fehlerzustand bewegen, nachdem sie zuerst Abgeschlossen oder Zurückgesetzt war. BOs stellen einen Mechanismus zum Sicherstellen, dass sie keine Lebenszyklusbeschränkungen verletzen, wenn sie sich von Zustand zu Zustand bewegen, bereit.
Ansatz
Ein BO 207 hat ein Verfahren zum Bewegen zu jedem seiner verschiedenen Lebenszykluszustände. Statt einfach eine öffentliche Variable zu zeigen, die den Lebenszykluszustand der Aufgabe enthält, zeigt das BO Verfahren wie beispielsweise Task.Clear(), Task.Complete() und Task.MarkInError(), die die Aufgabe zu einem neuen Zustand bewegen. Dieser Ansatz hindert die Aufgabe daran, einen ungültigen Wert für den Lebenszykluszustand zu enthalten, und macht es offensichtlich, was die Lebenszykluszustände einer Aufgabe sind.
Beispiel
Geschäftslogik: Arbeiten auf Gruppen von
Geschäftsobjekten
Überblick
Manchmal fungiert ein BO 207 als ein Behälter für eine Gruppe von anderen BOs. Dies passiert, wenn mehrere BOs umfassende Operationen durchgeführt werden. Um zu schließen, stellt ein Anspruch zum Beispiel sicher, dass er keine offenen Ergänzungen oder Aufgaben hat. Es kann ein Verfahren auf dem Anspruchs-BO – CanClose() – vorhanden sein, das die das Schließen eines Anspruchs beschränkenden Geschäftsregeln auswertet und wahr oder falsch zurückgibt. Eine andere Situation kann ein Wiedergewinnen der offenen Aufgaben für einen Anspruch umfassen. Der Anspruch kann Schleifen durch seine Sammlung von Aufgaben ausführen, wobei er jede Aufgabe fragt, ob sie offen ist, und sie zu einer temporären Sammlung, die zu dem Aufrufer zurückgegeben wird, hinzufügt, falls dem so ist.
Beispiel
Geschäftsobjektstrukturen
Überblick
Wenn ein BO 207 hinzugefügt oder aktualisiert wird, sendet es alle seine Attribute hinunter zu einer Serverkomponente 222 zum Schreiben in die Datenbank. Statt auf jedes Attribut in der Parameterliste der Funktionen auf dem CCA 208 und der Serverkomponente 222 explizit Bezug zu nehmen, werden alle die Attribute in einer einzelnen regelmäßigen Variantenanordnung gesendet. Diese regelmäßige Anordnung ist auch als eine Struktur bekannt.
Ansatz
Jedes bearbeitbare BO 207 hat ein Verfahren namens AsStruct, das die Mitgliedsvariablen des Objekts nimmt und sie in eine regelmäßige Variantenanordnung stellt. Der CCA 208 ruft dieses Verfahren auf einem BO 207 auf, bevor er das BO 207 hinunter zu der Serverkomponente 222 sendet, damit es hinzugefügt oder aktualisiert wird. Der Grund dafür, dass dies notwendig ist, besteht darin, dass obwohl Objektbezugnahmen per Wert über das Netz geleitet werden können, die Objekte selbst dies nicht können. Nur grundlegende Datentypen wie Ganzzahl bzw. Integer und Zeichenfolge bzw. String können per Wert zu einer Serverkomponente 222 gesendet werden. Eine VB-Aufzählung wird zum Benennen der freien Stellen der Struktur verwendet, so dass die Serverkomponente 222 einen symbolischen Namen statt eines Index zum Zugreifen auf Elemente in der regelmäßigen Anordnung verwenden kann. Es ist zu beachten, dass dies im Allgemeinen nur verwendet wird, wenn Hinzufügungen oder volle Aktualisierungen bei einem Geschäftsobjekt 207 durchgeführt werden.
In ein paar Fällen ist ein Grund zum Neuinstanziieren des BO 207 auf der Serverseite vorhanden. Das FromStruct-Verfahren tut genau das Gegenteil des AsStruct-Verfahrens und initialisiert das BO 207 aus einer regelmäßigen Variantenanordnung. Die Größe der als ein Parameter zu FromStruct geleiteten Struktur wird überprüft, um die Gewissheit zu erhöhen, dass sie eine gültige Struktur ist.
Wenn ein BO 207 eine Bezugnahme auf ein anderes BO 207 enthält, speichert das AsStruct-Verfahren den primären Schlüssel des BO 207, auf das Bezug genommen wird. Zum Beispiel enthält die Aufgabenstruktur eine AusführendenId, nicht das Auführenden-BO 207, auf das durch die Aufgabe Bezug genommen wird. Wenn das FromStruct-Verfahren auf die AusführendenId in der Aufgabenstruktur stößt, instanziiert es ein neues Ausführenden-BO und setzt die ID ein, wobei es den Rest des Ausführenden-BO leer lässt.
Beispiel
Klonen von Geschäftsobjekten
Überblick
Häufig wird eine Kopie eines Geschäftsobjekts 207 ausgebildet. Ein Klonen ist eine Weise zum Realisieren dieser Art von Funktionalität, indem der Kopierprozess in dem BO 207 selbst eingekapselt wird. Steuerungseinheiten 206, die versuchsweise Änderungen bei einem Geschäftsobjekt 207 ausbilden müssen, bitten das ursprüngliche BO 207 einfach um einen Klon und bilden Änderungen bei dem Klon aus. Falls der Benutzer entscheidet, die Änderungen zu sichern, bittet die Steuerungseinheit 206 das ursprüngliche BO darum, sich anhand der bei dem Klon ausgebildeten Änderungen selbst zu aktualisieren.
Ansatz
Jedes BO 207 hat ein Klonverfahren zum Zurückgeben einer oberflächlichen Kopie von sich selbst. Eine oberflächliche Kopie ist eine Kopie, die keinen Kopien der anderen Objekte, auf die das BO 207 Bezug nimmt, sondern nur eine Kopie einer Bezugnahme auf die Objekte aufweist. Zum Klonen einer Aufgabe weist es zum Beispiel dem Klon kein brandneues Anspruchsobjekt zu; es weist dem Klon eine neue Bezugnahme auf das vorhandene Anspruchsobjekt zu. Sammlungen sind die einzige Ausnahme zu dieser Regel – sie werden immer vollständig kopiert, da sie Bezugnahmen auf andere BOs enthalten.
Jedes BO 207 hat auch ein UpdateFromClone-Verfahren, um es ihm zu ermöglichen, einen Klon zurück mit sich selbst zu "vereinigen", indem es seine Attribute derart ändert, dass sie zu den bei dem Klon ausgebildeten Änderungen passen.
Beispiel
Halb fertige Geschäftsobjekte
Überblick
BOs 207 werden gelegentlich aus Leistungsgründen nur halb voll gefüllt. Dies wird für mehrere Tabellen umfassende Abfragen, die große Datensätze zurückgeben, getan. Ein Verwenden von halb fertigen BOs 207 kann ein fehleranfälliger Prozess sein, so dass es wesentlich ist, dass das halb fertige Ausbilden von BOs sorgfältig verwaltet und aufgenommen wird.
Bei den meisten Anwendungen sind zwei Arten von Fenstern vorhanden – Suchfenster und Bearbeitungs-/Detailfenster. Suchfenster sind die einzigen Fenster, die BOs 207 halb fertig ausbilden. Im Allgemeinen ist ein halb fertiges Ausbilden nur ein Problem, wenn ein ein völlig fertig ausgebildetes BO erwartendes Detailfenster ein halb fertiges BO von einem Suchfenster empfängt.
Ansatz
Detailfenster frischen die BOs 207, die durch die Suchfenster zu ihnen geleitet werden, ohne Rücksicht darauf, ob sie bereits völlig fertig waren oder nicht, auf. Dies widmet sich den mit einem Weitergeben von halb fertigen BOs verbundenen Problemen und hilft auch dabei, sicherzustellen, dass das BO 207 aktuell ist.
Dieser Ansatz erfordert einen anderen Typ von Verfahren (neben Gewinnen, Hinzufügen, Aktualisieren und Löschen) auf dem CCA 208: ein Auffrischungsverfahren. Dieses Verfahren ist einem Gewinnungsverfahren sehr ähnlich (faktisch ruft es das gleiche Verfahren auf der Serverkomponente auf), aber ist einzigartig, da es die Daten in Objekten, die bereits erzeugt sind, auffrischt. Die Steuerungseinheit 206 des Detailfensters ruft den passenden CCA 208 auf, wobei sie das aufzufrischende BO 207 weitergibt, und kann annehmen, dass das BO 207 aktuell und völlig fertig sein wird, wenn die Steuerung von dem CCA 208 zurückkehrt.
Dies kann nicht notwendig sein, falls zwei Fenster in sehr enger Beziehung zueinander stehen. Falls das erste Fenster das einzige Fenster ist, das jemals das zweite öffnet, ist es für das zweite Fenster notwendig, das durch das erste Fenster weitergegebene BO 207 aufzufrischen, falls es weiß, dass das BO 207 vollständig genug ausgebildet ist, um verwendet zu werden.
CCAs
CCAs 208 sind für ein Transformieren von Daten aus Zeilen und Spalten in einer Datensatzgruppe für Geschäftsobjekte 207 und für ein Ausführen von Aufrufen zu Serverkomponenten 222 im Auftrag von Steuerungseinheiten 206 verantwortlich.
Wiedergewinnen von Geschäftsobjekten
Überblick
Nach einem Bitten einer Komponente um ein Wiedergewinnen von Daten führt der CCA 208 die durch die Komponente zurückgegebenen Daten in Geschäftsobjekte 207, die durch die UI-Steuerungseinheit 206 verwendet werden.
Ansatz
Der Führungsprozess stellt sich dar wie folgt:
CCAs 208 rufen GetRows bei der Datensatzgruppe auf, um eine Kopie ihrer Daten in einer regelmäßigen Variantenanordnung zu gewinnen, um die Datensatzgruppe möglichst bald freizugeben. Es ist ein Verfahren zum Koordinieren des Führens jeder durch die Komponente zurückgegebenen Datensatzgruppe vorhanden.
Bei dem Führungsprozess eines einzelnen Verfahrens wird nur eine Datensatzgruppe koordiniert. Es ist ein Verfahren zum Aufbauen eines BO aus einer einzelnen Zeile einer Datensatzgruppe vorhanden. Dieses Verfahren wird durch das Führungskoordinationsverfahren einmal für jede Zeile in der Datensatzgruppe aufgerufen.
Beispiel
Auffrischen von Geschäftsobjekten
Überblick
Die Logik zum Auffrischen von BOs 207 ist der Logik zum Erzeugen derselben zuerst sehr ähnlich. Ein Verfahren "Auffrischen" ist einem Verfahren "Gewinnen" sehr ähnlich, aber muss BOs 207, die bereits vorhanden sind, verwenden, wenn es den Führungsprozess ausführt.
Beispiel
Hinzufügen von Geschäftsobjekten
Überblick
Steuerungseinheiten 206 sind für ein Erzeugen und Besetzen von neuen BOs 207 verantwortlich. Zum Hinzufügen eines BO 207 zu der Datenbank muss die Steuerungseinheit 206 den CCA 208 aufrufen, wobei sie das hinzuzufügende Geschäftsobjekt 207 weitergibt. Der CCA 208 ruft das AsStruct-Verfahren auf dem BO 207 auf und leitet die BO-Struktur hinunter zu der zu sichernden Komponente. Er aktualisiert daraufhin das BO 207 mit der ID und dem Zeitstempel, die durch den Server erzeugt werden. Es ist zu beachten, dass das Verfahren auf dem CCA 208 nur das BO 207 aktualisiert.
Beispiel
Aktualisieren von Geschäftsobjekten
Überblick
Der Aktualisierungsprozess ist sehr ähnlich zu dem Hinzufügungsprozess. Der einzige Unterschied besteht darin, dass die Serverkomponente nur einen Zeitstempel zurückgibt, da das BO bereits eine ID hat.
Beispiel
Löschen von Geschäftsobjekten
Löschungsüberblick
Wie die Hinzufügungs- und die Aktualisierungsverfahren nehmen Löschungsverfahren ein Geschäftsobjekt 207 als einen Parameter und haben keinen Rückgabewert. Das Löschungsverfahren modifiziert das Objekt 207, das es löscht, nicht, da das Objekt bald verworfen werden wird.
Beispiel
SERVERKOMPONENTE
Serverkomponenten 222 haben zwei Zwecke: ein Durchsetzen von Geschäftsregeln und ein Ausführen von Datenzugriffsoperationen. Sie werden zum Vermeiden eines Duplizierens von Logik zwischen Funktionen entworfen.
Entwerfen für eine Wiederverwendung
Einkapselung erzwingen
Jede Serverkomponente 222 kapselt eine einzelne Datenbanktabelle oder einen Satz von in enger Beziehung zueinander stehenden Datenbanktabellen ein. Serverkomponenten 222 wählen möglichst viele Daten aus einer einzelnen Tabelle aus oder modifizieren sie. Eine Komponente wählt gelegentlich aus einer Tabelle aus, die durch eine andere Komponente "besessen" oder eingekapselt wird, um eine Verbindungsstelle zu verwenden (aus Effizienzgründen). Eine Serverkomponente 222 arbeitet häufig mit anderen Serverkomponenten zusammen, um eine Geschäftstransaktion abzuschließen.
Verteilen von Logik zwischen mehreren Klassen
Falls die Komponente sehr groß wird, wird sie in mehr als eine Klasse gespalten. Wenn dies auftritt, wird sie in zwei Klassen aufgeteilt – eine für Geschäftsregeln und eine für einen Datenzugriff. Die Geschäftsregelnklasse realisiert die Schnittstelle der Komponente und nutzt die Datenzugriffsklasse zum Modifizieren von Daten wie benötigt.
Beispiel
FEHLERHANDHABUNG
Allgemeine Informationen
Mit der Ausnahme von "Class_Initialize", "Class_Terminate" und in einer FehlerHandhabungseinheit aufgerufenen Verfahren hat jede Funktion oder jedes Unterprogramm eine durch einen Benutzer definierte Anweisung 'Bei Fehler Gehe Zu' bzw. 'On Error Go To'. Die erste Zeile in jeder Prozedur ist: Bei Fehler Gehe Zu FehlerHandhabungseinheit bzw. On Error Go To ErrorHandler. Einer Zeile nahe dem Ende der Prozedur ist ein Label "ErrorHandler" zugewiesen. (Es ist zu beachten, dass jede Prozedur eine mit einem Label "ErrorHandler" versehene Zeile haben kann, da Zeilenlabels in VB 5.0 einen Prozedurbereich haben). Dem Label ErrorHandler geht eine Anweisung Exit Sub oder Exit Function voraus, um ein Ausführen des Fehlerhandhabungscodes, wenn kein Fehler vorhanden ist, zu vermeiden.
Fehler werden basierend auf der Ebene des Moduls in der Anwendung verschieden gehandhabt (das heißt, Benutzerschnittstellenmodule sind für ein Anzeigen von Fehlernachrichten für den Benutzer verantwortlich).
Alle Module nutzen eine technische Architektur aus, um Nachrichten zu protokollieren. Clientmodule, die bereits eine Bezugnahme auf die Architektur haben, rufen das Log-Manager-Objekt direkt auf. Da Servermodule üblicherweise keine Bezugnahme auf die Architektur haben, verwenden sie die globale LogMessage()-Funktion, der in jeder Serverkomponente entsprochen wird.
Irgendwelche Fehler, die in einer Serverkomponente 222 vorgebracht werden, werden durch das Aufrufen der UI-Steuerungseinheit 206 gehandhabt. Dies stellt sicher, dass der Benutzer passende von dem Fehler benachrichtigt wird und dass Geschäftsfehler nicht in nicht gehandhabte fatale Fehler umgesetzt werden.
Alle unerwarteten Fehler werden durch eine allgemeine Fehlerhandhabungsfunktion bei dem globalen Architekturmodul gehandhabt, um die Anwendung immer taktvoll auszuschalten.
Serverkomponentenfehler
Die FehlerHandhabungseinheit für jedes Dienstmodul enthält eine Fall-Anweisung zum Überprüfen auf alle vorausgesehenen Fehler hin. Falls der Fehler kein behebbarer Fehler ist, besteht die Logik zu seiner Handhabung darin, zuerst MTS durch ein Aufrufen von GetObjectContext.SetAbort() über den Fehler zu berichten. Als Nächstes wird die globale LogMessage()-Funktion aufgerufen, um die für Unterstützungspersonal der Stufe eins bestimmte kurze Beschreibung zu protokollieren. Daraufhin wird die LogMessage()-Funktion ein zweites Mal aufgerufen, um die detaillierte Beschreibung des Fehlers für Unterstützungspersonal einer höheren Stufe zu protokollieren. Schließlich wird der Fehler neu vorgebracht, so dass die aufrufende Funktion die fehlgeschlagene Operation kennen wird.
Eine vorgegebene Fall-Bedingung wird codiert, um irgendwelche unerwarteten Fehler zu handhaben. Dies protokolliert den durch VB erzeugten Fehler und bringt ihn daraufhin vor. Eine Codeprobe ist nachstehend bereitgestellt:
Es folgt ein Beispiel dafür, wie eine Fehlerhandhabung in der Aufgabenkomponente realisiert wird, wenn ein Versuch gemacht wird, eine Aufgabe einem Ausführenden, der nicht vorhanden ist, neu zuzuweisen. SQL zum Neuzuweisen einer Aufgabe zu einem nicht vorhandenen Ausführenden auszuführen erzeugt einen Fehler der Verletzung der referentiellen Integrität, der in dieser Fehlerhandhabungseinheit eingefangen wird:
CCAs, CCIs, Geschäftsobjekte und Formulare
Alle CCIs, CCAs, Geschäftsobjekte und Formulare bringen jeden Fehler, der erzeugt wird, vor. Ein Codemuster ist nachstehend bereitgestellt:
Benutzerschnittstellensteuerungseinheitsfehler
Die Benutzerschnittstellensteuerungseinheiten 206 handhaben irgendwelche erzeugten und von den unteren Ebenen der Anwendung hinauf geleiteten Fehler. UI-Module sind dafür verantwortlich, welche Fehler auch immer durch Serverkomponenten 222 vorgebracht werden könnten durch ein Anzeigen eines Nachrichtenfelds für den Benutzer zu handhaben.
Jeder in den UIs erzeugte Fehler wird auch in einem Dialogfeld für den Benutzer angezeigt. Jeder auf dem Client eingeleitete Fehler wird unter Verwendung der LogMessage()-Prozedur protokolliert. Auf dem Server eingeleitete Fehler werden bereits protokolliert worden sein und müssen daher nicht wieder protokolliert werden.
Alle unerwarteten Fehler werden durch ein allgemeines Fehlerverfahren bei dem globalen Architekturmodul eingefangen. Abhängig von dem von dieser Funktion zurückgegebenen Wert kann die Steuerungseinheit bei der Anweisung, die den Fehler ausgelöst hat, fortsetzen, bei der nächsten Anweisung fortsetzen, ihre Stilllegungsfunktion aufrufen, um sich selbst auszuschalten, oder ein Ausschaltverfahren auf dem Anwendungsobjekt aufrufen, um die ganze Anwendung auszuschalten.
Es werden keine Fehler von dieser Ebene der Anwendung vorgebracht, da Steuerungseinheiten alle Fehler handhaben. Eine Codeprobe einer Steuerungseinheitsfehlerhandhabungseinheit ist nachstehend bereitgestellt:
LOKALISIERUNG
Die CBAM-Anwendung ist derart aufgebaut, dass sie mit einer minimalen Anstrengung oder Wandlung für verschiedene Sprachen und Länder an lokale Gegebenheiten angepasst bzw. lokalisiert werden kann.
Anforderungen und Bereich
Die CBAM-Architektur stellt eine Unterstützung für gewisse Lokalisierungsmerkmale bereit:
Lokalisierbare Betriebsmittelablage;
Flexibler Benutzerschnittstellenentwurf;
Datumsformatlokalisierung; und
Beanspruchung von Fensterbetriebssystemlokalisierungsmerkmalen.
Lokalisierungsansatzkontrollliste
Lokalisierbare Buchstabenablage
Die CBAM-Anwendung hat eine Infrastruktur zum Unterstützen von mehreren Sprachen. Die Architektur fungiert über ihren Codetabellenansatz als eine zentralisierte Buchstabenablage.
Die Codetabellen haben eine Lokalisierung im Sinn. Jede Zeile in der Codetabelle enthält eine zugeordnete Sprachidentifizierung. Über die Sprachidentifizierung kann ein beliebiger gegebener Code Werte von einer beliebigen Sprache unterstützen.
Flexible Schnittstelle 400
Eine flexible Benutzerschnittstelle 400 und ein flexibler Code machen eine Anpassung leicht. Die 4 veranschaulicht, wie verschiedene Sprachen neu gestrichen und neu kompiliert werden. Es werden zum Beispiel sowohl eine englische UI 404 als auch eine französische UI 406 leicht untergebracht. Dies bringt eine minimale Anstrengung mit sich, da beide UIs die gleiche Kerncodebasis 402 gemeinsam nutzen. Aktualisierungen bei den UIs sind lediglich eine oberflächliche Änderung.
Generische Graphiken werden verwendet und eine Überfüllung wird vermieden, um eine Benutzerschnittstelle, die leicht zu lokalisieren ist, zu erzeugen.
Datenlokalisierung
Sprachlokalisierungseinstellungen beeinflussen die Weise, auf die Daten auf UIs (Benutzerschnittstellen) angezeigt werden. Das Vorgabesystemanzeigeformat ist für verschiedene Sprachen/Länder verschieden. Zum Beispiel:
Englisch (Vereinigte Staaten von Amerika) zeigt "mm/dd/yy" (zum Beispiel "05/16/98") an.
Englisch (Vereinigtes Königreich) zeigt "dd/mm/yy" (zum Beispiel "16/05/98") an.
Die UI der vorliegenden Erfindung wendet eine Anzahl von Datumssteuerungen Dritter einschließlich Sheridan Calendar Widgets (von Sheridan Software) an, die es Entwicklern ermöglichen, vordefinierte Eingabemasken für Daten einzustellen (über die Eigenschaftsseiten der Steuerungen; die Eigenschaft ist in diesem Fall "Maske").
Obwohl die Maskeneigenschaft beeinflusst werden kann, wird die Vorgabeeinstellung vorzugsweise akzeptiert (die Vorgabeeinstellung für Maske ist "0 – Systemvorgabe"; sie wird zur Entwurfszeit eingestellt). Ein Akzeptieren der Vorgabesystemeinstellungen beseitigt den Bedarf an einem Codieren für mehrere Schauplätze (mit einigen möglichen Ausnahmen), stört keine intrinsischen Funktionen von Visual Basic wie beispielsweise DateAdd und ermöglicht es, Daten als Zeichenfolgen zur Verwendung in SQL zu formatieren.
Das nachstehend veranschaulichte Testprogramm zeigt, wie ein das englische (Vereinigtes Königreich) Vorgabesystemdatenformat verwendendes Datum zu einem benutzerdefinierten Format (in diesem Fall eine Zeichenfolgenkonstante zur Verwendung mit DB2-SQL-Anweisungungen) neu formatiert wird:
Wirksames Einsetzen von Fensterbetriebssystem
Die CBAM-Architektur zeigt Schnittstellenverfahren auf dem RegistryService-Objekt zum Zugreifen auf schauplatzspezifische Werte, die von dem Steuerungsfeld eingestellt werden.
Die Architektur zeigt eine API von dem RegistryService-Objekt, die einen Zugriff auf alle die in dem Steuerungsfeld verfügbaren Informationen ermöglicht. Nachstehend ist die Signatur der API gezeigt:
GetRegionalInfo(Info As RegionalInfo) As String
Wobei RegionalInfo jeder der Werte in der nachstehenden Tabelle sein kann:
Beispiel für Gewinnen von RegionalInfo:
Logische Arbeitseinheit
Das Muster der logischen Arbeitseinheit (LUW) ermöglicht eine Trennung des Anliegens zwischen UI-Steuerungseinheiten 206 und Geschäftslogik.
Überblick
Wenn ein Benutzer ein Fenster öffnet, Änderungen ausbildet und OK oder Sichern anklickt, wird normalerweise eine Serverkomponente 222 aufgerufen, um eine Transaktion, die die Änderungen des Benutzers in der Datenbank sichern wird, auszuführen. Hierdurch kann es gesagt werden, dass das Fenster die Grenze der Transaktion definiert, da die Transaktion übertragen wird, wenn das Fenster sich schließt.
Das LUW-Muster ist verwendbar, wenn Datenbanktransaktionen sich über Fenster erstrecken. Ein Benutzer beginnt zum Beispiel, Daten in einem Fenster zu bearbeiten, und öffnet daraufhin ohne ein Sichern ein anderes Fenster und beginnt ein Bearbeiten von Daten in dem Fenster, wobei der Sicherungsprozess mehrere Fenster umfasst. Keine Fenstersteuerungseinheit 206 kann den Sicherungsprozess verwalten, da Daten von beiden Fenstern als ein Teil einer unteilbaren Arbeitseinheit gesichert werden müssen. Stattdessen wird ein LUW-Objekt eingeführt, um den Sicherungsprozess zu verwalten.
Die LUW fungiert als eine Art von "Einkaufstasche". Wenn eine Steuerungseinheit 206 ein Geschäftsobjekt 207 modifiziert, legt sie es in die Tasche, die später zu bezahlen (sichern) ist. Sie kann die Tasche einer anderen Steuerungseinheit 206 geben, um das Einkaufen zu beenden (mehr Objekte zu modifizieren), und daraufhin einer dritten Steuerungseinheit geben, die bezahlt (die LUW um ein Einleiten des Sicherns bittet).
Ansatz
Steuerungseinheiten 206 können verschiedene Stufen des LUW-"Bewusstseins" haben:
Erfordert Neue: erzeugt immer eine neue LUW;
Erfordert: erfordert eine LUW und erzeugt nur eine neue LUW, falls eine nicht durch die aufrufende Steuerungseinheit weitergegeben wird;
Erfordert Vorhandene: erfordert eine LUW, aber erzeugt keine neue LUW, falls eine nicht durch die aufrufende Steuerungseinheit weitergegeben wird. Bringt einen Fehler vor, falls keine LUW weitergegeben wird; und
Nicht Unterstützt: ist nicht dazu in der Lage, eine LUW zu verwenden.
Steuerungseinheiten 206, die immer eine neue LUW erfordern, erzeugen die LUW während der Initialisierung in ihrer ArchInitClass-Funktion. Sie können wählen, ob andere Fenster in ihre LUW einzubeziehen sind oder nicht. Falls es für ein anderes Fenster wünschenswert ist, in eine vorhandene LUW einbezogen zu werden, gibt die Steuerungseinheit 206, die die LUW besitzt, eine Bezugnahme auf die LUW weiter, wenn sie das Anwendungsobjekt 202 aufruft, um das zweite Fenster zu öffnen. Steuerungseinheiten 206, die eine LUW erfordern oder eine vorhandene LUW erfordern akzeptieren die LUW als einen Parameter in der ArchInitClass-Funktion.
LUWs enthalten alle die notwendige Logik zum Persistentmachen ihrer "Inhalte" – der modifizierten BOs 207. Sie handhaben ein Aufrufen von Verfahren auf dem CCA 208 und ein Aktualisieren der BOs 207 mit neuen IDs und/oder Zeitstempeln.
ARCHITEKTUR-API-HIERARCHIE
Es folgt ein Überblick des Architekturobjektmodels einschließlich einer Beschreibung jedes Verfahrens und der Parameter, die es akzeptiert. Zusätzliche Abschnitte befassen sich detaillierter mit den Konzepten hinter spezifischen Bereichen (Speichern von Code im Cache, Nachrichtenprotokollierung und Datenzugriff).
Architekturobjekt
Die 5 stellt die derzeitigen Eigenschaften bei dem Architekturobjekt 200 dar.
Das Folgende sind sich auf dem Architekturobjekt 200 befindende APIs, die entweder eine wiedergewonnene oder eine erzeugte Instanz eines Objekts zurückgeben, was die folgenden Schnittstellen realisiert:
CodesMan() 500;
TextMan() 502;
IdMan() 504;
RegMan() 506;
LogMan() 508;
ErrMan() 510;
UserMan() 512; und
SecurityMan() 514.
AsMsgStruct()
Dieses Verfahren auf dem Architekturobjekt gibt eine Variantenstruktur zurück, um eine Fernnachricht weiterzureichen.
Syntax:

Public Function AsMsgStruct() As Variant
End Function

Beispiel:

Dim vMsg As Variant
vMsg = objArch.AsMsgStruct

CodesMan
Das Folgende sind sich auf der Schnittstelle des Architekturobjekts 200 namens CodesMan 500 befindende APIs:
CheckCacheFreshness();
FillControl(ctlControl, ncategory, nFillType, [nCodeStatus], [colAssignedCodes]);
FilterCodes(colAllCodes, nCodeStatus);
GetCategoryCodes(nCategory);
GetCodeObject(nCategory, sCode);
GetResourceString(lStringId);
GetServerDate();
RefreshCache();
RemoveValidDates(sCode, colPassedInAssignedCodes); und
SetServerDate(dtServerDate).
CheckCacheFreshness()
Überprüft, ob der Cache abgelaufen ist, und falls dem so ist, wird aufgefrischt.
Syntax:

Private Sub CheckCacheFreshness()
End Sub

Beispiel:

CheckCacheFreshness

FillControl()
Diese API wird zum Füllen von Listenfeldern oder Kombinationsfeldern mit Werten aus einer Liste von CodierungDecodierungen bzw. CodeDecodes verwendet. Gibt eine Sammlung für nachfolgende Nachschlagevorgänge zu Codeobjekten, die zum Füllen von Steuerungen verwendet werden, zurück.
Syntax:

Public Function FillControl(ctlControl As Object, nCategory As CodeDecodeCats, nFillType As CodeDecodeLengths, Optional nCodeStatus As CodeDecodeFilters = cmValidCodes, Optional colAssignedCodes As CCollection) As CCollection
End Function

Parameter:

ctlControl: eine Bezugnahme auf ein eingeleitetes Listenfeld oder Kombinationsfeld.
nCategory: die ganzzahlbasierte Konstante, die diese CodeDecodes von anderen klassifiziert hat. Einzelne der gültigen Konstanten schließen ein: cmCatTaskType = 1 cmCatSource cmCatTaskStatus
nFillType: das Attribut des CodeDecode, das du füllen möchtest. Einzelne der gültigen Werte schließen ein: cmCode cmShortDecode cmLongDecode
nCodeStatus: optionaler Wert, der die CodeDecodes gemäß ihren effektiven Daten und Ablaufdaten filtert. Einige der gültigen Konstanten schließen ein: cmAllCodes Anhängige + Gültige + Abgelaufene Codes cmPendingCodes Codes, deren effektives Datum größer als das derzeitige Datum ist cmValidCodes Nicht Anhängige oder Abgelaufene Codes
colAssignedCodes: verwendet, wenn eine Steuerung gefüllt wird, die zugewiesene Werte füllen und einschließen sollte.

Beispiel:

' Eine Instanzvariable für Zustandssammlung auf Objekt vereinbaren
Private colStates As CCollection
' FillControll-API aufrufen und lokale Sammlung inst var auf Sammlung von Codes, die zum Füllen der Steuerung bzw. controll verwendet wurden, einstellen. Diese Sammlung wird für nachfolgende Nachschlagevorgänge verwendet.
Set colStates =
objArch.CodesMan.FillControl(frmCurrentForm.choStates,
cmCatStates, cmLongDecode)

FilterCodes()
Gibt eine Sammlung von Code/Decodes zurück, die unter Verwendung ihrer effektiven Daten und Ablaufdaten basierend darauf, welcher nCodeStatus von dem fillcontrol-Verfahren weitergegeben wird, gefiltert werden.
Syntax:

Private Function FilterCodes(colAllCodes As CCollection, nCodeStatus As CodeDecodeFilters) As CCollection
End Function

Parameter:

colAllCodes:
nCodeStatus:

Beispiel:

Set colFilteredCodes = FilterCodes(colCodes, nCodeStatus

GetCategoryCodes()
Gibt eine Sammlung von Ccode-Objekten, denen eine gültige Kategorie zugewiesen ist, zurück.
Syntax:

Public Function GetCategoryCodes(nCategory As CodeDecodeCats) As CCollection
End Function

Parameter:

nCategory: die ganzzahlbasierte Konstante, die diese CodeDecodes von anderen klassifiziert hat.

Beispiel:
GetCodeObject()
Gibt ein gültiges CCode-Objekt, dem eine spezifische Kategorie und ein spezifischer Code zugewiesen sind, zurück.
Syntax:

Public Function GetCodeObject(nCategory As CodeDecodeCats, sCode As String) As CCode
End Function

Parameter:

nCategory: die ganzzahlbasierte Konstante, die diese CodeDecodes von anderen klassifiziert hat.
sCode: eine Zeichenfolge, die das Codeattribut des CodeDecode-Objekts angibt.

Beispiel:

frmCurrentForm.lblState = objArch.CodesMan.GetCodeObject(cmCatStates, "IL").LongDecode

GetResourceString()
Gibt eine Zeichenfolge aus der Betriebsmitteldatei, der eine spezifische Zeichenfolgen-ID zugewiesen ist, zurück.
Syntax:

Private Function GetResourceString(lStringId As Long) As String
End Function

Parameter:

lStringId: die mit der Zeichenfolge in der Betriebsmitteldatei verbundene id.

Beispiel:

sMsg = arch.CodesMan.GetResourceString (CLng(vMessage))

GetServerDate()
Gibt das Datum von dem Server zurück.
Syntax:

Private Function GetServerDate() As Date
End Function

Beispiel:

SetServerDate CCA.GetServerDate

RefreshCache()
Frischt alle die Codeobjekte in dem Cache auf.
Syntax:

Private Sub RefreshCache()
End Sub

Beispiel:

m_Cache.RefreshCache

RemoveValidCodes()
Entfernt alle gültigen Codes aus der eingeleiteten Sammlung von zugewiesenen Codes, was verwendet wird, um zu sehen, welche Codes zugewiesen und nicht gültig sind.
Syntax:

Private Sub RemoveValidCodes(sCode As String, colPassedInAssignedCodes As CCollection)
End Sub

Parameter:

sCode: Name von Code
colPassedInAssignedCodes: bereits verwendete Codes.

Beispiel:

RemoveValidCodes codCode.Code, colPassedInAssignedCodes

SetServerDate()
Stellt das Serverdatum ein.
Syntax:

Private Sub SetServerDate(dtServerDate As Date)
End Sub

Parameter:

dtServerDate: Datum von Server.

Beispiel:

SetServerDate CCA.GetServerDate

TextMan
Das Folgende sind sich auf der Schnittstelle des Architekturobjekts 200 namens TextMan 502 befindende APIs.
PairUpAposts();
PairUpAmps(); und
MergeParms().
PairUpAposts()
Ordnet Apostrophe in der weitergegebenen Zeichenfolge paarweise an.
Syntax:

Public Function PairUpAposts(sOriginalString As String) As String
End Function

Parameter:

sOriginalString: durch den Aufrufer eingeleitete Zeichenfolge

Beispiel:

Dim sString As String
sString = objArch.TextMan.PairUpAposts("This is Monika's string")
' Erwartete Rückgabe: sString = "This is Monika''s string"

PairUpAmps()
Ordnet Et-Zeichen in der weitergegebenen Zeichenfolge paarweise an.
Syntax:

Public Function PairUpAmps(sOriginalString As String) As String
End Function

Parameter:

sOriginalString: durch den Aufrufer eingeleitete Zeichenfolge

Beispiel:

Dim sString As String
sString = objArch.TextMan.PairUpAmps("Forms&Corr")
' Erwartete Rückgabe: sString = "Forms&&Corr"

MergeParms()
Vereinigt Zeichenfolge mit der Sammlung von weitergegebenen Parametern.
Syntax:

Public Function MergeParms(sString As String, colParms As CCollection) As String
End Function

Parameter:

sOriginalString: durch den Aufrufer eingeleitete Zeichenfolge
colParms As Ccollection: Sammlung der durch den Aufrufer eingeleiteten Parameter

Beispiel:

Dim sString As String
sString = obArch.TextMan.MergeParms(sString, colParms)

IdMan
Das Folgende sind sich auf der Schnittstelle des Architekturobjekts 200 namens IdMan 504 befindende APIs:
GetGUID();
GetSequenceID();
GetTimeStamp();
GetTrackingNbr(); und
GetUniqueId().
GetGUID()
Syntax:

Public Function GetGUID()
End Function

Beispiel:

Dim vNewGuid As Variant
vNewGuid = objArch.IdMan.GetGUID

GetSequenceId()
Syntax:

Public Function GetSequenceId(sTemplateType As CounterName) As String
End Function

Parameter:

sTemplateType: die die eine Sequenz-id erfordernde Vorlage bestimmende Zeichenfolge (das heißt cmCountFC = Forms & Corr)

Beispiel:

frmCurrentForm.txtTemplateNumber = objArch.IdMan.GetSequenceId(cmCountFC)

GetTimeStamp()
Syntax:

Public Function GetTimeStamp()
End Function

Beispiel:

Dim nNewTimeStamp As Long
nNewTimeStamp = objArch.IdMan.GetTimeStamp

GetTrackingNbr()
Syntax:

Public Function GetTrackingNbr()
End Function

Beispiel:

Set objTechArch = New CTechArch
sUniqueTrackNum = obj TechArch.IdMan.GetTrackingNbr

GetUniqueId()
Syntax:

Public Function GetUniqueId()
End Function

Beispiel:

Dim vUid As Variant
vNewUid = objArch.IdMan.GetUniqueId

RegMan
Das Folgende sind sich auf der Schnittstelle des Architekturobjekts 200 namens RegMan 506 befindende APIs:
GetCacheLife();
GetClientDSN();
GetComputerName();
GetDefaultAndValidate();
GetFCArchiveDirectory();
GetFCDistributionDirectory();
GetFCMasterDirectory();
GetFCUserDirectory();
GetFCWorkingDirectory();
GetHelpPath();
GetLocalInfo();
GetLogLevel();
GetRegionalInfo();
GetRegValue();
GetServerDSN();
GetSetting();
GetTimerLogLevel();
GetTimerLogPath(); und
GetUseLocalCodes().
GetCacheLife()
Syntax:

Public Function GetCacheLife() As String
End Function

Beispiel:

Dim s As String
s = objArch.RegMan.GetCacheLife

GetClientDSN()
Syntax:

Public Function GetClientDSN() As String
End Function

Beispiel:

Dim s As String
s = objArch.RegMan.GetClientDSN

GetComputerName()
Syntax:

Public Function GetComputerName() As String
End Function

Beispiel:

Dim s As String
s = objArch.RegMan.GetComputerName

GetDefaultAndValidate()
Syntax:

Private Function GetDefaultAndValidate(sKey As String) As String
End Function

Parameter:

sKey: der Schlüssel in der Registrierdatenbank, von der der Benutzer anfordert (das heißt: Hilfe-Pfad bzw. Help Path)

Beispiel:

Dim sDefault As String
sDefault = objArch.RegMan.GetDefaultAndValidate(sKey)

GetFCArchiveDirectory()
Syntax:

Public Function GetFCArchiveDirectory() As String
End Function

Beispiel:

Dim s As String
s = objArch.RegMan.GetFCArchiveDirectory

GetFCDistributionDirectory()
Syntax:

Public Function GetFCDistributionDirectory() As String
End Function

Beispiel:

Dim s As String
s = objArch.RegMan.GetFCDistributionDirectory

GetFCMasterDirectory()
Syntax:

Public Function GetFCMasterDirectory() As String
End Function

Beispiel:

Dim s As String
s = objArch.RegMan.GetFCMasterDirectory

GetFCUserDirectory()
Syntax:

Public Function GetFCUserDirectory() As String
End Function

Beispiel:

Dim s As String
s = objArch.RegMan.GetFCUserDirectory

GetFCWorkingDirectory()
Syntax:

Public Function GetFCWorkingDirectory() As String
End Function

Beispiel:

Dim s As String
s = objArch.RegMan.GetFCWorkingDirectory

GetHelpPath()
Syntax:

Public Function GetHelpPath() As String
End Function

Beispiel:

Dim s As String
s = objArch.RegMan.GetHelpPath

GetLocalInfo()
Syntax:

Public Function GetLocalInfo() As String
End Function

Beispiel:

Dim s As String
s = objArch.RegMan.GetLocalInfo

GetLogLevel()
Syntax:

Public Function GetLogLevel() As String
End Function

Beispiel:

Dim s As String
s = objArch.RegMan.GetLogLevel

GetRegionalInfo()
Ermöglicht einen Zugriff auf alle schauplatzspezifischen Werte, die von dem Steuerungsfeld eingestellt werden.
Syntax:

Public Function GetRegionalInfo(Info As RegionalInfo) As String
End Function

Parameter:

Info: die regionalen Informationen enthaltende Zeichenfolge. Einige der gültigen Konstanten schließen ein: • cmLanguageId = &H1 ' Sprach-id • cmLanguageLocalized = &H2 ' Lokalisierter Name der Sprache • cmLanguageEnglish = &H1001 ' Englischer Name der Sprache • cmLanguageAbbr = &H3 ' Abgekürzter Sprachname • cmLanguageNative = &H4 ' Natürlicher Name der Sprache

Beispiel:

Dim s As String
s = objArch.RegMan.GetRegionalInfo

GetRegValue()
Syntax:

Public Function GetRegValue() As String
End Function

Beispiel:

Dim s As String
s = objArch.RegMan.GetRegValue

GetServerDSN()
Syntax:

Public Function GetServerDSN() As String
End Function

Beispiel:

s As String
s = objArch.RegMan.GetServerDSN

GetSetting()
Einstellung aus der Registrierdatenbank gewinnen.
Syntax:

Public Function GetSetting(sKey As String) As String
End Function

Parameter:

sKey: der Schlüssel in der Registrierdatenbank, von der der Benutzer anfordert (das heißt: Help Path)

Parameter:

GetHelpPath = GetSetting(cmRegHelpPathKey)

GetTimerLogLevel()
Syntax:

Public Function GetTimerLogLevel() As String
End Function

Beispiel:

Dim s As String
s = objArch.RegMan.GetTimerLogLevel

GetTimerLogPath()
Syntax:

Public Function GetTimerLogPath() As String
End Function

Beispiel:

Dim s As String
s = objArch.RegMan.GetTimerLogPath

GetUseLocalCodes()
Syntax:

Public Function GetUseLocalCodes() As String
End Function

Beispiel:

Dim s As String
s = objArch.RegMan.GetUseLocalCodes

LPSTRToVBString()
Extrahiert eine VB-Zeichenfolge aus einem Puffer, der eine mit Null beendete Zeichenfolge enthält.
Syntax:

Private Function LPSTRToVBString$(ByVal s$)
End Function

LogMan
Das Folgende sind sich auf der Schnittstelle des Architekturobjekts 200 namens LogMan 508 befindende APIs:
LogMessage();
WriteToDatabase(); und
WriteToLocalLog().
LogMessage()
Wird zum Protokollieren der Nachricht verwendet. Diese Funktion wird basierend auf ihrem Ernst und der Protokollstufe von vMsg bestimmen, wo die Nachricht protokolliert werden sollte, wenn überhaupt.
Syntax:
Parameter:

vMsg: die Standardarchitekturnachricht
lSeverity: der Ernst der Nachricht
sClassName: der Name der die Nachricht protokollierenden Klasse
sMethodName: der Name des die Nachricht protokollierenden Verfahrens
sVersion: die Version der Binärdatei (EXE oder DLL), die das die Nachricht protokollierende Verfahren enthält
lErrorNum: die Nummer des derzeitigen Fehlers
sText: ein optionaler Parameter, der den Text der Nachricht enthält. Falls er weggelassen wird, wird der Text in einer Zeichenfolgendatei nachgeschlagen, oder die generische VB-Fehlerbeschreibung wird verwendet.

Beispiel:
WriteToDatabase()
Wird zum Protokollieren der Nachricht in der Datenbank auf dem Server unter Verwendung des CLoggingComp verwendet. Diese Funktion gibt die TrackingId, die durch das CLoggingObject erzeugt wird, zurück.
Syntax:

Private Sub WriteToDatabase (vMsg As Variant, msgToLog As CMessage)
End Sub

Parameter:

vMsg: die Standardarchitekturnachricht
msgToLog: ein Parameter, der den Text der Nachricht enthält.

Beispiel:

If msgToLog.IsLoggableAtLevel(m_lLocalLogLevel) Then WriteToDatabase vMsg, msgToLog
End If

WriteToLocalLog()
Wird zum Protokollieren der Nachricht in entweder einer Einfachdatei in dem Fall von Windows 95 oder dem NT-Ereignisprotokoll in dem Fall von Windows NT verwendet.
Syntax:

Private Sub WriteToLocalLog(msgToLog As CMessage)
End Sub

Parameter:

msgToLog: ein Parameter, der den Text der Nachricht enthält.

Beispiel:
ErrorHandler:

WriteToLocalLog msgToLog
End Sub

ErrMan
Das Folgende sind sich auf der Schnittstelle des Architekturobjekts 200 namens ErrMan 510 befindende APIs:
HandleError();
RaiseOriginal();
ResetError(); und
Update().
HandleError()
Dieses Verfahren wird zu der allgemeinen Fehlerhandhabungseinheit in MArch.bas durchgeleitet.
Syntax:

Public Function HandleError (vMsg As Variant, nCompType As CompType, sClassName As String, sMethodname As String) As ErrResumeCodes
End Sub

Parameter:

vMsg: allgemeine Architekturinformationen
nCompType: enthält Ranginformationen (Client oder Server)
sClassName: Klasse, die den Fehler vorgebracht hat.
sMethodName: Verfahren, das den Fehler vorgebracht hat.

RaiseOriginal()
Dieses Verfahren wird zum Rücksetzen des Fehlerobjekts und Vorbringen verwendet.
Syntax:

Public Sub RaiseOriginal()
End Sub

Beispiel:

objArch.ErrMan.Raiseoriginal

ResetError()
Dieses Verfahren wird zum Rücksetzen von Attributen verwendet.
Syntax:

Public Sub ResetError()
End Sub

Beispiel:

objArch.ErrMan.ResetError

Update()
Dieses Verfahren wird zum Aktualisieren von Attributen auf die Werte des globalen Fehlerobjekts von VB verwendet.
Syntax:

Public Sub Update()
End Sub

Beispiel:

objArch.ErrMan.Update

UserMan
Das Folgende sind sich auf der Schnittstelle des Architekturobjekts 200 namens UserMan 512 befindende APIs.
UserId;
EmployeeId;
EmployeeName;
EmployeeFirstName;
EmployeeLastName;
EmployeeMiddleInitial;
GetAuthorizedEmployees;
IsSuperOf();
IsRelativeOf(); und
IsInRole().
UserId()
Syntax:

Public Property Get UserId() As String
End Property

Beispiel:

Dim sNewUserId As String
sNewUserId = objArch.Useman.UserId

EmployeeId()
Syntax:

Public Property Get EmployeeId() As String
End Property

Beispiel:

Dim sNewEmployeeId As String
sNewEmployeeId = objArch.Userman.EmployeeId

EmployeeName()
Syntax:

Public Property Get EmployeeName() As String
End Property

Beispiel:

Dim sName As String
sName = objArch.UserMan.EmployeeName

EmployeeFirstName()
Syntax:

Public Property Get EmployeeFirstName() As String
End Property

Beispiel:

Dim sFName As String
sFName = objArch.UserMan.EmployeeFirstName

EmployeeLastName()
Syntax:

Public Property Get EmployeeLastName() As String
End Property

Beispiel:

Dim sLName As String
sLName = objArch.UserMan.EmployeeLastName

EmployeeMiddleInitial()
Syntax:

Public Property Get EmployeeMiddleInitial() As String
End Property

Beispiel:

Dim sMI As String
sMI = objArch.UserMan.EmployeeMiddleInitial

GetAuthorizedEmployees()
Erzeugt eine Sammlung der überwachten Personen des Benutzers aus dem Verzeichnis und gibt GetAuthorizedEmployees zurück – Sammlung von autorisierten Angestellten.
Syntax:

Public Function GetAuthorizedEmployees() As CCollection
End Function

Beispiel:

Dim colAuth As Collection
colAuth = objArch.UserMan.GetAuthorizedEmployees

IsSuperOf()
Überprüft, ob der derzeitige Benutzer ein Vorgesetzter des eingeleiteten Benutzers ist.
Syntax:

Public Function IsSuperOf(sEmpId As String) As Boolean
End Function

Parameter:

sEmpId: Zeichenfolge, die eine Angestellten-ID-Nummer enthält

Beispiel:

Dim bIsSuperOfMonika As Boolean
bIsSuperOfMonika = objArch.UserMan.IsSuperOf("TS012345")

IsRelativeOf()
Überprüft, ob der eingeleitete Benutzer ein Verwandter des derzeitigen Benutzers ist.
Syntax:

Public Function IsRelativeOf(sEmpId As String) As Boolean
End Function

Parameter:

sEmpId: Zeichenfolge, die eine Angestellten-ID-Nummer enthält

Beispiel:

Dim bIsRelativeOfMonika As Boolean
bIsRelativeOfMonika = objArch.UserMan.IsRelativeOf("TS012345")

IsInRole()
Überprüft, um zu sehen, ob der derzeitige Benutzer sich in einer gewissen Rolle befindet.
Syntax:

Public Function IsInRole(sRole As String) As Boolean
End Function

Parameter:

sRole: Zeichenfolge, die eine Rolle enthält

Beispiel:

Dim bIsInRoleTaskLibrarian As Boolean
bIsInRoleTaskLibrarian = objArch.UserMan.IsInRole("TA")

SecurityMan
Die Folgenden APIs befinden sich auf der Schnittstelle des Architekturobjekts 200 namens SecurityMan 514.
EvalClaimRules;
EvalFileNoteRules;
EvalFormsCorrRules;
EvalOrgRules;
EvalRunApplicationRules;
EvalRunEventProcRules;
EvalTaskTemplateRules;
EvalUserProfilesRules;
IsOperAuthorized;
GetUserId; und
OverrideUser.
EvalClaimRules()
Diese API nimmt auf Geschäftsregeln zur Anspruchssicherheitsüberprüfung Bezug und gibt einen booleschen Wert zurück, falls Regeln erfüllt sind.
Syntax:

Private Function EvalClaimRules(lBasicOp As cmBasicOperations, vContextData As Variant) As Boolean
End Function

Parameter:

lBasicOp: eine grundlegende Operation, die der derzeitige Benutzer durchführen möchte (das heißt Löschen)
vContextData: eine regelmäßige Variantenanordnung, die relevante Geschäftsobjekte oder andere Informationen hält.

Beispiel:
EvalFileNoteRules()
Diese API nimmt auf Geschäftsregeln zur Dateinotizsicherheitsüberprüfung Bezug und gibt einen booleschen Wert zurück, falls Regeln erfüllt sind.
Syntax:

Private Function EvalFileNoteRules(lBasicOp As cmBasicOperations, vContextData As Variant) As Boolean
End Function

Parameter:

Beispiel:
EvalFormsCorrRules()
Diese API nimmt auf Geschäftsregeln für eine Sicherheitsüberprüfung von Formularen und Korrespondenz Bezug und gibt einen booleschen Wert zurück, falls Regeln erfüllt sind.
Syntax:

Private Function EvalFormsCorrRules(lBasicOp As cmBasicOperations) As Boolean
End Function

Parameter:

lBasicOp: eine grundlegende Operation, die der derzeitige Benutzer durchführen möchte (das heißt Löschen)

Beispiel:
EvalOrgRules()
Diese API nimmt auf Geschäftsregeln zur Ereignisverarbeitungseinheitssicherheitsüberprüfung Bezug und gibt einen booleschen Wert zurück, falls Regeln erfüllt sind.
Syntax:

Private Function EvalOrgRules(lBasicOp As cmBasicOperations) As Boolean
End Function

Parameter:

Beispiel:
EvalRunApplicationRules()
Diese API nimmt auf Geschäftsregeln zum Ausführen der Anwendung Bezug und gibt einen booleschen Wert zurück, falls Regeln erfüllt sind.
Syntax:

Private Function EvalRunApplicationRules(lBasicOp As cmBasicOperations) As Boolean
End Function

Parameter:

Beispiel:
Diese API nimmt auf Geschäftsregeln zur Ereignisverarbeitungseinheitssicherheitsüberprüfung Bezug und gibt einen booleschen Wert zurück, falls Regeln erfüllt sind.
Syntax:

Private Function EvalRunEventProcRules(lBasicOp As cmBasicOperations) As Boolean
End Function

Parameter:

Beispiel:
EvalTaskTemplateRules()
Diese API nimmt auf Geschäftsregeln zur Aufgabenvorlagensicherheitsüberprüfung Bezug und gibt einen booleschen Wert zurück, falls Regeln erfüllt sind.
Syntax:

Private Function EvalTaskTemplateRules(lBasicOp As cmBasicOperations) As Boolean
End Function

Parameter:

Beispiel:
Diese API nimmt auf Geschäftsregeln zur Aufgabenvorlagensicherheitsüberprüfung Bezug und gibt einen booleschen Wert zurück, falls Regeln erfüllt sind.
Syntax:

Private Function EvalUserProfileRules(lBasicOp As cmBasicOperations, vContextData As Variant) As Boolean
End Function

Parameter:

Beispiel:
GetUserId()
Gibt den Anmeldenamen/die Benutzer-id des derzeitigen Benutzers zurück.
Syntax:

Public Function GetUserId() As String
End Function

Beispiel:

Dim sUserId as String
sUserId = GetUserId

IsOperAuthorized()
Diese API nimmt auf Geschäftsregeln Bezug und gibt einen booleschen Wert, der bestimmt, ob der Benutzer Sicherheitsprivilegien zum Durchführen einer gewissen Operation hat, zurück.
Syntax:

Public Function IsOperAuthorized(vMsg, as variant, nOperation as cmOperations, vContext As Variant) As Boolean
End Function

Parameter:

vMsg: die Standardarchitekturnachricht
nOperation: eine Aufzählung, die einen Namen der zu überprüfenden Operation enthält.
vcontext: eine regelmäßige Variantenanordnung, die relevante Geschäftsobjekte oder andere Informationen hält.

Beispiel:

Dim bCanIDoThis As Boolean
bCanIDoThis = objArch.SecurityMan.IsOperAuthorized(vMsg, aOperationName, vContext)
TlbEditIcon.Enabled = bCanIDoThis

Override User()

Initialisiert für einen anderen Benutzer neu.

Syntax:

Public Sub OverrideUser(Optional sUserId As String, Optional dictRoles As CDictionary, Optional dictSubs As CDictionary)
End Function

Parameter:

sUserId:
dictRoles:
dictSubs:

Beispiel:
CODERAHMEN
Allgemeine Anforderungen
Es werden getrennte Tabellen (CodesDecodes) zum Speichern der statischen Werte erzeugt.
Nur die Bezugnahmen auf Codes/Decodes werden in Geschäftstabellen (zum Beispiel Aufgabe), die diese Werte nutzen, gespeichert. Dies minimiert die Größe der Geschäftstabellen, da ein Speichern eines Code-Werts viel weniger Speicherplatz als sein entsprechender Decode-Wert braucht (zum Beispiel wird für den Staat "AL" statt der Zeichenfolge "Alabama" in jeder Tabellenzeile gespeichert).
CodeDecodes werden lokal auf der Clientworkstation in einer lokalen DBMS gespeichert. Bei der Anwendungsstartprozedur wird eine Prozedur zum Sicherstellen, dass die lokalen Tabellen synchron mit der zentralen DBMS sind, durchgeführt.
Infrastrukturansatz
Der Ansatz der Code-Decode-Infrastruktur 600 der vorliegenden Erfindung gibt einen Überblick über das Verfahren des physischen Modellierens von Codetabellen. Das Modell ermöglicht es, Codes ohne Auswirkungen auf das physische Datenmodell und/oder die Anwendung und Architektur zu erweitern. Die 6 zeigt das physische Layout von CodeDecode-Tabellen gemäß einem Ausführungsbeispiel der vorliegenden Erfindung.
Infrastruktur
Das physische Modell der CodeDecode-Infrastruktur 600 tut das Folgende:
Es unterstützt eine relationale Funktionalität zwischen CodeDecode-Objekten;
Es unterstützt eine Erweiterbarkeit ohne eine Modifikation bei der DBMS oder der Anwendungsarchitektur;
Es stellt einen konsistenten Ansatz zum Zugreifen auf alle CodeDecode-Elemente bereit; und
Es ist leicht wartbar.
Diese generischen Tabellen sind dazu in der Lage, neue Kategorien und eine Modifikation von Beziehungen ohne einen Bedarf an einem Ändern der DBMS oder CodeDecode-Anwendungsarchitektur zu handhaben.
Die Vorteile dieses Modells sind die Erweiterbarkeit und die Wartbarkeit. Dieses Modell ermöglicht die Modifikationen von Codekategorien ohne irgendwelche Auswirkungen auf die DBMS oder den Anwendungsarchitekturcode. Dieses Modell erfordert es auch, dass weniger Tabellen gewartet werden. Darüber hinaus ist nur ein Verfahren zum Zugreifen auf CodeDecodes notwendig.
Tabellenbeziehungen und Feldbeschreibungen:

(pk) gibt einen primären Schlüssel an.

Code_Kategorie bzw. Code_Category 602

• C_Category (pk): die Kategorienummer für eine Gruppe von Codes
• C_Cache (derzeit nicht genutzt): kann angeben, ob die Kategorie in Speicher auf der Clientmaschine im Cache gespeichert werden sollte
• T_Category: eine Textbeschreibung der Kategorie (zum Beispiel Anwendungsaufgabentypen, Anspruchsstatus, Tage der Woche)
• D_Last_Update: das Datum, an dem irgendwelche Daten in der gegebenen Kategorie zuletzt aktualisiert wurden; dieses Feld wird zum Bestimmen, ob eine Kategorie oder Kategorien auf der lokalen Datenbasis zu aktualisieren ist oder sind, verwendet

Beziehnungen

• Eine Einer-zu-vielen- bzw. one-to-many-Beziehung mit dem Tabellen-Code (das heißt, eine Kategorie kann mehrere Codes haben)

Code 604

• C_Category (pk): die Kategorienummer für eine Gruppe von Codes
• C_Code (pk): eine kurze Codeidentifizierung (bis zu zehn Zeichen; die derzeitige maximale Länge, die verwendet wird, beträgt fünf Zeichen)
• D_Effective: ein Datumsfeld, das das effektive Datum des Codes angibt
• D_Expiration: ein Datumsfeld, das das Ablaufdatum des Codes angibt (die Vorgabe ist 1. Januar 2999)

Beziehungen

• Eine Viele-zu-einem- bzw. many-to-one-Beziehung mit Code_Category 602 (vorstehend beschrieben)
• Eine one-to-many-Beziehung mit Code_Relations 606 (eine gegebene Kategorie-und-Code-Kombination kann zu mehreren anderen Kategorie-und-Code-Kombinationen in Beziehung gebracht werden)

Code_Beziehungen bzw. Code_Relations 606

• C_Category1 (pk): die erste Kategorie
• C_Code1 (pk): der erste Code
• C_Category2 (pk): die zugehörige Kategorie
• C_Code2 (pk): der zugehörige Code

Beziehungen

• Eine many-to-one-Beziehung mit der Code-Tabelle (jede Kategorie und jeder Code in der Code-Tabelle kann mehrere zugehörige Kategorie-Code-Kombinationen haben)

Code_Decode 608

• C_Category (pk): die Kategorienummer für eine Gruppe von Codes
• C_Code (pk): dine kurze Codeidentifizierung (bis zu zehn Zeichen; die derzeitige maximale Länge, die verwendet wird, beträgt fünf Zeichen)
• N_Lang_ID (pk): ein Wert, der die lokale Spracheinstellung angibt (wie in den Regionaleinstellungen einer gegebenen Maschine definiert). Der Wert für Englisch (Vereinigte Staaten) wird zum Beispiel als 0409 gespeichert. Ein Verwenden dieser Einstellung ermöglicht die Speicherung und Auswahl von Textcodebeschreibungen basierend auf der gewählten Sprache
• T_Short_Desc: eine abgekürzte Textbeschreibung von C_Code
• T_Long_Desc: eine Textbeschreibung von C_Code mit voller Länge – welche der Benutzer tatsächlich sehen wird (zum Beispiel Schließe Ergänzung – Wiederherstellung, Dateinotiz, Arbeitskraftkompensation)

Lokalisierungsunterstützungsansatz
Lokalisierung freigeben
Codes haben eine Unterstützung für mehrere Sprachen. Der Schlüssel zu diesem Merkmal ist ein Speichern einer Sprachidentifizierung zusammen mit jedem CodeDecode-Wert. Dieses Sprachfeld bildet einen Teil des zusammengesetzten Schlüssels der Code_Decode-Tabelle. Jeder Code-API-Nachschlagevorgang schließt einen Aufruf auf Systemebene zum Wiedergewinnen der Sprachsystemvariablen ein. Dieser Wert wird als Teil des Aufrufs zum Wiedergewinnen der Werte, denen die richtige Sprache zugewiesen ist, verwendet.
Warten von Sprachlokalisierungseinstellung
Eine Verknüpfung mit der Sprachsystemumgebungsvariablen zu den Sprachschlüsseln ist bei jedem CodeDecode gespeichert. Dieser Wert wird zu jeder Zeit durch den Benutzer einfach modifiziert, indem er die in dem Steuerungsfeldordner von Microsoft Windows verfügbare Regionaleinstellungsbenutzerschnittstelle bearbeitet.
Codeablaufansatz
Ein Handhaben von zeitempfindlichen Codes wird ein Problem, wenn Steuerungen mit einer Liste von Werten gefüllt werden. Ein Ziel besteht darin, es nur dem Benutzer zu ermöglichen, passende Einträge zu betrachten und auszuwählen. Die Herausforderung liegt darin, dazu in der Lage zu sein, Codes ablaufen zu lassen, ohne die Anwendung nachteilig zu beeinflussen. Um dies zu erreichen, wird berücksichtigt, wie jede UI, der ihre derzeitige Betriebsart gegeben ist, entscheiden wird, welche Werte dafür passend sind, sie dem Benutzer zu zeigen.
Die drei häufigsten UI-Betriebsarten, die zeitempfindliche Codes beeinflussen, sind die Hinzufügungsbetriebsart, die Betrachtungsbetriebsart und die Bearbeitungsbetriebsart.
Hinzufügungsbetriebsart
In der Hinzufügungsbetriebsart werden typischerweise nur gültige Codes als Auswahloptionen für den Benutzer angezeigt. Es ist zu beachten, dass die Konstante, cmValidCodes, die Vorgabe ist und selbst dann, wenn dieser optionale Parameter weggelassen wird, immer noch in derselben Weise arbeiten wird.
Set colStates = objArch.CodesMan.FillControl(frmCurrentForm.cboStates, cmCatStates, cmLongDecode, cmValidCodes)
Betrachtungsbetriebsart
In der Betrachtungsbetriebsart betrachtet der Benutzer typischerweise ohne eine direkte Fähigkeit zum Bearbeiten Ergebnisse von Verlaufsdaten. Ein Bearbeiten von ausgewählten Verlaufsdaten startet eine andere UI. Angesichts dessen werden die Steuerungen mit gültigen und abgelaufenen Codes oder mit anderen Worten nicht anhängigen Codes gefüllt.
Set colStates = objArch.CodesMan.FillControl(frmCurrentForm.cboStates, cmCatStates, cmLongDecode, cmNonPendingCodes)
Bearbeitungsbetriebsart
In der Bearbeitungsbetriebsart sind Änderungen bei gültigen Codes erlaubt, aber es werden auch abgelaufene Codes angezeigt, falls sie bereits der Einheit zugewiesen sind.
Dim colAssignedCodes As New cCollection
colAssignedCodes.Add HistoricalAddress.State
Set colStates = objArch.CodesMan.FillControl(frmCurrentForm.cboStates, cmCatStates, cmLongDecode, cmValidCodes, colAssignedCodes)
Aktualisieren von lokalen CodeDecodes
Die lokalen CodeDecode-Tabellen werden mit einem zentralen Speicher von CodeDecodes synchron gehalten. Die Architektur ist dafür verantwortlich, auf einer regelmäßigen Grundlage eine Überprüfung auszuführen, um zu sehen, ob irgendwelche neuen oder aktualisierten Code-Decodes von dem Server vorhanden sind. Die Architektur gibt auch bei einer Erfassung von neuen oder modifizierten CodeDecode-Kategorien die zugehörigen Daten zurück und führt eine Aktualisierung bei der lokalen Datenbank durch. Die 7 zeigt ein Logikdiagramm für diesen Prozess 700.
Nach einem API-Aufruf wird eine Überprüfung ausgeführt, um zu bestimmen, ob die Architektur initialisiert ist 702. Falls sie es ist, wird eine Überprüfung ausgeführt, um zu bestimmen, ob das Frischeintervall abgelaufen ist 704. Falls das Frischeintervall nicht abgelaufen ist, ist der API-Aufruf abgeschlossen 706. Wenn jedoch entweder die Architektur nicht initialisiert ist oder das Frischeintervall abgelaufen ist, dann werden die Felder "LetzteAktualisierung" bzw. "LastUpdate" für jede Kategorie aus dem CodeDecode gelesen und zu dem Server geleitet 708. Daraufhin werden neue und aktualisierte Kategorien aus der Datenbank gelesen 710. Schließlich wird die lokale Datenbank aktualisiert 712.
Codezugriffs-APIs
Das Folgende sind sich auf der Schnittstelle des Architekturobjekts 200 namens CodesMan 500 befindende APIs.
GetCodeObject(nCategory, sCode);
GetCategoryCodes(nCategory);
FillControl(ctlControl, nCategory, nFillType, [nCodeStatus], [colAssignedCodes]).
GetCodeObject: Gibt für eine spezifische Kategorie und einen spezifischen Code ein gültiges CCode-Objekt zurück.
Syntax:

GetCodeObject(nCategory, sCode)

Parameter:

nCategory: die ganzzahlbasierte Konstante, die diese CodeDecodes von anderen klassifiziert hat.
sCode: eine Zeichenfolge, die das Code-Attribut des CodeDecode-Objekts angibt.

Beispiel:

frmCurrentForm.lblState = objArch.CodesMan.GetCodeObject (cmCatStates, "IL").LongDecode

GetCategoryCodes: Gibt für eine gegebene gültige Kategorie eine Sammlung von CCode-Objekten zurück.
Syntax:

GetCategoryCodes(nCategory)

Parameter:

Beispiel:

Dim colMyStates As CCollection
Set colMyStates = objArch.CodesMan.GetCategory(cmCatStates)

FillControl: Diese API wird zum Füllen von Listenfeldern oder Kombinationsfeldern mit Werten aus einer Liste von CodeDecodes verwendet. Gibt eine Sammlung für nachfolgende Nachschlagevorgänge zu Code-Objekten, die zum Füllen von Steuerungen verwendet werden, zurück.
Syntax:

FillControl(ctlControl, nCategory, nFillType, [nCodeStatus], [colAssignedCodes])

Parameter:

ctlControl: eine Bezugnahme auf ein eingeleitetes Listenfeld oder Kombinationsfeld.
nCategory: die ganzzahlbasierte Konstante, die diese CodeDecodes von anderen klassifiziert hat.
nFillType: das Attribut des CodeDecodes, das du füllen möchtest. Gültige Werte schließen ein: cmCode cmShortDecode cmLongDecode
nCodeStatus: optionaler Wert, der die Code-Decodes gemäß ihren effektiven Daten und Ablaufdaten filtert. Gültige Konstanten schließen die folgenden ein: cmAllCodes Anhängige + Gültige + Abgelaufene Codes cmPendingCodes Codes, deren effektives Datum größer als das derzeitige Datum ist cmValidCodes Nicht Anhängige oder Abgelaufene Codes cmExpiredCodes Codes, deren abgelaufenes Datum größer als das derzeitige Datum ist cmNonPendingCodes Gültige + Abgelaufene Codes cmNonValidCodes Anhängige + Abgelaufene Codes cmNonExpiredCodes Anhängige + Gültige Codes
colAssignedCodes: verwendet, wenn eine Steuerung gefüllt wird, die sich füllen und zugewiesene Werte einschließen sollte.

Beispiel:
Relationale Codezugriffs-APIs
Über die APIs "GetCodeObject" oder "GetCategoryCodes" zurückgegebene Codeobjekte können Beziehungen zu anderen Codeobjekten haben. Dies ermöglicht eine Funktionalität, bei der Codes anderen einzelnen Codeobjekten zugeordnet werden.
Die zum Wiedergewinnen dieser Werte verwendeten APIs ähneln denen auf der CodesMan-Schnittstelle. Der Unterschied besteht jedoch darin, dass die Verfahren auf dem Codes-Objekt statt der CodesManager-Schnittstelle aufgerufen werden: nachstehend sind wieder die APIs aufgelistet.
GetCodeObject(nCategory, sCode);
GetCategoryCodes(nCategory);
FillControl(ctlControl, nCategory, nFillType, [nCodesStatus], [colAssignedCodes]).
Nachstehend ist etwas Probecode zum Veranschaulichen, wie diese APIs auch aus Code-Objekten aufgerufen werden, angegeben.
Beispiel für GetCodeObject:

Dim objBondCode As CCode
Set objBondCode = objArch.CodesMan.GetCodeObject(cmCatLOB, "B")
Dim objSuretyCode As CCode
Set objSuretyCode = objBondCode.GetCodeObject(cmCatSupplement, "B01")

Beispiel für GetCategory:

Dim objBondCode As CCode
Set objBondCode = objArch.CodesMan.GetCodeObject(cmCatLOB, "B")
Dim colSupplements As CCollection
Set colSupplements = objBondCode.GetCategory(cmCatSupplement)

Beispiel für FillControl:

Dim objBondCode As CCode
Set objBondCode = objArch.CodesMan.GetCodeObject(cmCatLOB, "B")
Dim colSupplements As CCollection
Set colSupplements = objBondCode.FillControl(frmForm.cboSupplements, cmCatSupplements, cmLongDecode)

NACHRICHTENPROTOKOLLIERUNG
Die Nachrichtenprotokollierungsarchitektur ermöglicht eine Nachrichtenprotokollierung in einer sicheren und konsistenten Art und Weise. Die Schnittstelle zu der Nachrichtenprotokollierungskomponente ist einfach und konsistent, was eine Nachrichtenprotokollierung auf einer beliebigen Verarbeitungsebene ermöglicht. Sowohl Fehlernachrichten als auch Informationsnachrichten werden in einer zentralisierten Ablage protokolliert.
Ein Abstrahieren des Nachrichtenprotokollierungsansatzes ermöglicht es der Realisierung, sich zu ändern, ohne gegen vorhandenen Code zu verstoßen.
Beste Praktiken
Nachrichten werden immer durch die Architektur protokolliert, wenn ein nicht behebbarer Fehler auftritt (das heißt das Netz zu Boden geht) und er nicht explizit gehandhabt wird. Eine Nachrichtenprotokollierung kann auf einer Grundlage wie benötigt verwendet werden, um die Diagnose und das Instandsetzen von SIRs zu erleichtern. Diese Sorte der Protokollierung ist an Punkten der Integration zwischen Klassen und Komponenten besonders gut verwendbar. Zum Zwecke des Austestens protokollierte Nachrichten haben einen Ernst der Informationen, um nicht mit legitimen Fehlernachrichten verwechselt zu werden.
Verwendung
Eine Nachricht wird protokolliert, indem die LogMessage()-Funktion auf der Architektur aufgerufen wird.
Beschreibung von Parametern:

vMsg: die Standardarchitekturnachricht
lSeverity: der Ernst der Nachricht
sClassName: der Name der Klasse, die die Nachricht protokolliert
sMethodName: der Name des Verfahrens, das die Nachricht protokolliert
sVersion: die Version der Binärdatei (EXE oder DLL), die das die Nachricht protokollierende Verfahren enthält
lErrorNum: die Nummer des derzeitigen Fehlers
sText: ein optionaler Parameter, der den Text der Nachricht enthält. Falls er weggelassen wird, wird der Text in einer Zeichenfolgendatei nachgeschlagen, oder die generische VB-Fehlerbeschreibung wird verwendet.
sText: ein optionaler Parameter, der den Text der Nachricht enthält. Falls er weggelassen wird, wird der Text in einer Zeichenfolgendatei nachgeschlagen, oder die generische VB-Fehlerbeschreibung wird verwendet.
lLoggingOptions: Ein optionaler Parameter, der eine Konstante enthält, die bestimmt, wo die Nachricht zu protokollieren ist (das heißt ein Weitergeben von cmLogToDBAndEventViewer an LogMessage wird den Fehler in der Datenbank und der Ereignisbetrachtungseinheit protokollieren.)

Protokollierungsstufen
Bevor eine Nachricht protokolliert wird, wird ihr Ernst mit der Protokollstufe der derzeitigen Maschine verglichen. Wenn der Ernst der Nachricht kleiner als die oder gleich der Protokollstufe ist, dann wird die Nachricht protokolliert.
Gültige Werte für die Protokollstufe sind als eine Aufzählung in VB definiert. Sie schließen ein:
Beispiel
Datenbankprotokoll
Die Datenbankprotokolltabelle besteht aus den folgenden Feldern:
Lokales Protokoll
Nachrichten werden immer in dem Ereignisprotokoll des Anwendungsservers protokolliert; dies trifft jedoch nicht notwendigerweise für die Datenbank wie durch den an LogMessage weitergegebenen optionalen Parameter, lLoggingOptions, mitgeteilt zu. Ein Administrator mit den passenden Zugriffsrechten kann sich mit dem MTS-Anwendungsserver fernverbinden und sein Ereignisprotokoll betrachten. Nur ein MTS-Paket enthält die Ereignisprotokollkomponente, so dass Fehler alle in das gleiche Anwendungsserverereignisprotokoll geschrieben werden.
Über Visual Basic protokollierte Ereignisse haben immer "VBRuntime" als die Quelle. Das Computerfeld wird automatisch mit dem Namen des Computers, der das Ereignis protokolliert (das heißt dem MTS-Anwendungsserver), statt dem Computer, der das Ereignis erzeugt hat (typischerweise ein Clientcomputer), besetzt.
Die gleichen Ereignisdetails, die in die Datenbank geschrieben werden, werden in eine lesbare Zeichenfolge formatiert und in das Protokoll geschrieben. Der Text "die durch ... identifizierte VB-Anwendung hat protokolliert:" wird automatisch durch VB hinzugefügt; der Text, der folgt, enthält die Details der Nachricht.
DATENZUGRIFF
Alle außer ein paar Ausnahmefällen verwenden die API "FühreAbfrageAus" bzw. "ExecuteQuery". Die API deckt Einzeldatenbankoperationen, bei denen eine einzelne Eingabe und eine einzelne Ausgabe vorhanden sind, ab. Im Wesentlichen sollten nur gewisse Operationen des Stapeltyps ausgeschlossen sein.
Der Datenzugriffsrahmen dient den Zwecken der Leistung, der Konsistenz und der Wartbarkeit.
Leistung
Das Verfahren "ExecuteQuery" umfasst Verwendungsmuster zum Verwenden von ADO in einer effizienten Art und Weise. Beispiele für diese Muster schließen eine Nutzung von getrennten Datensatzgruppen und ein explizites Vereinbaren von optionalen Parametern, die zu der besten Leistung führen, ein.
Konsistenz
Dieses Verfahren stellt eine gemeinsame Schnittstelle für eine Entwicklung des Datenzugriffs bereit. Wenn eine einfache und stabile Datenzugriffsschnittstelle gegeben ist, können beste Praktiken entwickelt und verbreitet werden.
Wartbarkeit
Da das Verfahren sich an einem einzelnen Ort befindet, ist es sehr modularisiert und kann mit wenig Auswirkungen auf seine Aufrufer gewartet werden.
Anwendungsserver verwenden oft die Datenzugriffsschnittstelle ActiveX-Datenobjekte (ADO bzw. ActiveX Data Objects). Dies ermöglicht ein vereinfachtes Programmiermodell sowie es den Ausführungsbeispielen zu ermöglichen, eine Vielzahl von Datenquellen zu nutzen.
Das Verfahren "ExecuteQuery"
Überblick
Das Verfahren "ExecuteQuery" sollte für die meisten Anwendungs-SQL-Aufrufe verwendet werden. Dieses Verfahren kapselt eine Funktionalität zum Verwenden von ADO in einer wirkungsvollen und effizienten Art und Weise ein. Diese API findet bei Situationen, in denen eine einzelne Operation, die ein einzelnes Datensatzgruppenobjekt zurückgibt, ausgeführt werden muss, Anwendung.
Syntax

Set obj = ExecuteQuery(vMsg, nTranType, sSQL, [nMaxRows], [adoTransConn], [args])

Parameter
vMsg
Dieser Parameter ist die TechArt-Struktur. Diese wird als ein Token zur Informationserfassung wie beispielsweise Leistungsmetrik, Fehlerinformationen und Sicherheit verwendet.
nTranType
Eine anwendungsdefinierte Konstante, die angibt, welcher Typ von Operation durchgeführt wird. Werte für diesen Parameter können welche von den folgenden Konstanten sein:
cmSelect
cmSelectLocal
cmUpdate
cmInsert
cmDelete
sSQL
Zeichenfolge, die den gegen die DBMS durchzuführenden SQL-Code enthält.
nMaxRows (optional)
Ganzzahliger Wert, der die maximale Anzahl von Datensätzen, die die Datensatzgruppe der derzeitigen Abfrage zurückgeben wird, darstellt.
adoTransConn (optional)
Ein ADO-Verbindungs-Objekt. Dieses wird für Operationen, die eine ADO-Transaktionssteuerung erfordern (siehe Abschnitt "Verwenden von Transaktionen"), erzeugt und in das Ausführen der Abfrage eingeleitet.
args (optional)
Eine Liste von Parametern, die respektvoll in die SQL-Anweisung einzufügen sind.
Realisierung
Bei einem Ausführungsbeispiel der vorliegenden Erfindung befindet sich das Verfahren "ExecuteQuery" in der Datei MservArch.bas. Diese Datei sollte in alle Projekte des Serverkomponententyps integriert werden. Dies wird es jeder Serverkomponente ermöglichen, auf dieses Verfahren zuzugreifen.

Anmerkung: da dieses Verfahren in einem "bas"-Modul ist, ist es von überall in dem Projekt global verfügbar.

Auswählen von Datensätzen
ExecuteQuery nutzt getrennte Datensatzgruppen für Anweisungen des Typs "Auswählen" bzw. "Select". Dies erfordert, dass die Clients, insbesondere die CCAs, eine Bezugnahme auf ADOR, eine ActiveX-Datenobjekt-Datensatzgruppe (ActiveX Data Object Recordset), enthalten. Diese DLL ist eine Untermenge der ADODB-DLL. ADOR enthält nur das Datensatzgruppenobjekt.
Ein Verwenden von getrennten Datensatzgruppen ermöglicht ein Führen von Datensatzgruppenobjekten von dem Server zu dem Client. Dies funktioniert sehr viel effizienter als die regelmäßige Variantenanordnung, die mit einem Verwenden der API "GetRows" auf dem Server verbunden ist. Diese Leistungssteigerung ist besonders augenscheinlich, wenn der Anwendungsserver mit einer großen Anzahl von gleichzeitigen Benutzern belastet ist.
Probe von Clientkomponentenadapter (CCA)
Probe von Serverkomponente
Codeausschnitt von ExecuteQuery (Auswahlabschnitt)
Einfügen von Datensätzen
Ein Einfügen von Datensätzen erfordert gewisse eine optimistische Sperrung betreffende Informationen. Auf dem Server wird ein eindeutiger Wert angefordert, um das letztmalige Modifizieren anzugeben. Dieser eindeutige Wert wird derart zurück zu dem Anforderer zurückgegeben, dass er für spätere Datenbankoperationen verwendet werden kann.
Probe von Clientkomponentenadapter (CCA)

Dim vNewTS as Variant
vNewTS = objServer.PerformInsert(vMsg, nId, sName)
' Zeitstempel des Objekts auf vNewTS einstellen

Probe von Serverkomponente

Private Const cmCustInsertSQL = "Insert Customer(nId, Name, LastUpdated) Values(?, '?', ?)"
Public Function PerformInsert(vMsg, nId, sName) As Variant
Dim lCurrTS as Long
lCurrTS = GetTimeStamp
Dim colArgs as CCollection
Set colArgs = New Ccollection
colArgs.Add nId
colArgs.Add sName
colArgs.Add lCurrTS
ExecuteQuery(vMsg, cmInsert, sCustInsertSQL, , , colArgs)
PerformInsert = lCurrTS

Codeausschnitt von ExecuteQuery (Einfügungsabschnitt)

Case cmInsert
Set adoRS = adoConn.Execute(sSQL, nRecordsAffected, adCmdText)
If nRecordsAffected <= 0 Then Err.Raise cmErrQueryInsert
Set adoRS = Nothing
ExecuteQuery = nRecordsAffected

Aktualisieren von Datensätzen
Ein Aktualisieren von Datensätzen erfordert gewisse eine optimistische Sperrung betreffende Informationen. Auf dem Server wird ein eindeutiger Wert angefordert, um das letztmalige Modifizieren anzugeben. Ferner wird der letzte Lesezeitstempel verwendet, um während der Aktualisierung zu validieren, dass der Datensatz seit dem letztmaligen Lesen nicht modifiziert worden ist.
Probe von Clientkomponentenadapter (CCA)

Dim vNewTS as Variant
vNewTS = objServer.PerformUpdate(vMsg, 1, 'Rick', 8907654)
' Zeitstempel des Objekts auf vNewTS einstellen

Probecodeausschnitt von Serverkomponente
Codeausschnitt von ExecuteQuery (Aktualisierungsabschnitt)
Löschen von Datensätzen
Bei einem Löschen von Datensätzen wird der letzte Lesezeitstempel verwendet, um während des Löschens zu validieren, dass der Datensatz seit dem letztmaligen Lesen nicht modifiziert worden ist.
Probe von Clientkomponentenadapter (CCA)

Dim vAns as Variant
vAns = objServer.PerformDelete(vMsg, nId, lLastTS)

Probe von Serverkomponente
Codeausschnitt von ExecuteQuery (Löschungsabschnitt)
DATENBANKSPERRUNGSRAHMEN
Eine Datenbanksperrung stellt die Integrität der Datenbank in einer Mehrbenutzerumgebung sicher. Eine Sperrung verhindert das häufige Problem von verloren gegangenen Aktualisierungen von mehreren den gleichen Datensatz aktualisierenden Benutzern.
Lösungsoptionen
Pessimistische Sperrung
Diese Politik der Sperrung ermöglicht es dem ersten Benutzer, einen vollen Zugriff auf den Datensatz zu haben, während folgenden Benutzern ein Zugriff verweigert wird oder sie einen Nur-Lese-Zugriff haben, bis der Datensatz entsperrt ist. Es sind Nachteile bei diesem Verfahren zur Sperrung vorhanden. Es ist ein Verfahren, das anfällig für gegenseitige Sperrungen auf der Datenbank sowie eine schlechte Leistung, wenn auf Konflikte gestoßen wird, ist.
Optimistische Sperrung
Der optimistische Ansatz zu der Datensatzsperrung basiert auf der Annahme, dass es keine normale Verarbeitung für mehrere Benutzer ist, Datensätze gleichzeitig sowohl zu lesen als auch zu aktualisieren. Diese Situation wird als Ausnahmeverarbeitung statt als normale Verarbeitung behandelt. Zu der Lesezeit werden nicht tatsächlich Sperrungen auf der Datenbank platziert. Zu der Zeit des Aktualisierens oder Löschens wird ein Zeitstempelmechanismus verwendet, um sicherzustellen, dass ein anderer Benutzer den Datensatz nicht modifiziert oder gelöscht hat, seit du den Datensatz zuletzt gelesen hast.
Ein bevorzugtes Ausführungsbeispiel der vorliegenden Erfindung verwendet einen Ansatz der optimistischen Sperrung zur Steuerung des gleichzeitigen Zugriffs. Dies stellt die Datenbankintegrität sowie den mit dieser Form der Sperrung verbundenen geringen Overhead sicher. Andere Vorteile bei diesem Verfahren sind eine erhöhte Verfügbarkeit von Datensätzen für mehrere Benutzer und eine Minimierung von gegenseitigen Sperrungen der Datenbank.
Tabellenkandidaten für eine Steuerung des gleichzeitigen Zugriffs werden während der "Datenmodellierungsübung" identifiziert. Die einzige Tabelle, die gleichzeitig aktualisiert wird, ist der Mechanismus der optimistischen Sperrung. Sobald diese identifiziert sind, wird das Folgende zu der Anwendung hinzugefügt.
Feld "N_Last_Updt" zu Tabelle in Datenbank hinzufügen;
Fehlerhandhabungsroutinen bei den Operationen, die aus dieser Tabelle modifizieren oder löschen; und
Anzeige/Mitteilung für Benutzer, dass der Fehler aufgetreten ist.
Verwendung
Die nachstehende Tabelle beschreibt die Rollen der zwei grundlegenden Typen von Komponenten zum Ermöglichen einer optimistischen Sperrung.

Annahme: Das Feld der optimistischen Sperrung ist von dem Typ Datum und wird "N_Last_Updt" genannt

GROSSER ERGEBNISSATZ
Wenn Datensätze aus einer Datenbank wiedergewonnen werden, wird die Menge von Daten, deren Wiedergewinnung aus der Datenbank und Weitergabe quer über das Netz erforderlich ist, die durch den Benutzer wahrgenommene Leistung beeinflussen, falls die Suchkriterien zu weit sind. Fenster, die derartige Daten anfordern, werden langsam zu malen sein, und Suchen werden langsam sein. Die Ausbildung der Datenbankabfragen wird derart ausgeführt, dass eine praktikable Menge von Daten wiedergewonnen wird. Es sind ein paar Optionen vorhanden, um sich den Problemen zu widmen, die aus großen Ergebnissätzen entstehen. Die Optionen sind nachstehend in der Reihenfolge der Präferenz angegeben.
Die Schnittstelle/Steuerungseinheit neu entwerfen, um kleinere Ergebnissätze zurückzugeben. Durch ein Entwerfen der Steuerungseinheiten, die die Datenbankabfragen intelligent präsentieren, geben die Abfragen, die dem Datenbankserver präsentiert werden, keinen Ergebnissatz zurück, der groß genug ist, um die durch den Benutzer wahrgenommene Leistung zu beeinflussen. Im Wesentlichen gibt das Potential zum Wiedergewinnen von zu vielen Datensätzen an, dass die UIs und die Steuerungseinheiten verschieden entworfen worden sind. Ein Beispiel für eine gut entworfene Such-UI ist eines, bei dem der Benutzer dazu aufgefordert wird, minimale Suchkriterien einzutragen, um einen übermäßig großen Ergebnissatz zu verhindern.
Scrollbare Ergebnissätze haben. Die scrollende Wiedergewinnung eines großen Ergebnissatzes ist die inkrementelle Wiedergewinnung einer Ergebnisuntermenge, die so viele Male, wie es der Benutzer anfordert, oder bis der ganze Ergebnissatz erhalten ist wiederholt wird. Ergebnisse werden durch den Ansatz der begrenzten Abfrage (Bounded Query Approach) wiedergewonnen, bei dem der erste Datensatz durch eine Wo-Klausel (where clause) mit berechneten Werten bestimmt wird.
Clientanforderungen für scrollbaren Ergebnissatz
Bevorzugte UI
Die bevorzugten Anzeigen stellen sich dar wie folgt:
Zurückgegebene Ergebnisse werden in einem GreenTree-Listenfeld angezeigt;
Eine Aktionsschaltfläche mit der Aufschrift Mehr ... wird für den Benutzer bereitgestellt, um die verbleibenden Ergebnisse zu erhalten;
Die Mehr-Schaltfläche wird freigegeben, wenn der Benutzer eine anfängliche Suche durchgeführt hat und immer noch wiederzugewinnende Ergebnisse vorhanden sind;
Die Mehr-Schaltfläche wird gesperrt, wenn keine wiederzugewinnenden Ergebnisse mehr vorhanden sind;
Das Listenfeld und die Aktionsschaltfläche sind in einem Gruppenfeld enthalten, um eine visuelle Verbindung zwischen der Schaltfläche und dem Listenfeld bereitzustellen.
Begrenzte Abfrage
Abfragen, die mit den begrenzten Ergebnissätzen realisiert werden, werden zu dem Server gesendet. Der Server realisiert das executeQuery-Verfahren, um die Datensatzgruppe wie gewöhnlich wiederzugewinnen. Begrenzte Ergebnisabfragen haben eine Reihenfolge gemäß einer Klausel, die die durch das Geschäft erforderte Sortierungsreihenfolge zusammen mit einer ausreichenden Anzahl von Spalten zum Sicherstellen, dass alle Zeilen eindeutig identifiziert werden können, aufweist. Die Datensatzgruppe wird durch die von dem Client weitergegebene Variable nMaxRows, die zum Erhalten der ersten Zeile des nächsten Ergebnissatzes erhöht wird, begrenzt. Die Rückgabe von der Komponente ist genau so wie mit einer Abfrage, die nicht begrenzt ist, eine Datensatzgruppe. Der CCA 208 erzeugt die Objekte und leitet diese zurück zu der Steuerungseinheit 206. Die Steuerungseinheit 206 fügt diese zurückgegebene Sammlung von Objekten zu ihrer Sammlung von Objekten (eine Ansammlung von vorhergehenden Ergebnissen) hinzu, und während sie dies tut, wird sie den Vergleich des letzten Objekts mit dem ersten Objekt der nächsten Zeile durchführen. Die zum Unterscheiden der zwei Zeilen notwendigen Werte werden zu der regelmäßigen Variantenanordnung, die zum Weitergeben zu der Komponente für die nachfolgende Abfrage notwendig ist, hinzugefügt.
Die Steuerungseinheit 206 auf dem Client behält die Werte für nMaxRows, die anfängliche SQL-Anweisung und die regelmäßige Anordnung von Werten, um zwischen der letzten Zeile der vorhergehenden Abfrage und der ersten Zeile der nächsten Abfrage zu unterscheiden. Der Mechanismus, durch den sich die Steuerungseinheit 206 bewusst ist, dass mehr wiederzugewinnende Datensätze vorhanden sind, besteht darin, zu überprüfen, dass die Anzahl von Ergebnissen eins größer als die maximale Anzahl von Zeilen ist. Zum Verhindern der Wiedergewinnung von Datensätzen über das Ende der Datei hinaus sperrt die Steuerungseinheit 206 diese Funktionen bei der UI. Es wird zum Beispiel eine Befehlsschaltfläche Mehr bei der UI, die zum Anfordern der Daten verwendet wird, gesperrt, wenn die Anzahl von zurückgegebenen Objekten kleiner als nMaxRows + 1 ist.
Anwendungsverantwortlichkeit
Server
Die Serverkomponente ist für ein Erzeugen einer Sammlung von Argumenten und ein Anhängen der SQL-Anweisung zum Hinzufügen einer Wo-Klausel, die dazu in der Lage sein wird, zwischen der letzten Zeile der vorhergehenden Abfrage und der ersten Zeile der nächsten zu unterscheiden, verantwortlich.
CCA
Der CCA 208 verarbeitet die Datensatzgruppe in Objekte wie bei nicht begrenzten Abfragen. Der CCA 208 leitet die von der Steuerungseinheit 206 weitergegebene regelmäßige Variantenanordnung weiter, um die begrenzten Ergebnisse zu identifizieren.
Steuerungseinheit
Die Steuerungseinheit 206 hat die Verantwortlichkeit des Sperrens der Mehr-Steuerung, wenn das Ende der Datei erreicht worden ist. Die Steuerungseinheit 206 besetzt die regelmäßige Variantenanordnung (vKeys) mit den zum Bestimmen eines Starts der nächsten Abfrage notwendigen Werten.
Beispiel
Ein CCA 208 wird für eine benutzerdefinierte Suche, die das Potential zum Zurückgeben eines ziemlich großen Ergebnissatzes hat, codiert. Das nachstehende Codebeispiel realisiert den Ansatz der begrenzten Abfrage.
Auf dem Server codiert der Entwickler die Abfrage wie folgt:
End Function
Zum Bestimmen der zusätzlichen Wo-Klausel, die zum Bestimmen des Startpunkts der Abfrage notwendig ist, wird das folgende Verfahren hinzugefügt:
Auf dem CCA 208 muss eine Erlaubnis für das Weitergeben der vKeys erteilt werden.
Die Steuerungseinheit leitet die Abfrage ein und aktualisiert die regelmäßige Variantenanordnung von Schlüsseln und Eigenschaften des Formulars 204 basierend auf der Rückgabe. Zusätzlich zu dem für das nachstehende Beispiel gezeigten Code wird die Mehr-Steuerung freigegeben, falls die Suche zurückgesetzt wird.
' Instanzvariablen vereinbaren
Private nMaxRows As Integer
Dim interimResults As CCollection
Dim vResults As CCollection
Dim vKeys(3) As Variant
' Konstanten vereinbaren
Private Const nDefaultAmount As Long = 50
Private Const cmRetrieveBusinessObjectSQL = "SELECT * FROM NODE_RULE ORDER BY_N_TASK_TEMPL_ID"
Während einer Klasseninitialisierung das Folgende durchführen:
Die Suchrücksetzfunktionalität wird außerhalb der Initialisierung gehalten, so dass diese von anderen Teilen der Anwendung aufgerufen werden kann.
Zum Behalten der Werte zum Unterscheiden zwischen der letzten Zeile des Ergebnissatzes und der ersten Zeile des nächsten wird das folgende Verfahren auf der Steuerungseinheit verwendet:
Betrieb von Beispiel mit Daten
Man lasse für dieses Beispiel nMaxRows = 3 sein. Der Geschäftsfall verlangt danach, den Ergebnissatz nach dem Nachnamen zu ordnen, und der Entwickler weiß, dass jede Zeile durch Felder des Vornamens bzw. FirstName, Nachnamens bzw. LastName und der eindeutigen ID bzw. Unique ID eindeutig identifiziert werden kann, so dass die in der Steuerungseinheit als eine Konstante hinzugefügte anfängliche SQL sein sollte; SELECT * FROM Person ORDER BY LastName, FirstName, Unique_ID
Anfängliche Abfrage
Die erste Abfrage wird mit einer leeren regelmäßigen Anordnung vKeys gesendet. Wenn der Server diese Abfrage empfängt, identifiziert das Verfahren ArqumenteFürGeschäftsobjekt bzw. ArgumentsForBusinessObject die Elemente als leer und besetzt die colArgs nicht. Die Abfrage wird mit der unveränderten anfänglichen SQL ausgeführt. Die Datensatzgruppe der Größe nMaxRows + 1 wird zu dem CCA 208 zurückgegeben und genau so wie nicht begrenzte Ergebnisse verarbeitet. Der CCA 208 gibt die Sammlung von Objekten zu der Steuerungseinheit 206 zurück. Die Steuerungseinheit 206 fährt fort, die Sammlung vResults mit den zurückgegebenen Objekten zu besetzen. vResults ist die umfassende Sammlung von zurückgegebenen Objekten. Wenn das letzte Objekt der ersten Anforderung erreicht wird (bei nMaxRows), werden die Werte als solche in vKeys gespeichert;
vKeys(0) = LastName (Barleycorn)
vKeys(1) = FirstName (John)
vKeys(2) = Unique_ID (512)
Wenn das erste Objekt der nächsten Anforderung erreicht wird (bei nMaxRows + 1), wird ein Vergleich der Objektvariablen gegen die Werte von vKeys durchgeführt. Da die letzten Namen übereinstimmen, wird vKeys (2) nicht gelöscht, und es werden keine weiteren Überprüfungen durchgeführt.
Nachfolgende Abfrage
Die nachfolgende Abfrage wird vKeys zusammen mit ihr weitergeben. Der Server erzeugt die Sammlung von Argumenten aus vKeys und hängt die entsprechende sSq1-Zeichenfolge an. Die sSq1-Anweisung, die zu execute query geleitet wird, ist
SELECT * FROM Person ORDER BY LastName, FirstName, Unique_ID
WHERE ? >= ? AND ? >= ? AND ? > ?
Diese sSq1 und Sammlung sind in dem Aufruf an ExecuteQuery enthalten, der die Argumente mit der sich auf das Architekturverfahren MergeSQL stützenden Zeichenfolge vereinigt, um die SQL-Anweisung zu vervollständigen. Der Startpunkt der Datensatzgruppe wird durch die WO-Klausel definiert, und die Grenze wird durch den Wert nMaxRows eingestellt.
Abfrage für weniger beschränkende WO-Kriterien
Nach der zweiten Abfrage ist die letzte Zeile der Abfrage David Dyson, und die nächste ist Bobby Halford. Da der Nachname verschieden ist, wird vKeys abgesehen von vKeys(0) = Dyson leer sein. Die VerarbeiteObjektsammlung bzw. ProcessObjectCollection wird vKeys wie folgt besetzen, wenn das Objekt nMaxRows verarbeitet wird:
vKeys(0) = LastName (Dyson)
vKeys(1) = FirstName (David)
vKeys(2) = Unique_ID (98)
Nach einem Identifizieren der Unterschiede zwischen Werten von vKeys und dem Objekt nMaxRows + 1 wird die regelmäßige Anordnung vKeys aktualisiert wie folgt:
vKeys(0) = LastName (Dyson)
vKeys(1) = Leer
vKeys(2) = Leer
Die Abfrage, die von ArgumentsForBusinessObject zurückgegeben wird, ist
SELECT * FROM Person ORDER BY LastName, FirstName, Unique_ID
WHERE ? > ?
und die den Feldnamen FirstName und den Wert ("David") besitzenden colArgs. ExecuteQuery vereinigt die Argumente mit der SQL-Anweisung wie zuvor und gibt den Wert zurück.
Ende
Nach der fünften Iteration wird der Ergebnissatz nur 2 Datensätze besitzen. Wenn die Steuerungseinheit 206 die zurückgegebene Sammlung verarbeitet, ist der von ProcessObjectCollection zurückgegebene Zähler kleiner als nMaxRows + 1, was angibt, dass alle Datensätze wiedergewonnen worden sind.
SICHERHEITSRAHMEN
Realisierung
Die 8 zeigt eine Darstellung des Sicherheitsrahmens 800 und seiner Hauptkomponenten.
Es kann aus der 8 ersehen werden, dass das Sicherheitsobjekt 802 bei dem Client vorhanden ist und eine Sicherheits-API bei dem Server bereitgestellt ist. Das Sicherheitsobjekt 802 stellt ein für ein Autorisieren jeder Operation verantwortliches Verfahren bereit, wobei ihm die Struktur vMsg, eine Operations-ID und ein den Kontext der Operation beschreibender optionaler Parameter zugewiesen werden.
Client
Benutzerauthentifizierung:
Eine Benutzerauthentifizierung wird über ein sich in dem Sicherheitsobjekt 802 befindendes Verfahren namens IsOperAuthorized gehandhabt. Während das Anwendungsobjekt lädt, ruft es vor einem Ausführen einer weiteren Verarbeitung das Verfahren IsOperAuthorized auf, wobei die Operation "Anmeldung" ist. Dieses Verfahren ruft anschließend eine Authentifizierungs-DLL, die für ein Identifizieren des Benutzers als einen autorisierten Benutzer innerhalb der Firmensicherheit verantwortlich ist, auf.
UI-Steuerungseinheiten:
Die UI-Steuerungseinheiten begrenzen einen Zugriff auf ihre Funktionen durch ein Beschränken des Zugriffs auf spezifische Widgets durch ein Freigeben und Sperren derselben. Die Logik für das Freigeben und Sperren von Widgets verbleibt auf der UI-Steuerungseinheit 206, aber die Logik zum Bestimmen, ob ein Benutzer Zugriff auf eine spezifische Funktionalität hat, befindet sich in der Form von Geschäftsregeln in dem Sicherheitsobjekt 802. Die UI-Steuerungseinheit 206 ruft das Verfahren IsOperAuthorized auf, um den Zustand ihrer Widgets einzustellen.
Server
Die Serversicherheit wird durch ein Beschränken des Zugriffs auf die Daten auf drei verschiedene Weisen realisiert:
Serversicherheitsverfahren
Serverkomponenten 222 rufen die API IsOperAuthorized in der Architektur auf, bevor jede Operation ausgeführt wird. In allen Fällen gibt das Sicherheitsobjekt 802 einen booleschen Wert gemäß den Zugriffsrechten des Benutzers und den Geschäftsregeln zurück.
SQL-Filterung
Nimmt Sicherheitsattribute wie eine Anspruchsempfindlichkeit oder eine öffentliche/private Dateinotiz in die SQL-Anweisungen auf, wenn Zeilen ausgewählt oder aktualisiert werden. Dies beschränkt den sich ergebenden Datensatz effizient und vermeidet die Rückgabe von beschränkten Daten zu dem Client.
Beschreibung
Jede sich auf die GUI beziehende Sicherheit wird unter Verwendung des Sicherheitsobjekts 802 bei dem Client realisiert. Die Informationen sind sowohl bei dem Clientprofil als auch Geschäftsobjekten 207 verfügbar, was es ermöglicht, die Sicherheitsregeln richtig auszuwerten.
IsOperAuthorized wird aufgerufen, um bei dem Laden einer UI oder falls einen Änderung des Zustands in der UI vorhanden ist Widgets einzustellen.
Die Benutzerauthentifizierung wird immer durch die Anwendungsobjekte 202 verwendet, um ein Benutzerprivileg zum Starten der Anmeldung zu validieren.
Die SQL-Filterung wird in den Fällen, in denen empfindliche Daten nicht einmal bei dem Client verfügbar sein dürfen oder in denen ein großer Vorteil bei dem Verringern der Größe des zu dem Client zurückgegebenen Datensatzes vorhanden ist, verwendet.
Die SQL-Filterung wird nur in sehr seltenen Fällen, in denen die Leistung eine ernsthafte Angelegenheit ist, verwendet. Sie wird vorsichtig verwendet, um eine gesteigerte Komplexität und Leistungsauswirkungen zu vermeiden, da einige Abfragen beschwerlich sein können und ein Einbetten von Sicherheit bei ihnen die Komplexität sogar noch mehr steigern könnte.
Sicherheitsrahmen
Überblick
Das Sicherheitsobjekt 802 dient dem Zweck des Haltens von fest eingebauten Geschäftsregeln zum Gewähren oder Verweigern eines Benutzerzugriffs für verschiedene Anwendungsfunktionen. Diese Informationen werden zu den UI-Steuerungseinheiten 206, die die notwendigen Modifikationen bei dem UI-Zustand ausbilden, zurückgegeben. Das Clientprofilobjekt bzw. ClientProfile-Objekt dient dem Zweck des Speicherns von benutzerspezifischen (und statischen) Sicherheitsinformationen im Cache direkt auf dem Client. Diese Informationen sind zum Auswerten der Geschäftsregeln bei dem Sicherheitsobjekt 802 notwendig.
Beziehungen
Die 9 zeigt die Beziehungen zwischen dem Sicherheitselement und anderen Elementen.
Architekturobjekt
Das TechArch-Objekt ist für ein Bereitstellen eines Zugriffs und ein Aufrechterhalten des Zustands der Objekte Clientprofil bzw. ClientProfile 902 und Sicherheit bzw. Security 802 verantwortlich. Das Clientprofilobjekt 902 wird in den Initialisierungs- bzw. Beendungsverfahren von TechArch instanziiert und zerstört. Dieses Objekt wird durch eine Instanzvariable bei dem TechArch-Objekt instand gehalten.
CInitCompCCA
Das CInitCompCCA-Objekt 904 stellt zwei Dienste für das Architekturobjekt 200 bereit, es dient als ein Zugriffspunkt für den CInitComp-Server 906, und es führt das eingestellte Abfrageergebnis in ein Clientprofilobjekt 902.
CInitComp
Das CInitComp-Server-Objekt 906 stellt einen Datenzugriff auf die Daten, die sich in den Organisationstabellen 908 befinden, bereit. Diese Daten sind auf dem Client verwendbar, um eine Stufe des Zugriffs auf Daten basierend auf fest eingebauten Geschäftsregeln zu bestimmen.
Organisationstabellen
Die Organisationstabellen 908 enthalten Benutzer-, Angestellten- und Einheitsinformationen, die zum Aufbauen der Hierarchie von Informationen, die zum Bestimmen einer Stufe des Zugriffs auf empfindliche Informationen notwendig ist, notwendig sind.
Clientprofil
Das Clientprofilobjekt 902 dient dem Zweck des Speicherns von statischen, benutzerspezifischen Sicherheitsinformationen im Cache direkt auf dem Client. Diese Informationen sind zum Bestimmen einer Datenzugriffsstufe von Informationen für den Benutzer notwendig, was erreicht wird, indem die notwendigen Werte zu dem Sicherheitsobjekt 802 geleitet werden.
Sicherheitsobjekt
Das Sicherheitsobjekt 802 enthält Geschäftsregeln, die zum Bestimmen von Zugriffsprivilegien eines Benutzers in Bezug auf spezifische Funktionen verwendet werden. Das Objekt akzeptiert gewisse Parameter, die durch die verschiedenen UI-Steuerungseinheiten 206 eingeleitet werden, und gibt sie an die Geschäftsregellogik weiter, die dann wieder das Clientprofilobjekt 902 nach spezifischen Benutzerinformationen befragt.
Clientprofil
Attribute
Das Folgende sind interne Attribute für das Clientprofilobjekt 902. Diese Attribute werden der Anwendung nicht gezeigt und sollten nur durch das Sicherheitsobjekt 802 verwendet werden:
• sProfile
Dieses Attribut wird durch die ältere (legacy) Anwendung bei der Startprozedur weitergegeben und enthält die TSIds, den Extern-Indikator, den Zählwert von Gruppenelementen und Gruppenelemente des Benutzers. Es wird durch eine Anforderung von den Anwendungsobjekten in diese Attribute geführt.
• colSpecialUsers:
Dieses Attribut speichert Informationen aus einer spezielle Benutzer, die nicht in eine der beschriebenen Rollen passen, wie beispielsweise einen Organisationsbibliothekar enthaltenden Tabelle im Cache. (Zum Beispiel der stellvertretende Vorsitzende oder Vorstandsvorsitzende der Firma.)
• sTSId:
Dies ist die TSId des derzeitigen Benutzers, und sie entspricht seiner/ihrer Windows-NT-Id. Sie wird zum Gewinnen von Informationen über den derzeit angemeldeten Benutzer aus den Organisationstabellen 908 verwendet.
• sEmployeeId:
Diese entspricht der Angestellten-Id des Benutzers wie in den Organisationstabellen 908 gespeichert. Sie wird gegen die eingeleitete Angestellten-Id verwendet, um eine Beziehung zwischen Ausführenden und dem derzeitigen Benutzer zu überprüfen.
• sEmployeeName, sEmployeeFirst, sEmployeeMI und sEmployeeLast:
Alle diese Attribute entsprechen dem Namen des derzeitigen Benutzers.
• dictClientPrivileges:
Dieses Attribut enthält eine Sammlung von Identifizierungen, die angeben, welche Rolle/Befugnis eine Einzelperson spielt/besitzt. Dieser Wert wird zum Identifizieren der statischen Rolle des angemeldeten Benutzers verwendet.
Diese Werte werden für eine Sicherheitsgeschäftslogik verwendet, die basierend darauf, ob der Benutzer intern oder extern ist oder ob der Benutzer sich in einer gegebenen administrativen Rolle befindet, einen Zugriff gewährt oder verweigert. Vorhandene Werte sind die folgenden:

• SC – gibt Befugnis für empfindlichen Anspruch an
• CC – gibt Befugnis zum Ändern von Anspruchsstatus an
• MT – gibt Befugnis zum Warten von F&C-Vorlagen an MO – gibt Befugnis zum Warten von Organisation an
• MR – gibt Befugnis zum Warten von Rollen an

Das Folgende sind die vorgeschlagenen Hinzufügungen:

• TA – gibt Befugnis zum Ausführen von Aufgabenassistent an
• FN – gibt Befugnis zum Ausführen von Dateinotizen an
• CH – gibt Befugnis zum Ausführen von Anspruchsverlauf an
• TL – gibt Befugnis zum Warten von Aufgabenvorlagen an

• dictProxyList:
Dieses Attribut enthält eine Berichterstattungshierarchie eines Angestellten. Es wird zum Bestimmen, ob der derzeitige Benutzer/Angestellte eine Erlaubnis zum Durchführen einer Aktion hat, basierend auf seiner/ihrer Beziehung zu anderen Benutzern/Angestellten in der Hierarchie verwendet. Ein Geschäftsbeispiel dafür ist der Fall eines Vorgesetzten, der Rechte zum Betrachten von Informationen, zu denen seine/ihre Untergebenen Zugriff haben, hat. Die Beziehungs-APIs benutzen dictProxyList zum Bestimmen, ob der den Informationen zugewiesene Benutzer ein Vorgesetzter oder Untergebener des derzeitigen Benutzers ist.
• boolInternal:
Dieses Attribut gibt an, ob der angemeldete Benutzer extern oder intern ist. Es wird auch aus dem durch die ältere Anmeldung eingeleiteten Attribut sProfile geführt.
Öffentliche Verfahren
Das Folgende sind die durch das Clientprofilobjekt gezeigten APIs. Diese APIs werden durch das Sicherheitsobjekt zur Sicherheitsüberprüfung verwendet und sollten nicht in irgendeinem Abschnitt der Anwendung durch die Entwickler verwendet werden.
• GetAuthorizedEmployees As Collection
Diese Funktion gibt eine Sammlung von Angestellten-Ids von den durch den derzeitigen Benutzer überwachten Angestellten zurück.
• IsSuperOf(sUserId) As Boolean
Diese API gibt wahr zurück, falls der angemeldete Benutzer ein Vorgesetzter der eingeleiteten Benutzer-Id ist. Sie schlägt den sUserId-Wert in dem Attribut dictProxyList nach.
• IsRelativeOf(sUserId) As Boolean
Diese API gibt wahr zurück, falls die eingeleitete Benutzer-Id entweder dem angemeldeten Benutzer oder jemandem aus der dictProxyList entspricht
• IsInternal As Boolean
Dies API wird dazu verwendet, dem Benutzer basierend darauf, ob die Daten für die Organisation privat sind und ob der Benutzer intern oder extern ist, einen Zugriff auf Informationen zu gewähren oder zu beschränken.
• IsInRole(sRole) As Boolean
Diese API schlägt den in dem Attribut dictClientRoles enthaltenen passenden SRole-Wert nach, um zu bestimmen, ob der derzeitige Benutzer zum Spielen der Rolle autorisiert ist.
Die folgenden Accessoren werden zum Gewinnen von Daten aus dem Objekt des Clientprofils verwendet:

• UserId: gibt sTSId zurück
• EmployeeId: sEmployeeId zurückgeben
• EmployeeName: gibt sEmployeeName zurück
• EmployeeFirstName: gibt sEmployeeFirst zurück
• EmployeeLastName: gibt sEmployeeLast zurück
• EmployeeMiddleInitial: gibt sEmployeeMI zurück
• ExpandTree: gibt boolExpandTreePreference zurück
• TemplatePathReference: gibt sTemplatePathPreference zurück

Sicherheitsobjekt
Öffentliche Verfahren
Die folgende API wird durch das Sicherheitsobjekt gezeigt und wird durch die Anwendung zur Sicherheitsüberprüfung verwendet:
• IsOperAuthorized(vMsg As Variant, nOperations As cmOperations, vContext As Variant) as Boolean
Diese API wird abhängig davon, was von den Geschäftsregelfunktionen zum Bestimmen von Benutzerzugriffsstufen zurückgegeben wird, wahr oder falsch zurückgeben. Diese API wird in zwei Situationen aufgerufen:

1. Wenn vor einem Laden des Formulars der Anfangzustand eingestellt wird. Falls eine Sicherheitsanforderung vorhanden ist, wird IsOperAuthorized für die passende Operation aufgerufen.
2. Nach jeder relevanten Änderung bei dem UI-Zustand. Wenn zum Beispiel ein empfindlicher Anspruch in dem Aufgabenassistentenfenster hervorgehoben wird. Eine relevante Änderung ist eine, die den Bedarf an einer Sicherheitsüberprüfung mit sich bringt.

Die gültigen Werte für die Aufzählung und die entsprechenden Kontextdaten sind:

• cmMaintainFormsCorr (keine)
• cmRunEventProcessor (keine)
• cmWorkOnSensitiveClaim (ein Anspruchsobjekt)
• cmMaintainPersonalProfile (keine)
• cmMaintainWorkplan (keine)
• cmDeleteFileNote (ein Dateinotizobjekt)
• cmMaintainTaskLIbrary (keine)
• cmMaintainOrg (keine)

Serversicherheits-APIs
• IsSVCOperAuthorized (vMsg As Variant, sOperations As String, vContext As Variant) as Boolean
Diese API wird durch jedes Verfahren auf dem Server, das Daten persistent macht oder potentiell auf empfindliche Daten zugreifen kann, aufgerufen (reagierender Ansatz).
• IsOperAuthorized (vMsg As Variant, nOperations As cmOperations, vContext As Variant) as Boolean
Diese API ist für die Fälle, in denen eine Eigeninitiative zeigende Sicherheitsüberprüfung auf dem Server benötigt wird, verfügbar.
Realisierungsbeispiele
Die folgenden Beispiele zeigen einige Wege zum Realisieren der vorstehend beschriebenen Optionen:
Client
• Geschäftslogik
IsOperAuthorized
Es wird der Fall des Aufgabenassistentenfensters betrachtet, in dem es dem Benutzer nicht erlaubt sein sollte, sich irgendwelche Informationen über einen empfindlichen Anspruch anzusehen, falls er/sie nicht der Anspruchsausführende oder der Vorgesetzte des Ausführenden ist. Der folgende Code wäre bei der Steuerungseinheit:
Es wird der Fall des Korrespondenz-Warten-Suche-Fensters (Maintain Correspondence Search window) betrachtet, in dem es nur einem Benutzer, der ein Formular- und Korrespondenzbibliothekar ist, erlaubt werden sollte, eine Vorlage zu löschen. Der folgende Code wäre bei der Steuerungseinheit:
Server
• SQL-Filterung:
Es wird der Fall des Entwurfsdateinotizfensters betrachtet, in dem ein Benutzer nur auf die Entwurfsdateinotizen schauen kann, deren Autor er/sie ist. Bei der Steuerungseinheit würde man haben:
Und bei der Komplemente wäre die SQl-Anweisung:
Diese Anwendung läuft als ein Hintergrundprozess oder -dienst ohne eine direkte Interaktion mit Clientanwendungen auf dem Server, so dass sie keine sich auf die GUI beziehende Sicherheit benötigt. Grundsätzlich sind ihre Hauptaktionen auf die Erzeugung von neuen Aufgaben im Ansprechen auf extern erzeugte Ereignisse beschränkt, oder sie tut genauer Folgendes:

• Sie liest statische Informationen aus den Aufgabenvorlagentabellen;
• Sie liest Ereignisse aus den Ereignistabellen;
• Sie fügt Aufgaben in die Aufgabentabelle ein.

In diesem Sinne ist ihre Sicherheit gänzlich von externen Einheiten abhängig, wie nachstehend beschrieben:

• Die Aufgabenbibliotheksanwendung ist der Zugangspunkt für irgendwelche Änderungen bei den Aufgabenvorlagendatenbanktabellen. Sie wird die vorstehend beschriebenen Optionen nutzen, um ihre Sicherheitsanforderungen zu erfüllen.
• Ereignisse werden von älteren Anwendungen erzeugt, so dass die Aufgabeneinheit sich vollständig auf die für diese Anwendungen realisierte Sicherheit stützt, um die Erzeugung von Ereignissen zu steuern.
• Eine andere Stufe der Sicherheit für die Ereigniserzeugung stützt sich auf die Datenbankautorisierungs- und -authentifizierungsfunktionen. Nur autorisierte Komponenten haben Zugriff auf die Datenbanktabellen (dies ist ebenso für alle die anderen Anwendungen gültig).

ANSPRUCHSORDNER
Definition
Der Anspruchsordner verwaltet Anspruchsinformationen von einer ersten Mitteilung ganz durch ein Schließen und Archivieren. Er tut dies durch ein Bereitstellen einer strukturierten und leicht zu verwendenden Schnittstelle, die mehrere Geschäftsprozesse zum Handhaben von Ansprüchen unterstützt. Die Informationen, die er erfasst, werden vielen anderen Komponenten zugeführt, die es Anspruchsfachleuten ermöglichen, vorbereitende Anwendungen, die ihr Arbeitspensum verringern, zu nutzen. Da immer noch physische Anspruchsdateien erforderlich sind, stellt der Anspruchsordner Fähigkeiten bereit, die ein Verfolgen von physischen Dateien unterstützen. Er arbeitet mit dem ÄLTEREN System bzw. LEGACY-System, um alle die Fähigkeiten, die in dem derzeitigen System vorhanden sind, zu unterstützen.
Die durch den Anspruchsordner unterstützten primären Prozesse sind:
• Erste Mitteilung von Schadensfall
Der Anspruchsordner ist der primäre Eintragungspunkt für neue Schadensfallinformationen. Anspruchsdateien sind in dem Anspruchsordner vorhanden, bevor sie in das LEGACY-System "gepusht" bzw. "geschoben" werden, um eine finanzielle Verarbeitung durchzuführen.
• Anspruchserkundigung
Der Anspruchsordner unterstützt interne und externe Erkundigungen nach Anspruchsinformationen. Der Ordnerentwurf ermöglicht aus vielen verschiedenen Gründen einen schnellen Zugriff auf verschiedene Ebenen von Informationen in dem Anspruch.
• Einleitung von Anspruchshandhabung
Der Anspruchsordner stellt anfängliche Schadensfallinformationen für die Anspruchsfachleute bereit, so dass sie den Prozess des Ausbildens von ersten Kontakten mit passenden Teilnehmern an dem Anspruch beginnen können. Er ermöglicht es ihnen, durch ihre anfänglichen Kontakte und eine Untersuchung erhaltene Daten zu betrachten und einzutragen.
• Untersuchung und Auswertung
Der Anspruchsordner stellt einen Zugriff auf für den Untersuchungs- und Auswertungsprozess benötigte detaillierte Informationen bereit. Er ermöglicht es den Anspruchshandhabern, zwischen allen den Anwendungen und Informationen, die sie zum Unterstützen dieser Prozesse benötigen, zu navigieren.
• Identifizieren von Anspruchsereignissen
Der Anspruchsordner identifiziert während des Bestehens eines Anspruchs auftretende entscheidende Ereignisse wie beispielsweise eine Änderung des Status, die Antworten bei anderen Komponenten zum Durchführen automatisierter Funktionen auslösen können, wie ein Auslösen von Aufgaben in dem Aufgabenassistent.
• Verwalten der physischen Datei
Der Anspruchsordner unterstützt bessere Verfolgungsfähigkeiten für die physischen Dateien, die mit dem elektronischen Datensatz eines Anspruchs einhergehen.
Wert
Durch ein Erfassen von detaillierten Informationen über Ansprüche versucht der Anspruchsordner, die Effizienz von Anspruchsfachleuten auf vielen Wegen zu verbessern. Erstens ist weniger Einarbeitung zum Finden von grundlegenden Informationen zum Unterstützen einer beliebigen Anzahl von Erkundigungen erforderlich, da die Informationen in einem logischen, leicht zu verwendenden Format organisiert sind. Zweitens verwendet der Anspruchsordner seine Informationen zum Unterstützen von anderen Anwendungen wie Formularen und Korrespondenz, so dass Anspruchsinformationen nicht jedes Mal, wenn sie benötigt werden, neu eingetragen werden müssen. Drittens stellt er bessere Wege zum Finden von physischen Dateien zum Verringern der für ein Finden derselben und Arbeiten mit ihnen erforderlichen Zeit bereit. Darüber hinaus sind viele andere potentielle Verwendungen von Anspruchsordnerinformationen vorhanden.
Der Anspruchsordner versucht auch, einige der derzeitigen Verarbeitungsanforderungen zu überwinden, die das LEGACY-System auferlegt, wie beispielsweise ein Aufzeichnen von Schadensfällen ohne Ansprüche, ein Erfordern von Versicherungsscheinnummern zur Anspruchseinrichtung, ein Erfordern von Reserven für Leitungen und andere Beschränkungen. Dies wird einige der geringwertigen zusätzlichen Arbeit, die zum Füttern des LEGACY-Systems erforderlich ist, verringern.
Schließlich organisiert und koordiniert der Anspruchsordner Informationen über Teilnehmer und Ausführende, so dass alle an einem Anspruch beteiligten Leute schnell und leicht identifiziert werden können.
Schlüsselbenutzer
Obwohl Anspruchsfachleute die primären Benutzer des Anspruchsordners sind, kann jeder Anspruchsfachmann den Anspruchsordner nutzen, um von einem Anspruch zu erfahren oder eine Erkundigung über einen Anspruch zu beantworten.
Komponentenfunktionalität
Da der Anspruchsordner der primäre Zugangspunkt für neue Ansprüche ist, muss er zum Einrichten neuer Ansprüche notwenige Informationen erfassen und dazu in der Lage sein, die Informationen an das LEGACY-System weiterzugeben. Sobald die Informationen weitergegeben sind, besitzt das LEGACY-System alle in beiden Systemen enthaltenen Informationen, und sie sind in dem Anspruchsordner nicht bearbeitbar. Der Anspruchsordner hat jedoch mehr Informationen als das, was in dem LEGACY-System enthalten ist, und ermöglicht es daher, gewisse Informationen einzutragen und zu modifizieren, wenn der Anspruch einmal zu dem LEGACY-System geschoben ist.
Der Anspruchsordner zerlegt einen Anspruch in verschiedene Ebenen, die den Versicherungsschein, den Versicherten, den Anspruch, die Anspruchsteller und die Linien des Anspruchstellers widerspiegeln. Jede Ebene hat einen strukturierten Satz von Informationen, die auf sie Anwendung finden. Die Anspruchsebene des Anspruchs hat zum Beispiel Informationen über den Anspruchsstatus, den Geschäftszweig und die Ausführenden. Eine Einzellinie hat Informationen, die den Linientyp, die Zuständigkeit und Sach- oder Fahrzeugschäden einschließen. Die Anspruchstellerebene enthält Kontaktinformationen sowie Verletzungsbeschreibungen.
Die Informationen auf jeder Ebene sind zu Organisationszwecken in Abschnitte gruppiert. Jede Ebene hat einen Detailabschnitt, der die grundlegenden Informationen über die Ebene aufweist.
Die Schlüsselebenen in dem Anspruchsordner und ihre Informationsabschnitte sind:

• Die Versicherungsscheinebene: Details und versichertes Auto für Autoansprüche, versichertes Eigentum für Sachansprüche und versicherte Yacht für Schiffsansprüche.
• Die Anspruchsebene: Details, Fakten von Schadensfall, Ereignisse, Haftung. Die Haftung wird als Teil der Verhandlungskomponente betrachtet und dort beschrieben.
• Die Teilnehmerebene: Details und Kontaktinformationen. Für Anspruchsteller werden zusätzliche Abschnitte gezeigt, um Ereignisse, Verletzung und Invaliditätsverwaltung anzuzeigen. Die Teilnehmerebene wird bei der Teilnehmerkomponente erörtert.
• Die Linienebene: Details, beschädigtes Fahrzeug für Fahrzeuglinien, beschädigtes Eigentum für Sachlinien, beschädigte Yacht für Schiffslinien, Ereignisse, Schäden und Verhandlung. Schäden und Verhandlung werden als Teil der Verhandlungskomponente betrachtet und dort beschrieben.

Ereignisse werden in dem Anspruchsordner ausgelöst, indem gewisse Aktionen wie ein Ändern einer Zuständigkeit, ein Identifizieren einer Verletzung oder ein Schließen einer Linie durchgeführt werden. Andere allgemeine Ereignisse werden in dem Ereignisabschnitt auf den meisten Ebenen ausgelöst, indem dasjenige angeklickt wird, das aufgetreten ist. Diese Ereignisse werden durch die Ereignisverarbeitungseinheit verarbeitet und könnten eine beliebige Anzahl von Antworten erzeugen. Bei einem Ausführungsbeispiel der vorliegenden Erfindung besteht die primäre Antwort darin, neue Aufgaben in dem Aufgabenassistent für einen Anspruch auszulösen.
Benutzerschnittstellen

• Anspruchsordner-UI
• Versicherungsscheinebene – Versicherungsscheindetailtabelle
• Versicherungsscheinebene – Versichertes-Fahrzeug-Tabelle
• Versicherungsscheinebene – Versichertes-Eigentum-Tabelle
• Versicherungsscheinebene – Versicherte-Yacht-Tabelle
• Anspruchsebene – Anspruchsdetailtabelle
• Anspruchsebene – Fakten-von-Schadensfall-Tabelle
• Anspruchsebene – Ereignistabelle
• Anspruchsebene – Haftungstabelle
• Linienebene – Liniendetailtabelle
• Linienebene – Beschädigtes-Eigentum-Tabelle
• Linienebene – Beschädigtes-Auto-Tabelle
• Linienebene – Beschädigte-Yacht-Tabelle
• Linienebene – Ereignistabelle
• Linienebene – Schadenstabelle
• Linienebene – Verhandlungstabelle
• Aufgabenassistent
• Dateinotizen
• Anspruchsverlauf
• Suche Aufgabenvorlage
• Suche nach Korrespondenz
• Finde Ansprüche
• Version 7
• Betrachte Dateiordner
• Drucke Etikett

ANSPRUCHSORDNERBAUM- UND -MENÜENTWURF
Anspruchsbaum
Der Anspruchsbaum in dem Anspruchsordnerfenster zerlegt den Anspruch abhängig von der spezifischen Zusammensetzung des Anspruchs in Versicherungsschein-, Versicherten-, Anspruchs-, Anspruchsteller- und Linienebenen.
Die Versicherungsscheinebene ist immer der erste Knoten in dem Anspruchsbaum und wird durch die Versicherungsscheinnummer identifiziert. Bevor die Versicherungsscheinnummer eingetragen ist, wird das Feld "Unbekannt" aufgelistet. Falls ein Anspruch uncodiert ist, wird das Feld als "Uncodiert" aufgelistet. Ein Auswählen der Versicherungsscheinebene bringt die Versicherungsscheinebenentabellen in dem Hauptteil des Anspruchsordners hoch.
Die Versichertenebene ist immer der zweite Knoten in dem Anspruchsbaum und wird durch den Namen des Versicherten identifiziert. Bevor der Versicherte identifiziert ist, wird das Feld als "Unbekannt" aufgelistet. Ein Auswählen der Versichertenebene bringt die Versicherter-Teilnehmer-Tabellen in dem Hauptteil des Anspruchsordners hoch. Nur ein Versicherter wird auf dieser Ebene als in den Versichertenscheinebenentabellen identifiziert aufgelistet, es können jedoch immer noch mehrere Versicherte hinzugefügt werden. Zusätzliche Versicherte werden in der Teilnehmerliste unter dem Anspruchsbaum gezeigt.
Die Anspruchsebene ist immer der dritte Knoten in dem Anspruchsbaum und wird durch die Anspruchsnummer identifiziert. Wenn die Anspruchsebene ausgewählt wird, erscheinen die Anspruchsebenentabellen in dem Hauptteil des Anspruchsordners.
Nach der Anspruchsebene werden alle Anspruchsteller mit ihren zugeordneten Linien in einem Hierarchieformat aufgelistet. Wenn ein Anspruchsteller hinzugefügt wird, wird ein Knoten zu dem Baum hinzugefügt, und das den Anspruchsteller identifizierende Feld wird als "Unbekannt" aufgelistet. Sobald ein Teilnehmer identifiziert worden ist, parteiisch oder Kunde, wird der Name des Anspruchstellers auf der Ebene aufgelistet. Wenn die Ebene ausgewählt wird, werden die Teilnehmerebenentabellen für den Anspruchsteller in dem Hauptteil des Anspruchsordners gezeigt.
Linienebenen werden durch ihren Linientyp identifiziert. Bevor ein Linientyp ausgewählt ist, wird die Linienebene als "Unbekannt" aufgelistet. Wenn eine Linienebene ausgewählt wird, werden die Linienebenentabellen für die spezifische Linie in dem Hauptteil des Anspruchsordners gezeigt.
Es sind mehrere Dinge vorhanden, die den Anspruchsbaum verändern können, wenn er einmal eingerichtet ist. Erstens wird dann, wenn ein Anspruchsteller oder eine Linie gelöscht wird, er oder sie aus dem Anspruchsbaum entfernt. Ein Anspruch, der irrtümlicherweise markiert wird, ändert das Aussehen der Ebenen nicht. Zweitens werden der Anspruch, der Anspruchsteller und die Linienebenen abhängig davon, ob sie zu V7 geschoben werden oder nicht, durch verschiedene Symbole identifiziert. Drittens wird dann, wenn eine Linie oder ein Anspruchsteller ausgeglichen ist, sie oder er derart identifiziert.
Teilnehmerliste
Das Teilnehmerlistenfeld enthält alle die Nichtanspruchsteller- und Nichtversicherten-Teilnehmer an dem Anspruch. (Anspruchsteller und Versicherte werden in dem Anspruchsbaum gezeigt und hier nicht wiederholt.) Teilnehmer werden mit ihrem Namen und ihrer Rolle gezeigt. Wenn ein Teilnehmer ausgewählt wird, werden die Teilnehmerebenentabellen in dem Anspruchsordner angezeigt.
Anspruchsordnermenüpunkte
Die Anspruchsordnermenüs enthalten die Aktionen, die ein Benutzer in dem Anspruchsordner durchführen müsste. Auf alle von ihnen kann durch eine Tastaturauswahl zugegriffen werden. Die Menüoptionen werden basierend auf dem Zustand des Anspruchsordners freigegeben oder gesperrt. Der Anspruchsordner kann sich für eine spezifische Ebene in dem Anspruchsbaum in einer Betrachtungsbetriebsart oder einer Bearbeitungsbetriebsart befinden. Wenn der Anspruchsordner sich in der Bearbeitungsbetriebsart befindet, sind die meisten Optionen gesperrt, bis der Benutzer seine Änderungen sichert und zu der Betrachtungsbetriebsart zurückgeführt wird. Das Freigeben/Sperren von Menüoptionen hängt auch davon ab, ob der Anspruch oder Abschnitte des Anspruchs zu V7 geschoben worden sind.
Anspruchsordnersymbolleiste

Die Symbolleiste stellt eine übliche Aktion, die ein Benutzer durchführt, dar, auf die leicht durch ein Anklicken des passenden Symbols zugegriffen werden kann. Es sind fünf Schaltflächengruppen auf der Anspruchsordnersymbolleiste vorhanden, die der Reihenfolge nach übliche Aktivitäten, ein Hinzufügen von neuen Elementen zu einem Anspruch, ein Starten von Dienstprogrammen, ein Durchführen von V7-Aktivitäten und ein Zugreifen auf Hilfsfunktionen darstellen. Das Freigeben/Sperren von Symbolleistenschaltflächen folgt der gleichen Logik wie für Menüpunkte. Fensterbeschreibung

Fensterdetails

CAR-Diagramm

Datenelemente

Übertragungspunkte

Anspruch	\| Sichern-Menüoption – Sichert alle Anspruchsebenendaten
Versicherungsschein	\| Sichern-Menüoption – Sichert alle Versicherungsebenendaten
Teilnehmer	\| Sichern-Menüoption – Sichert alle Teilnehmerebenendaten
Linie	\| Sichern-Menüoption – Sichert alle Linienebenendaten
Anspruch	\| Schließe-Anspruchsordner-Menüoption – Fordert Benutzer zum Sichern von Änderungen auf, falls in Bearbeitungsbetriebsart.

ANSPRUCHSVERLAUF
Definition
Der Anspruchsverlauf zeigt Informationen in einer Benutzerschnittstelle, die alle die einen Bestandteil bildenden Elemente einer Anspruchsdatei aufweisen soll. Die vier in der Komponente enthaltenen Typen von Verlauf sind gemäß gemeinsamen Indizierungskriterien wie Teilnehmer, Ausführender und Anspruchsphase durchsuchbar. Es kann ein Titelbericht (caption report) produziert werden, der den in einem Dokumentformat ausgewählten Verlauf zeigt.
Wert
Der Anspruchsverlauf versieht die Benutzer mit einer gemeinsamen Schnittstelle, durch die eine große Vielfalt von Informationen über den Anspruch zu betrachten ist. Er enthält den ganzen für einen Anspruch verfügbaren Verlauf und wird erweitert, indem Anspruchsfähigkeiten wie eine Erfassung von eingehender Post aufgebaut werden. Benutzer entwickeln anpassbare Ansichten des Verlaufs basierend auf irgendwelchen Kriterien, gemäß denen der Verlauf indiziert werden kann, und diese Berichte werden als anpassbare Word-Dokumente gesichert. Die Weise, auf die Verlaufsinformationen indiziert werden, stellt einen schnellen Zugriff auf einschlägige Daten, die zum Antworten auf eine Vielfalt von Anforderungen benötigt werden, bereit.
Schlüsselbenutzer
Alle Mitglieder der Anspruchsorganisation können den Anspruchsverlauf als einen Weg zum schnellen Sehen der ganzen bei einem Anspruch durchgeführten Aktivität verwenden. Dieser Nutzen steigert die Fähigkeit zum Lokalisieren von Schlüsselinformationen bezüglich eines beliebigen Anspruchs.
Komponentenfunktionalität
Der Anspruchsverlauf ist eine Komponente, die einen einfachen Prozess zum Wiedergewinnen des Verlaufs von den anderen Komponenten in dem System enthält. Er enthält selbst keine eigentlichen Daten. Selbst ein Betrachten eines Verlaufselements wird in dem Komponentenfenster, in dem das Element zuerst erfasst wurde, ausgeführt.
Der zweite Schlüsselprozess des Anspruchsverlaufs besteht darin, einen Titelbericht von allen Verlaufselementen gemäß den Elementen, die der Benutzer aufnehmen möchte, zu produzieren.
Es werden zwei Benutzerschnittstellen für diese Komponente benötigt, die den vorstehenden zwei Schlüsselfunktionen entsprechen:

• Anspruchsverlaufssuche: Dieses Fenster nutzt die Anspruchsphasen-, Teilnehmer-, Ausführenden- und Verlaufstypfelder in jedem Verlaufsdatensatz, um dem Benutzer dabei zu helfen, die Suche nach einem spezifischen Verlauf einzugrenzen.
• Titelbericht: Dieser Bericht verwendet die Funktionalität von Word zum Produzieren eines Berichts über jedes Verlaufselement, das der Benutzer sehen möchte, und sein zugeordnetes Detail. Da der Bericht in Word produziert wird, kann er gemäß vielen verschiedenen Bedürfnissen vollständig angepasst werden.

Benutzerschnittstellen

• Anspruchsverlaufssuche
• Titelbericht (Word-Dokument, nicht UI-Entwurf)

FORMULARE UND KORRESPONDENZ
Definition
Die Komponente Formulare & Korrespondenz unterstützt eine interne und externe Anspruchskommunikation und -dokumentation quer über alle Teile des Anspruchshandhabungsprozesses.
Die Funktion Formulare & Korrespondenz – Erzeuge Korrespondenz stellt die Fähigkeit bereit, unter Verwendung verschiedener Suchkriterien nach einer Vorlage zu suchen, eine Vorlage zur Verwendung auszuwählen und daraufhin Anspruchsdaten wirksam in die ausgewählte Vorlage einzusetzen.
Die Funktion Formulare & Korrespondenz – Vorlagenwartung ist ein Werkzeug für den Bibliothekar zum Erzeugen, Löschen und Aktualisieren von Korrespondenzvorlagen und ihren zugeordneten Kriterien.
Einige durch Formulare & Korrespondenz unterstützte spezifische Prozesse sind:

• Über Ansprüche berichten
– bei erster Mitteilung des Schadensfalls an staatliche/bundesstaatliche Dienststellen usw.
– interne Anforderungen von Informationen
• Teilnehmer beraten
• Teilnehmer kontaktieren
• Berechnungen durchführen
• Korrespondenz für Ansprüche oder Nichtansprüche erzeugen

Wert
Die Formular- und Korrespondenzkomponente unterstützt den Benutzer bei einem Erzeugen einer Dokumentation.
Ein wirksames Eintragen von Informationen aus dem Anspruch direkt in eine Korrespondenz verringert das Ausmaß des zum Erzeugen von Formularen und Briefen ausgeführten Tippens und Diktierens. Die für die Vorlagen verfügbaren typischen Daten sollten einschließen: Autor, Adressat, Anspruchsnummer, Datum des Schadensfalls, Versichertenname, Versicherungsscheinnummer usw. Ein Bibliothekar fügt standardisierte Formulare und Briefe in logischen Gruppierungen, die für die ganze Firma verfügbar gemacht werden, hinzu und wartet sie.
Schlüsselbenutzer
Anspruchsangestellte sind die primären Benutzer der Formular- und Korrespondenzkomponente, aber sie kann durch jeden, der Zugriff auf das System hat, zum Erzeugen von Dokumenten unter Verwendung von vorhandenen Vorlagen verwendet werden.
Bibliothekare für Formulare und Korrespondenz verwenden das System zum Erzeugen, Aktualisieren oder Entfernen von Vorlagen.
Komponentenfunktionalität
Formulare und Korrespondenz – Erzeuge Korrespondenz

1. Basierend auf Suchkriterien nach einer Vorlage suchen.
2. Unter Verwendung von Anspruchsdaten eine Korrespondenz aus einer Vorlage erzeugen.
3. Ohne eine Verwendung von Anspruchsdaten eine Korrespondenz aus einer Vorlage erzeugen.
4. Die Kriterien für eine ausgewählte Vorlage betrachten.
5. Die Microsoft-Word-Vorlage betrachten, bevor irgendwelche Daten wirksam eingesetzt werden.

Formulare und Korrespondenz – Vorlagenwartung

1. Basierend auf Suchkriterien nach einer Vorlage suchen.
2. Korespondenzvorlagen und ihre Kriterien erzeugen, duplizieren, bearbeiten und löschen.
3. Neu erzeugte/bearbeitete Vorlagen intern testen und genehmigen.
4.Word-Vorlagen für NAN-Verteilung richtig kopieren.

Benutzerschnittstellen

• Nach Korrespondenz suchen
• Korrespondenzdetails
• Felder zuordnen
• Korrespondenzsuche warten
• Korrespondenzvorlageninformationen – Detailtabelle
• Korrespondenzvorlageninformationen – Kriterientabelle
• Microsoft Word

DATEINOTIZEN
Definition
Dateinotizen erfassen die Textinformationen, die nicht als Teil einer Anspruchsdatenerfassung in diskreten Datenelementen gesammelt werden können. Sie sind primär ein Dokumentationswerkzeug, aber werden auch zur internen Kommunikation zwischen Anspruchsfachleuten verwendet.
Benutzer können die Notizen nach dem Teilnehmer oder der Anspruchsphase (ärztliche Untersuchung, Untersuchung, Deckung usw.) sortieren, um eine rasche Wiedergewinnung und Organisation dieser Textinformationen zu ermöglichen.
Wert
Dateinotizen beschleunigen die Wiedergewinnung von und Berichterstattung über Anspruchinformationen. Ein Dateinotizensuchprogramm mit mehreren Indizierungskriterien versieht Anspruchsfachleute und Vorgesetzte mit der Fähigkeit zum schnellen Finden einer über eine spezielle Person oder ein spezielles Thema geschriebenen Dateinotiz. Das Dateinotizenwerkzeug nutzt moderne Textverarbeitungsfähigkeiten, die Eintragungen beschleunigen, Fehler verringern und es ermöglichen, wichtige Informationen hervorzuheben. Überdies erleichtert die Kategorisierungs- und Schlüsselfeldsuche den Prozess des Findens und Kopierens von Dateinotizen. Schließlich verbessern Dateinotizen die Kommunikation, da sie zwischen denjenigen, die an einem Verwalten des Anspruchs beteiligt sind, hin- und hergesendet werden können.
Schlüsselbenutzer
Alle Mitglieder der Anspruchsorganisation können Dateinotizen nutzen. Externe Parteien können über RMS als allgemein markierte Dateinotizen betrachten. Dieses Dienstprogramm steigert die Fähigkeit zum Lokalisieren von Schlüsselinformationen bezüglich eines Anspruchs. Jeder, der mehr über einen Anspruch erfahren möchte oder Informationen über einen Anspruch aufzeichnen möchte, nutzt das Dateinotizenwerkzeug.
Komponentenfunktionalität
Das Durchsuchen von Dateinotizen ist als Teil der Anspruchsverlaufskomponente, die es dem Benutzer ermöglicht, die Verlaufselemente einer Anspruchsdatei einschließlich Aufgaben, Briefen und bedeutsamen Anspruchsänderungsereignissen zu durchsuchen, enthalten.
Die Benutzerschnittstellen, die für diese Komponente benötigt werden, sind:

• Die Dateinotizensuche (Teil der Anspruchsverlaufskomponente): Dieses Fenster nutzt das Anspruchsphasenfeld in dem Dateinotizendatensatz, um dem Benutzer dabei zu helfen, die Suche nach spezifischen Dateinotizen einzugrenzen. Ferner ermöglicht es Benutzern, alle Dateinotizen, die bestimmte Kriterien erfüllen, in einem Berichtsstilformat zu betrachten.
• Dateinotizeneintragung: Das zum Aufzeichnen der Dateinotiz verwendete Fenster. Es bettet ein Textverarbeitungssystem ein und stellt die Fähigkeit bereit, zu kategorisieren, eine Notiz als Firma (privat) gegen allgemein (öffentlich) anzugeben, die Notiz als einen Entwurf oder eine endgültige Ausfertigung zu sichern und die Notiz zu einer anderen Person zu senden.

Benutzerschnittstellen

• Dateinotizen
• Entwurfsdateinotizdurchsicht
• Teilnehmersuche
• Ausführendensuche

ADRESSBUCH
Definition
Das Adressbuch ist die Schnittstelle zwischen dem Anspruchssystem und der Kundendatenbank. Die Kundenanwendung ist eine neue Komponente, die zum Verfolgen von Leuten oder Organisationen, die aus irgendeinem Grund mit VERTRAUEN bzw. RELIANCE interagieren, entworfen ist, aber Ansprüche sind am wahrscheinlichsten die erste Anwendung, die einen Kunden verwendet. Auf das Adressbuch wird direkt von dem Desktop und von dem Anspruchsordner zugegriffen.
Das Adressbuch wird mehreren Bedürfnissen in der Anspruchsorganisation gerecht. Obwohl seine primäre Funktion darin besteht, das Hinzufügen von Teilnehmern zu einem Anspruch zu unterstützen, fungiert es als ein Pfad zu der Kundendatenbank zum Ausfindigmachen von vorhandenen Teilnehmern und Hinzufügen von neuen Leuten oder Organisationen zu der Firmendatenbank.
Die Kundendatenbank hält Informationen über Namen, Adressen, Telefonnummern und andere Informationen, die immer bei einer Person oder Organisation Anwendung finden, ganz egal welche Rolle sie bei einem Anspruch spielt.
Wert
Das Adressbuch stellt eine gemeinsame Definition von Leuten oder Organisationen bereit, die mit RELIANCE interagieren, und stellt daher ein sehr viel effizienteres Mittel zum Erfassen dieser Informationen bereit. Jeder Kundendatenbankeintrag stellt die Fähigkeit zum Verknüpfen einer Person oder Organisation mit allen den verschiedenen Rollen, die sie quer über die Organisation spielt, bereit und macht daher ein Wiedergewinnen von Informationen auf einer Kunde-für-Kunde-Grundlage leicht und schnell.
Dadurch, dass man ein gemeinsames Adressbuch hat, sind viele Vorteile für RELIANCE vorhanden. Informationen über Leute und Organisationen werden in anderen Aktivitäten wie freigegebenen Aufgaben, die Telefonnummern eines Kunden nachschlagen, wenn ein Telefongespräch geführt werden muss, wirksam eingesetzt. Informationen, die in der Vergangenheit redundant gespeichert worden sind, können einmal eingetragen und wieder verwendet werden. Sobald alle Bereiche von RELIANCE die Kundenanwendung verwenden, können verschiedene Bereiche der Firma Definitionen von Einzelpersonen und Organisationen gemeinsam nutzen.
Komponentenfunktionalität
Das Adressbuch ermöglicht es Benutzern, Datensätze aus der Kundendatenbank hinzuzufügen, zu bearbeiten und zu löschen. Sie stellt auch eine robuste Suchmöglichkeit einschließlich phonetischer Namenssuchen zum Finden von in der Kundendatenbank enthaltenen Leuten bereit.
Es sind zwei primäre Benutzerschnittstellen für das Adressbuch vorhanden:

• Adressbucheintrag finden – Dies ist ein Suchfenster, das es einem Benutzer ermöglicht, unter Verwendung von Namen, Adressen, Telefonnummern und anderen Identifizierungen Datensätze in der Kundendatenbank zu finden. Aus diesem Fenster können spezifische Datensätze ausgewählt und Ansprüchen als Teilnehmer beigefügt werden.
• Adressbucheintrag warten – Dieses Fenster ermöglicht es Benutzern, Informationen über Kunden hinzuzufügen oder zu bearbeiten, indem ihre Namen, Adressen, Telefonnummern, E-Mail-Informationen und Identifizierungsnummern wie eine SSN oder TIN angegeben werden.

Das Adressbuch wird gleichzeitig mit der Kundenanwendung erzeugt, um sich zu vergewissern, dass ein konsistenter Entwurfansatz befolgt wird.
Schlüsselbenutzer
Alle Mitglieder der Anspruchsorganisation verwenden das Adressbuch zum Nachschlagen von Informationen über Leute und Organisationen in der Kundendatenbank. Diejenigen, die Ansprüche einrichten und handhaben, verwenden das Adressbuch zum Identifizieren von Teilnehmern.
Benutzerschnittstellen

• Kunden finden
• Kunden warten

INDEX
Definition
Die Index- oder Anspruchssuchkomponente stellt die Fähigkeit zum Lokalisieren von Ansprüchen in dem System unter Verwendung von verschiedenen Suchkriterien bereit. Die Kriterien decken eine breitere Vielfalt von Suchfähigkeiten als heutzutage vorhanden sind ab, einschließlich Anspruchsausführenden, Teilnehmern, phonetischen Namenssuchen, Adressen, Rollen, Geschäftsstellen und Geschäftszweigen, aber nicht darauf begrenzt. Die Suchergebnisse zeigen ausgewählte Anspruchs-, Teilnehmer- und Ausführendendaten an, um bei einem Identifizieren jedes Anspruchs zu helfen.
Die Indexkomponente ermöglicht auch eine leichte Navigation zu verschiedenen Anspruchskomponenten wie dem Anspruchsordner, sobald ein Anspruch identifiziert worden ist. Es kann von dem Desktop und von jedem offenen Anspruchsordner auf sie zugegriffen werden.
Die Indexkomponente ist zum Unterstützen von mehreren Geschäftsprozessen in der Anspruchsorganisation entworfen. Ihre Funktionen sind entscheidend für ein Verbessern der Anspruchspersonalproduktivität und des Kundendienstes in den folgenden Bereichen:
• Passende Post finden
Die Fähigkeiten der Indexsuche erleichtern es, den Anspruch, zu dem ein Poststück gehört, basierend auf zum Identifizieren von Ansprüchen in Formularen, Korrespondenz und Rechnungen verwendeten Kriterien zu identifizieren. Die Ausführenden für einen Anspruch können auch zu Postleitzwecken identifiziert werden.
• Telefonische Erkundigungen
Dieses Fenster ist der primäre Punkt zum Handhaben von eingehenden telefonischen Erkundigungen nach einem beliebigen Anspruch. Benutzer können Ansprüche schnell finden, ohne dem Anrufer Anforderungen von zusätzlichen Informationen aufzubürden.
• Doppelte Ansprüche
Vor einem Einrichten von neuen Ansprüchen können Überprüfungen ausgeführt werden, um sicherzustellen, dass der Anspruch nicht bereits in das System eingetragen worden ist. Die zusätzlichen Suchfähigkeiten verschaffen eine größere Gewissheit, dass doppelte Ansprüche nicht eingetragen werden. Dies verringert den Bedarf an einem Löschen oder Vereinigen von Anspruchsdatensätzen.
• Betrugsidentifizierung
Da Ansprüche leicht nach Teilnehmer und anderen Kriterien durchsucht werden können, können Betrugsfragen leichter untersucht werden. Dies ist jedoch nicht der primäre Zweck dieser Komponente.
Wert
Der Index verringert die zum Finden von vorhandenen Ansprüchen erforderliche Zeit und verringert auch eine potentielle Nacharbeit daraus, dass Ansprüche nicht gefunden werden, wenn sie für ein Finden von passender Post oder Überprüfungen hinsichtlich Doppeln benötigt werden.
Schlüsselbenutzer
Anspruchsangestellte sind die primären Benutzer des Indexfensters, aber es kann durch jeden, der Zugriff auf das System hat, zum Zugreifen auf Ansprüche, ohne sich Verfolgungsnummern einprägen zu müssen, verwendet werden.
Komponentenfunktionalität
Der Index ist primär eine robuste Sucheinheit, die schnell und effizient nach Ansprüchen sucht. Er ist keine Komponente, die ihre eigenen Daten speichert, da er primär darauf konzentriert ist, Benutzer schneller und direkter auf Anspruchsdaten hinzuweisen.
Der Index besteht aus einem Suchfenster, das das Format von allen anderen Suchfenstern in dem System befolgt.
Benutzerschnittstellen

• Ansprüche finden

VERLETZUNG
Definition
Die Verletzungskomponente erfasst Versionen der Verletzungen eines Anspruchstellers, während sie fortschreiten. Dieses Fenster erfasst Verletzungsinformationen in der Form von diskreten Datenfeldern, was den Bedarf an Freiformtextdateinotizen verringert. Das Erfassen von Daten anstelle von Text ermöglicht es, die Verletzung genau zu verfolgen und schnell zu berichten. Die Daten können auch als Rückmeldungsstatistiken dienen, das heißt zum Aufbauen von besten Anspruchspraktiken und bei der Risikoauswahl. Das bevorzugte Verfahren zum Identifizieren und Dokumentieren von Verletzungen ist der ICD-9-Code. Der Benutzer kann unter Verwendung von Deskriptoren oder Nummern den ICD-9-Code eintragen oder nach ihm suchen.
Wert
Daten über jede Verletzung werden in einem konsistenten, zugänglichen Format erfasst und zusammengefasst, was ein Aufzeichnen und Durchsehen des Falls erheblich weniger zeitaufwändig und organisierter macht, was es dem Schadenssachverständigen ermöglicht, sich auf gewünschte Resultate zu konzentrieren. Dieser "Schnappschuss" des derzeitigen Status und Verlaufs einer Verletzung erleichtern ein Übergeben oder Dateitransfers zwischen Anspruchsfachleuten sehr. Zusätzlich ermöglicht die Erfassung in einem diskreten Datenfeld die Verwendung von Ereignissen zum Identifizieren von Aktionspunkten in dem Lebenszyklus eines Anspruchs, der Verletzungen umfasst.
Schlüsselbenutzer
Alle Mitglieder der Anspruchsorganisation können die Verletzungskomponente nutzen. Diese Komponente steigert die Fähigkeit zum Lokalisieren und Zusammenfassen von Schlüsselinformationen bezüglich einer Verletzung.
Komponentenfunktionalität
Die Verletzung ist ein Aspekt von Teilnehmerinformationen, die sich auf die Anspruchstellerteilnehmer an dem Anspruch beziehen. Die Teilnehmerkomponente bringt Kunden zu allen anderen anspruchsbezogenen Einheiten in Beziehung. Informationen über Verletzungen werden zu Teilnehmerdatensätzen in Beziehung gebracht und bei den Teilnehmerebeneninformationen in dem Anspruchsordner angezeigt. Neue Einheiten werden benötigt, um eine Verletzungsdatenerfassung zu realisieren: eine Verletzungs- und ICD-9-Suche. Die Verletzungskomponente interagiert mit fünf anderen Komponenten: Anspruchsordner – enthält Invaliditätsverwaltungsdaten über einen Anspruchsteller; Teilnehmer – listet die mit dem Anspruch verbundenen Einzelpersonen auf; sowie Dateinotizen, Aufgabenassistent und die Ereignisverarbeitungseinheit. Die Verletzungskomponente verwendet auch Microsoft WORD zum Erzeugen eines formatierten Verlaufsverletzungsberichts für eine spezielle Einzelperson.
Die Benutzerschnittstellen, die für diese Komponente benötigt werden, sind:

• Verletzung: Dies ist das primäre Verletzungsfenster, das grundlegende Verletzungsberichtsdaten erfasst, einschließlich: der Quelle des Verletzungsberichts, dem Datum des Verletzungsberichts, einem Indikator des früheren medizinischen Verlaufs und daraufhin einer detaillierten Liste der mit dem Bericht verbundenen Verletzungen. Die detaillierte Liste weist diskrete Felder für die folgenden Daten auf: ICD-9-Code, Körperteil, Typ, Art, Ernst, Behandlung, Diagnostik, ein Freiformtextbeschreibungsfeld und einen Kausalbeziehungsindikator.
• ICD-9: Dies ist das Suchfenster zum Lokalisieren von ICD-9-Codes und zugeordneten Beschreibungen.
• Invaliditätsverwaltung: Dieses Fenster enthält eine Untermenge von Teilnehmerdatenfeldern, die eine wirkungsvollere Verletzungsverwaltung ermöglicht.

Benutzerschnittstellen

• Anspruchsordner – Teilnehmerebene – Verletzungstabelle
• ICD-9-Suchfenster
• Anspruchsordner – Teilnehmerebene – Invaliditätsverwaltungstabelle

VERHANDLUNG
Definition
Die 10 zeigt eine Veranschaulichung der Verhandlungskomponente eines Ausführungsbeispiels der vorliegenden Erfindung. Die Verhandlung stellt eine einzelne, strukturierte Vorlage, die durch unterstützende Ansichten ergänzt wird, bereit, um Ereignisse bezüglich einer Verhandlung zu erfassen. Die Verhandlungsschnittstelle 1000 erfasst Schlüsselelemente einer Verhandlung wie beispielsweise ein Abrechnungszielspektrum, derzeitige Forderungen und Angebote sowie unterstützende Stärken und gegnerische Behauptungen des Anspruchs. Verhandlungsinformationen werden in diskreten Datenelementen 1002 gesammelt, was die Fähigkeit zum Erzeugen von Ereignissen 1006 basierend auf Schlüsselattributen oder Änderungen bei einer Verhandlung ermöglicht. Diese Ereignisse 1006 werden daraufhin zu einer gemeinsamen Ereigniswarteschlange 1008 gesendet. Die Verhandlungskomponente 1000 ist mit der Dateinotizenkomponente 1004 gekoppelt, um eine zusätzliche Dokumentationsfähigkeit in einem nicht strukturierten Format bereitzustellen. Die Verhandlungsvorlage wird durch alle anderen in dem Anspruchsordner enthaltenen Daten unterstützt.
Wert
Daten über jeden Fall werden in einem konsistenten, zugänglichen Format zusammengefasst, was ein Aufzeichnen und Durchsehen des Falls erheblich weniger zeitraubend und organisierter macht, was es dem Schadenssachverständigen ermöglicht, sich auf eine Verhandlungsstrategie und gewünschte Resultate zu konzentrieren. Dieser "Schnappschuss" des derzeitigen Status erleichtert ein Übergeben oder Dateitransfers zwischen Anspruchsfachleuten sehr. Zusätzlich ermöglicht die Erfassung in einem diskreten Datenfeld die Verwendung von Ereignissen zum Identifizieren von Aktionspunkten bei einer Verhandlung.
Schlüsselbenutzer
Alle Mitglieder der Anspruchsorganisation können die Verhandlung nutzen. Diese Komponente steigert die Fähigkeit zum Lokalisieren und Zusammenfassen von Schlüsselinformationen bezüglich einer Verhandlung.
Komponentenfunktionalität
Die Verhandlung ist ein Typ von Lösungsaktivität, der Teil der Anspruchskomponente des Anspruchseinheitsmodells ist. Die Anspruchskomponente ist der zentrale Brennpunkt des Anspruchseinheitsmodells, da sie die wesentlichen Informationen über einen Anspruch enthält. Die Anspruchskomponente unterstützt die Kernanspruchsdatenerfassungsfunktionalität, Erste-Mitteilung-Prozesse und Lösungsaktivität für Ansprüche. Die Haupttypen/-klassen von Daten in der Anspruchskomponente sind: Anspruch, Anspruchsteller, Linie, Anspruchsverlauf, Lösungsaktivität, Reserveelement und Reserveelementänderung. Drei Einheiten werden zum Realisieren einer Verhandlung benötigt: Lösungsaktivität, Anspruch und Anspruchsverlauf. Es ist auch eine Interaktion zwischen der Verhandlungskomponente und den Aufgabenassistenten-, Dateinotizen- und Ereignisverarbeitungseinheitskomponenten vorhanden.
Die zur Verhandlung benötigten Benutzerschnittstellen sind:

• Verhandlung: Dieses Fenster erfasst Forderungs- und Angebotsdaten, einschließlich: Betrag, Datum, Typ und Betriebsart der Kommunikation. Das Zielabrechnungsspektrum, niedrigstes und höchstes, werden zusammen mit Stärken und Schwächen des Falls erfasst.

Unterstützende Benutzerschnittstellen, die ebenfalls Teil des Anspruchsordners sind, schließen ein:

• Haftung (Anspruchsebenentabelle): Dieses Fenster wird zum Dokumentieren von Haftungsfaktoren bei einem Auswerten und Bewerten eines Anspruchs verwendet. Die Haftungsfaktoren umfassen Prozent der Haftung für alle beteiligten Parteien; Form der Verhandlung, die für die Zuständigkeit ausschlaggebend ist; Haftungstheorien, die der Anspruchshandhaber für auf den Anspruch anwendbar hält. Wird vor einem Entwickeln einer Verhandlungsstrategie verwendet.
• Schäden (Linienebenentabelle): Dieses Fenster stellt die Fähigkeit zum Bewerten und Auswerten eines Anspruchs basierend auf erlittenen und erwarteten Schäden bereit. Wird vor einem Entwickeln einer Verhandlungsstrategie verwendet.

Benutzerschnittstellen

• Anspruchsordner – Linienebene – Verhandlungstabelle
• Anspruchsordner – Anspruchsebene – Haftungstabelle
• Anspruchsordner – Linienebene – Schadenstabelle

ORGANISATION
Definition
Die 11 zeigt ein Flussdiagramm der durch die Organisationskomponente gemäß einem Ausführungsbeispiel der vorliegenden Erfindung genutzten Operationen. Die Organisationskomponente 1100 ermöglicht es, gemeinsame Informationen für die Leute, die Arbeit an Ansprüchen durchführen, quer über alle Ansprüche, an denen sie arbeiten, zu speichern, zu durchsuchen und wieder zu verwenden.
Bei einem Ausführungsbeispiel der Organisationskomponente 1100 werden alle Angestelltendatensätze in einer gemeinsamen Datenbank 1102 gehalten, so dass sie den sich in einer Anspruchsdatenbank 1104 befindenden spezifischen Ansprüchen, an denen sie arbeiten, beigefügt werden können. Die gemeinsamen Informationen, die in dem Angestelltendatensatz gehalten werden, schließen Name, Ort, Telefon und ein paar minimale Informationen des organisatorischen Kontexts wie Geschäftsstelle oder Abteilung ein. Dies ist das zum Unterstützen des Verfolgens von Ausführenden bei Ansprüchen erforderliche Minimum. Die Angestellteninformationen 1102 werden daraufhin mit den Anspruchsinformationen 1104 verknüpft 1106, und die Datenbanken werden aktualisiert 1108. Sind die Angestellten 1102 mit den Ansprüchen 1104, an denen sie arbeiten, verknüpft worden, kann die Datenbank nach Angestelltem oder Anspruch durchsucht werden 1110.
Diese Version der Organisation kann jedoch derart erweitert werden, dass sie Organisationsbeziehungen (insbesondere ein Verfolgen, wo ein Angestellter in die Organisationsstruktur fällt), Gruppen von Einzelpersonen als Ausführende zur Anspruchszuweisung und eine Anspruchszuordnung in der Organisationsstruktur aufweist. Diese Fähigkeiten sollen eine beliebige Vorstellung von Fallbelastungsanalyse, Verwaltungsberichterstattung oder automatisierter Zuweisung, die enthalten sein müsste, unterstützen.
Wert
Durch ein Verfolgen von gemeinsamen Definitionen von Angestellten quer über Ansprüche werden Indizierungsfähigkeiten verbessert, und Ausführende bei Ansprüchen werden genau verfolgt.
Schlüsselbenutzer
Die primären Benutzer der Organisationsfähigkeiten sind das Verwaltungspersonal, das Ausführende einrichtet; so wie die Techniker, die verfolgen, wer an einem Anspruch arbeitet.
Komponentenfunktionalität
Der Entwurf des minimalen Bereichs der Organisationskomponente schließt ein Suchfenster zum Finden von Angestellten in der Organisation und ein Detailfenster zum Sehen von spezifischen Informationen über jeden Angestellten ein.
Benutzerschnittstellen

• Organisationseinheitssuche
• Organisationseinheit hinzufügen/bearbeiten

Teilnehmer
Die 12 zeigt eine Veranschaulichung der Teilnehmerkomponente gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Ein Teilnehmer 1200 stellt die Verknüpfung zwischen Ansprüchen und Einzelpersonen und Organisationen, die in der Kundendatenbank gespeichert sind und auf die durch das Adressbuch 1202 zugegriffen wird, bereit. Der Teilnehmer verknüpft Kunden mit Ansprüchen 1204, indem er die Rollen definiert, die sie spielen, zum Beispiel Anspruchsteller, Fahrer oder Arzt. Er verwendet die in dem Adressbuch 1202 enthaltenen Informationen wieder, so dass sie nicht für jeden Teilnehmer neu eingetragen werden müssen.
Die Teilnehmerkomponente ermöglicht es auch, Verknüpfungen 1206 zwischen einem Teilnehmer und verschiedenen Elementen in Ansprüchen auszubilden. Ein Arzt kann mit dem Anspruchsteller, den er behandelt, verknüpft werden, und ein Fahrer kann mit dem beschädigten Fahrzeug, das er gefahren hat, verknüpft werden.
Sobald ein Teilnehmer zu einem Anspruch hinzugefügt worden ist, können zusätzliche Informationen 1208, die für den Anspruch spezifisch sind, beigefügt werden. Diese Informationen umfassen Verletzung, Anstellung und viele andere Typen von Informationen, die spezifisch für die Rolle, die eine Person oder Organisation bei einem Anspruch spielt, sind.
Die durch den Teilnehmer 1200 primär unterstützten Geschäftsprozesse sind:
• Beteiligung an einem Anspruch aufzeichnen
Es ist eine grundlegende Datenerfassungsanforderung zum Verfolgen von Einzelpersonen und Organisationen, die an einem Anspruch beteiligt sind, vorhanden, und diese wird unter Verwendung des Teilnehmeransatzes am effizientesten ausgeführt.
• Rollenspezifische Informationen aufzeichnen
Das Adressbuch 1202 speichert Informationen, die quer über Ansprüche wieder verwendet werden können, aber die Teilnehmerkomponente 1200 muss die Informationen halten, die für eine Beteiligung einer Einzelperson oder Organisation an einem spezifischen Anspruch spezifisch sind.
• Kontakt mit Kunden aufnehmen
Da der Teilnehmer zurück an das gemeinsame Adressbuch 1202 anknüpft, können irgendwelche dort enthaltenen Kontaktinformationen schnell und leicht erhalten werden.
• Formulare und Korrespondenz 1210
Ein wirksames Einsetzen von Adressinformationen in Briefen stellt eine Effizienzbefähigung für alle Benutzer, die keine Namens- und Adressinformationen nachschlagen müssen, bereit.
• Verlaufsinformationen kategorisieren
Teilnehmer werden zum Kategorisieren von Verlaufselementen wie Aufgaben und Dateinotizen verwendet, so dass Informationen bezüglich eines einzelnen Teilnehmers an einem Anspruch leicht wiedergewonnen werden können.
• Anspruchsindizierung
Ein Beifügen von Teilnehmern zu einem Anspruch ermöglicht es der Indexkomponente, bei dem Verarbeiten von Anspruchserkundigungen wirkungsvoller zu sein.
Schlüsselbenutzer
Die primären Benutzer der Teilnehmerkomponenten 1200 sind diejenigen, die direkt an einem Verarbeiten von Ansprüchen arbeiten. Sie sind diejenigen, die die Teilnehmerbeziehungen warten.
Anspruchsfachleute, die sich mit Verletzungen befassen, verwenden die Teilnehmertabellen in dem Anspruchsordner, um für ein besseres Ergebnis bei dem Anspruch Verletzungen zu verfolgen und Invaliditäten zu verwalten.
Wert
Da die Teilnehmerkomponente 1200 nur danach trachtet, die Rollen, die Einzelpersonen und eine Organisation quer über alle Ansprüche spielen, zu definieren, ist kein redundanter Eintrag von Namens-, Adress- und Telefoninformationen vorhanden. Diese sind alle in dem Adressbuch 1202 gespeichert.
Die Anzahl von potentiellen Teilnehmerrollen, die definiert werden können, ist im Grunde genommen grenzenlos und daher erweiterbar, da die Einbindung von zusätzlichen Leuten und Organisationen erfasst werden muss.
Komponentenfunktionalität
Der größte Teil der Teilnehmerfunktionalität wird in dem Kontext des Anspruchsordners ausgeführt. Der Anspruchsordner enthält auf zwei Weisen Teilnehmerebenen. Zuerst einmal sind Anspruchsteller in dem Anspruchsbaum auf der linken Seite des Fensters gezeigt. Darunter sind andere Teilnehmer in einer Liste gezeigt. Ein Auswählen eines beliebigen Teilnehmers zeigt einen Satz von Teilnehmerinformationstabellen an, die die folgenden Informationen anzeigen:

• Teilnehmerdetails – grundlegende Informationen über die Rolle, die ein Teilnehmer bei einem Anspruch spielt, und alle die anderen Teilnehmer, die mit ihm verbunden sind.
• Kontaktinformationen – Informationen aus dem Adressbuch über Namen, Adressen und Telefonnummern.
• Verletzung – spezifische Informationen über die Natur von durch verletzte Anspruchsteller erlittenen Verletzungen.
• Invaliditätsverwaltung – Informationen über verletzte Anspruchsteller mit Invaliditäten.

Nur die ersten zwei Tabellen werden für alle Teilnehmer konsistent angezeigt. Andere Tabellen können basierend auf der Rolle und charakteristischen Merkmalen der Beteiligung eines Teilnehmers an einem Anspruch erscheinen.
Ein Hinzufügen oder Bearbeiten von Teilnehmerrolleninformationen wird tatsächlich durch das Suchfenster des Adressbuchs 1202 ausgeführt. Der Prozess ist so einfach wie ein Finden des Datensatzes des Adressbuchs 1202 für den vorgesehenen Teilnehmer und ein Bestimmen der Rolle, die der Teilnehmer bei dem Anspruch spielt. Sobald dies getan ist, wird der Teilnehmer in dem Anspruchsordner gezeigt, und zusätzliche Informationen können hinzugefügt werden.
Die Vorstellung von einem Teilnehmer ist ein generisches Konzept, das nicht allein für Ansprüche spezifisch ist. Es basiert auf einem Entwurfsmuster, das bei einem Aufbauen von zusätzlichen Anspruchsfähigkeiten erweitert werden kann. Eine beliebige Beteiligung einer Einzelperson oder einer Organisation kann auf diese Weise modelliert werden.
Benutzerschnittstellen

• Teilnehmerebene – Teilnehmerdetailtabelle
• Teilnehmerebene – Kontaktinformationstabelle
• Teilnehmerebene – Ereignistabelle
• Teilnehmerebene – Verletzungstabelle (Verletzungskomponente)
• Teilnehmerebene – Invaliditätsverwaltungstabelle (Verletzungskomponente)
• Teilnehmerliste betrachten

AUSFÜHRENDER
Definition
Die Ausführendenkomponente ermöglicht es, Organisationseinheiten (Einzelpersonen, Gruppen, Geschäftsstellen usw.) verschiedene Rollen bei einem Handhaben des Anspruchs von einem Bericht bis zu der Lösung zuzuweisen. Die Ausführendenkomponenten wird auf einer Anspruch-für-Anspruch-Grundlage genutzt.
Ein Ausführender ist als eine beliebige Einzelperson oder Gruppe definiert, die zugewiesen werden kann, um eine Rolle bei einem Anspruch zu erfüllen.
Die Ausführendenkomponente unterstützt die Zuweisungsprozesse in dem Anspruchshandhabungsprozess. Dies geht über die Zuweisung des Anspruchs bei FNOL hinaus. Diese Komponente ermöglicht ebenso die Zuweisung von Arbeit (Aufgaben).
Einige durch den Ausführenden unterstützte spezifische Prozesse sind:

• Ansprüche zuweisen Identifizierung von verschiedenen Rollen bei den Ansprüchen, um den Anspruch zuzuweisen (Anspruch einleiten – DC-Prozess-Arbeit)
• Hält Rollen und Beziehungen von Ausführenden in Ansprüchen
• Aufgaben zuweisen
• Neuzuweisungen
• Unterstützt Leite-Anspruch-ein-Prozess – Zuweisung
• Suchmechanismus für Angestellte, Geschäftsstellen
• Alle Ausführenden sollten in der Organisationskomponente sein
• Stellt Verlauf von Zuweisungen bereit

Wert
Die Ausführendenkomponente ermöglicht die Zuweisung von Rollen oder Aufgaben zu Einzelpersonen oder Gruppen. Die Daten über Ausführende befinden sich in einer gemeinsamen Ablage: der Organisationskomponente.
Die Ausführendenkomponente verringert die zum Finden von Angestellten, Teams oder einem beliebigen potentiellen Ausführenden erforderliche Zeit und stellt die Konsistenz von Daten sicher.
Schlüsselbenutzer
Die primären Benutzer der Ausführendenkomponente sind diejenigen, die direkt an einem Verarbeiten von Ansprüchen arbeiten. Sie sind diejenigen, die die Zuweisung von Rollen oder Aufgaben, die sich auf einen Anspruch beziehen, warten.
Komponentenfunktionalität
Die Ausführendenkomponente unterstützt eine Informationsfunktion und eine Zuweisungsfunktion.

1. Details für Ausführende (Angestellter, Geschäftsstelle, Einheit usw.) betrachten. Diese Details können Organisationseinheitsbeziehungen nahe legen, aber sie in keiner Weise definieren oder warten.
2. Alle einem Anspruch derzeit und während des Verlaufs zugewiesenen Ausführenden (schließt Einzelpersonen, Gruppen, Geschäftsstellen usw. ein) betrachten.
3. Ausführende einem Anspruch zuweisen – auf den Anspruchs-, Anspruchsteller- und Ergänzungsebenen (einschließlich Einzelpersonen, Geschäftsstelle, Gruppen, usw.).

Benutzerschnittstellen

• Ausführenden zuweisen
• Ausführendenrollen
• Ausführendenliste betrachten

AUFGABENASSISTENT
Definition
Der Aufgabenassistent ist der Grundstein der Arbeitsumgebung eines Anspruchsfachmanns. Er stellt Terminkalenderfunktionen auf einer Arbeitsschrittebene bereit, die die Verwaltung von komplexen Anspruchsereignissen ermöglichen. Er ermöglicht die konsistente Ausführung von besten Anspruchspraktiken durch ein Zusammensetzung und Neuzusammensetzen aller der Aufgaben, die für einen Anspruch durchgeführt werden müssen, basierend auf detaillierten charakteristischen Anspruchsmerkmalen. Diese charakteristischen Merkmale kommen aus Ausführungsbefolgungsanforderungen (regulatory compliance requirements), Kontodienstverpflichtungen (account servicing commitments) und besten Praktiken zum Handhaben aller Typen von Ansprüchen. Der Aufgabenassistent stellt auch Mechanismen bereit, die einen Teil der oder die ganze Arbeit bei einem Durchführen einer Aufgabe automatisieren, um dem Anspruchsfachmann bei einem Abschließen seiner oder ihrer Arbeit zu helfen. Sobald eine Aufgabe abgeschlossen ist, erzeugt der Aufgabenassistent einen Verlaufsdatensatz zum Dokumentieren der Aktionen des Anspruchshandhabers.
Der Aufgabenassistent ist ...

• Ein Verfahren zum Sicherstellen einer konsistenten Ausführung von Ausführungsanforderungen, Kontodienstverpflichtungen und besten Praktiken der Anspruchshandhabung
• Eine Quelle der automatisierten Hilfe für Anspruchsfachleute
• Ein organisationsweites Kommunikationswerkzeug in dem Kontext eines Anspruchs (es ersetzt nicht Lotus Notes)
• Ein Mechanismus zum Ausbilden einer Anspruchsstrategie als üblich und gemeinsamen Nutzen von Firmenerfahrung
• Eine Terminkalenderanwendung zum Verfolgen von Ansprüchen
• Ein Verlaufsverfolgungswerkzeug
• Ein Weg zum Gewinnen der Aufmerksamkeit eines Anspruchsfachmanns oder eines Teamführers
• Ein Mechanismus zum schnellen Ausbilden von Prozessänderungen bei der Organisation

In dem Aufgabenassistent haben Anspruchsfachleute die letzte Kontrolle zum Bestimmen, ob und wann Aufgaben abgeschlossen sein müssen. Sie haben auch die Fähigkeit zum Hinzufügen von Aufgaben zu der Liste, um Arbeit darzustellen, die sie tun und die nicht in Standarddefinitionen von Aufgaben in dem System widergespiegelt ist. Dies unterstützt eine Vision von dem Anspruchsfachmann als einem kenntnisreichen Arbeiter, der durch die Untersuchung, Auswertung und Verhandlung des besten möglichen Resultats hindurch die meiste von seiner oder ihrer Zeit auf ein erfolgreiches Ergebnis konzentriert verwendet.
Wert
Der Aufgabenassistent verringert die zum Handhaben eines Anspruchs erforderliche Zeit, indem er den Anspruchsfachmann mit der automatischen Planung der Anspruchsaktivität versieht. Er hilft dem Anspruchsfachmann dabei, für jeden Anspruch abgeschlossene Aufgaben nicht zu vergessen, durchzuführen und aufzuzeichnen. Abgeschlossene Aufgaben sind selbstdokumentierend und bleiben Teil des Anspruchsverlaufs.
Der Aufgabenassistent stellt auch die konsistente Handhabung von Ansprüchen überall in der Organisation sicher und kann auf diese Weise Unkosten und Schadensfallkosten deutlich beeinflussen. Überdies hilft er bei einem Sicherstellen der Ausführungsbefolgung und der Erfüllung von Kontozusagen. Er unterstützt die bei einem Handhaben von schwierigen Ansprüchen erforderliche Teamarbeit als einen Strukturkommunikationsmechanismus.
Die automatisierten Freigaben für Aufgaben verringern die Menge von Zeit, die Anspruchsfachleute für Aktivitäten mit geringer Wertschöpfung wie beispielsweise ein Schreiben von Korrespondenz verwenden müssen. Sie können daher eine größere Menge von Zeit für ein Untersuchen, Auswerten und Verhandeln jedes Anspruchs verwenden.
Schlüsselbenutzer
Während Anspruchsfachleute die primären Benutzer des Aufgabenassistenten sind, verwenden andere die Anwendung ebenso. Der ganze Anspruchsgeschäftsbereich nutzt den Aufgabenassistenten zum Strukturieren von Arbeit und Kommunizieren miteinander. Teamführer verwenden den Aufgabenassistenten zum Durchführen einer Dateidurchsicht und zum Führen der Arbeit des Anspruchsfachmanns. Verwaltungspersonal verwendet den Aufgabenassistenten als ein Mittel zum Empfangen von Arbeit und zum Kommunizieren des Abschlusses der Arbeit. Anspruchsfachleute verwenden den Aufgabenassistenten zum Abschließen von Arbeit und zum Anfordern von Hilfe von Teamführern und Anspruchsfachleuten eines Spezialgebiets.
Der Aufgabenassistent erfordert einen neuen Typ von Benutzer zum Einrichten und Warten der Vielfalt von Aufgaben, die erzeugt werden. Ein Aufgabenbibliothekar wartet die Aufgabenbibliothek, die die Liste aller der standardisierten Aufgaben quer über die Organisation enthält. Der Bibliothekar definiert Regeln, die bewirken, dass Aufgaben basierend auf charakteristischen Anspruchsmerkmalen, Daten, die definieren, wann Aufgaben fällig sind, und einer Aufgabenfreigabe durch andere Anwendungen in Aufgabenlisten platziert werden.
Komponentenfunktionalität
Die 13 zeigt ein Flussdiagramm der durch die Aufgabenassistentenkomponente der vorliegenden Erfindung genutzten Operationen. Die Verarbeitung von Aufgaben durch den Aufgabenassistenten umfasst den Lebenszyklus der Aufgabe von ihrer Erzeugung bis zu ihrem Abschluss oder ihrer Löschung. In einer ersten Operation 1300 stellt die Aufgabeneinheit Aufgaben für den Aufgabenassistenten bereit. In der zweiten Operation 1302 zeigt der Aufgabenassistent daraufhin die Liste von durch die Aufgabeneinheit bereitgestellten Aufgaben an. In der dritten Operation 1304 wird es dem Benutzer ermöglicht, Aufgaben hinzuzufügen und Aufgaben zu bearbeiten, die durch die Aufgabeneinheit bereitgestellt werden. Die vierte Operation 1306 tritt auf, während der Anspruch verarbeitet wird. Während der Anspruch verarbeitet wird, bestimmen der Benutzer und die Aufgabeneinheit, wann die verschiedenen Aufgaben abgeschlossen sind. Wenn Aufgaben abgeschlossen sind, tritt die fünfte Operation 1308 auf. In der fünften Operation 1308 wird ein Verlaufsdatensatz für irgendwelche Aufgaben, von denen bestimmt wird, dass sie abgeschlossen sind, erzeugt.
Die Schlüsselbenutzerschnittstellen für diese Komponente sind:

• Der Aufgabenassistent: Dies ist das Dienstprogramm, das die Besetzung, Ausführung und Verlaufsverfolgung von Aufgaben unterstützt. Es ermöglicht es Benutzern, Aufgaben durchzuführen, Aufgaben abzuschließen und Aufgaben zu entfernen, die automatisch hinzugefügt worden sind.
• Der Aufgabenarbeitsplan: Diese Benutzerschnittstelle ermöglicht es dem Benutzer, den Plan für einen spezifischen Anspruch strategisch zu entwickeln. Sie zeigt Aufgaben, die ihren jeweiligen Ebenen des Anspruchs einschließlich Linien, Teilnehmern und dem Anspruch selbst beigefügt sind.
• Aufgabenfreigabefenster: Es sind viele Fenster vorhanden, die hinzugefügt werden können, um eine Aufgabe mit anderen Anwendungen wie beispielsweise einer Telefonunterstützung, Formularen und Korrespondenz und Dateinotizen freizugeben. Die Anzahl von potentiellen Aufgabenfreigaben ist im Grunde genommen grenzenlos.
• Aufgabeneintragung: Ermöglicht es einem Benutzer, eine neue Aufgabe hinzuzufügen, die nicht automatisch zu der Aufgabenliste hinzugefügt wurde, um Situationen abzudecken, in denen der Anspruchshandhaber auszuführende Arbeit angeben möchte, die nicht durch die Standardaufgabendefinitionen in der Aufgabenbibliothek widergespiegelt wird.

Hinter der Funktion des Aufgabenassistenten wertet die Aufgabeneinheit kontinuierlich von anderen Komponenten gesendete Nachrichten aus und bestimmt basierend auf den durch den Aufgabenbibliothekar aufgestellten Regeln, welche Aufgaben bei dem Aufgabenassistenten besetzt werden sollten. Es werden Nachrichten zu dem Aufgabenassistenten gesendet, wenn etwas Bedeutsames bei einer anderen Komponente auftritt. Die Nachrichten enthalten die charakteristischen Merkmale, die die Aufgabeneinheit zum Auswerten benötigt, um die richtigen Aufgaben in der Aufgabenliste zu platzieren.
Benutzerschnittstellen

• Aufgabenassistent
• Aufgabe neu zuweisen
• Aufgaben bearbeiten/hinzufügen
• Aufgabe zurücksetzen
• Aufgabe irrtümlicherweise markieren
• Arbeitsplan aufbauen
• Teilnehmersuche
• Teilnehmertelefonnummer
• Telefonaufgabe
• Persönliches Profil
• Kontosuche
• Organisationssuche
• Ausführendensuche

EREIGNISVERARBEITUNGSEINHEIT/AUFGABENEINHEIT
Definition
Die 14 zeigt eine Veranschaulichung der Ereignisverarbeitungseinheit 1400 zusammen mit anderen Komponenten des Systems gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Die Ereignisverarbeitungseinheit 1400 arbeitet hinter den Kulissen aller Anspruchsanwendungen, um auf bedeutsame Ereignisse zu horchen, die in dem Leben von verschiedenen Einheiten in dem System wie Ansprüchen (aber potentiell noch viele andere wie in Zukunft Konten oder Versicherungsscheine) aufgetreten sind. Sie bestimmt, welches die Antwort auf jedes Ereignis sein sollte, und leitet sie zu der Systemkomponente, die sie verarbeiten wird. Die Ereignisverarbeitungseinheit ist für eine beliebige spezifische Einheit oder ein beliebiges spezifisches Ereignis in dem System vollständig generisch und ermöglicht daher eine auf einer beinahe grenzenlosen Anzahl von Ereignissen und Antworten, die definiert werden können, basierende Automatisierung.
Die 15 zeigt eine Veranschaulichung der Aufgabeneinheit 1404 gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Die Aufgabeneinheit 1404 verarbeitet den üblichsten Satz von Ereignisantworten, diejenigen, die basierend auf Ereignissen 1006, die aufgetreten sind, Aufgaben 1406 erzeugen müssen. Sie vergleicht die Aufgaben, die für das System definiert worden sind, mit einem Satz von Anspruchskriterien, um festzustellen, welche Aufgaben hinzugefügt werden sollten und welche Aufgaben nun als abgeschlossen markiert werden sollten.
Die einzige Schnittstelle, die der Benutzer zu diesen Komponenten sieht, ist die Aufgabenbibliothek 1500, die es Aufgabenbibliothekaren 1502 ermöglicht, die Aufgaben und die sie erzeugenden Regeln, die durch die Aufgabeneinheit 1404 verwendet werden, zu definieren. Das Arbeiten mit diesen Komponenten ist beinahe gänzlich eine durch Spezialisten, die die Komplexität der an einem Sicherstellen, dass Ereignisse 1006 und Aufgaben 1406 richtig gehandhabt werden, beteiligten Regeln verstehen, durchgeführte Funktion.
Die Ereignisverarbeitungseinheit 1400 verwaltet auch die Kommunikation und Datensynchronisation zwischen neuen Anspruchskomponenten und LEGACY-Anspruchssystemen. Dieser einzelne Berührungspunkt kapselt die komplexen Prozesse der Übersetzung und Mitteilung von Ereignissen zwischen den zwei Systemen wirkungsvoll ein.
Wert
Die automatisierte Bestimmung von Ereignisantworten stellt enorme Vorteile für Systembenutzer bereit, indem sie die Wartung, die sie zum Sicherstellen der richtigen Verfügung über Ansprüche durchführen müssen, verringert.
Benutzer lösen durch die Daten, die sie eintragen, und die Systemaktivitäten, die sie durchführen, Ereignisse aus, und das System antwortet automatisch mit passenden automatisierten Aktivitäten wie einem Erzeugen von Aufgaben.
Die in der Aufgabenbibliothek definierten Aufgabenerzeugungsregeln stellen eine äußerst flexible Definition von Aufgabenhandhabungsprozessen bereit, die nur durch die in dem System verfügbaren Daten, auf denen Aufgabenerzeugungsregeln basieren können, begrenzt wird. Prozessänderungen können durch Aufgabenbibliothekare schnell realisiert werden und durch den Aufgabenassistenten durchgeführt werden.
Schlüsselbenutzer
Obwohl das ganze Anspruchspersonal direkt einen Vorteil von der Funktion der Ereignisverarbeitungseinheit und des Aufgabenassistenten hat, steuern nur speziell trainierte Benutzer die Verarbeitung dieser Komponenten. Die Aufgabenbibliothekbenutzerschnittstelle verwendende Aufgabenbibliothekare handhaben den Prozess des Definierens von neuen Aufgaben und der Regeln, die sie in der Aufgabeneinheit auslösen.
Betriebspersonal, das sicherstellt, dass alle Ereignisse richtig verarbeitet werden und dass die passenden Systembetriebsmittel verfügbar sind, um die Durchsatzhandhabungsereignisverarbeitung zu verwalten.
Komponentenfunktionalität
Wie in der 14 gezeigt nutzt die Ereignisverarbeitungseinheit 1400 eine gemeinsame Warteschlange 208 von Ereignissen 1006, die durch eine beliebige Komponente 1402 des Systems besetzt werden, um zu identifizieren, welche Ereignisse aufgetreten sind. Durch ein Arbeiten mit dieser Warteschlange bestimmt die Ereignisverarbeitungseinheit die passende Antwort für ein Ereignis und stellt Informationen für andere Komponenten bereit, die sie verarbeiten müssen. Die Ereignisverarbeitungseinheit verarbeitet selbst keine Ereignisse und erhält eine klare Einkapselung von Systemverantwortlichkeiten aufrecht. Ein Ereignis, das Anspruchsdaten beeinflusst, wird zum Beispiel durch die Anspruchskomponente verarbeitet.
Die Aufgabeneinheit 1404 folgt einem Prozess des Auswertens von Ereignissen 1006, Bestimmens von charakteristischen Anspruchsmerkmalen und Vergleichens der charakteristischen Anspruchsmerkmale mit in der Aufgabenbibliothek 1500 definierten Aufgaben.
Die Schlüsselbenutzerschnittstelle für die Aufgabeneinheit 1404 ist die Aufgabenbibliothek 1500. Die Aufgabenbibliothek 1500 hält die Vorlagen, die die Felder und Werte, mit denen die Aufgaben aufgebaut werden, enthalten. Eine Aufgabenvorlage kann Anweisungen wie "When event = litigation AND live of business = commercial auto, then ..." enthalten. Vorlagen identifizieren auch, was das Fälligkeitsdatum einer Aufgabe sein sollte und wie die Aufgabe mit anderen Anwendungen freigegeben wird.
Benutzerschnittstellen

• Aufgabenvorlage suchen
• Auslösende Vorlagen suchen
• Aufgabenvorlagendetails

Während vorstehend verschiedene Ausführungsbeispiele beschrieben worden sind, ist es selbstverständlich, dass sie nur beispielhaft und nicht beschränkend präsentiert worden sind. Somit sollte der Bereich der Erfindung nicht durch irgendeines der vorstehend beschriebenen beispielhaften Ausführungsbeispiele beschränkt werden, sondern sollte nur gemäß den folgenden Patentansprüchen definiert werden.

Claims

Vorrichtung zum Betreiben von komponentenbasierter Software, die zum Auswählen von Aufgaben in der Lage ist, wobei die Vorrichtung einen Computer aufweist und umfasst: eine Datenkomponente (906), die den Computer zum Speichern, Wiedergewinnen und Manipulieren von Daten unter Nutzung einer Vielzahl von Funktionen veranlasst; und eine Clientkomponente, die aufweist: einen Clientkomponentenadapter (208), der den Computer zum Senden und Empfangen von Daten zu/von der Datenkomponente veranlasst; ein Geschäftsobjekt (207), das den Computer zum Bereitstellen eines Daten-Caches veranlasst und eine Logik zum Veranlassen des Computers zum Manipulieren der Daten aufweist; eine Benutzerschnittstellensteuerungseinrichtung (206), die den Computer zum Handhaben von durch einen Benutzer erzeugten Ereignissen unter Nutzung des Geschäftsobjekts (207) zum Speichern von Daten im Cache und des Clientkomponentenadapters (208) zum letztendlichen Persistentmachen von Daten in einer Datenablage (908) veranlasst, wobei die Clientkomponente den Computer dazu veranlasst, es einem Benutzer zu ermöglichen, durch einen Angestellten durchzuführende Aufgaben zu definieren, die beim Abschluss ein Ziel erreichen, es dem Benutzer zu ermöglichen, Regeln einzugeben, die vorschreiben, welche der Aufgaben basierend auf vorbestimmten benutzererzeugten Ereignissen ausgewählt werden sollte, zumindest ein Ereignis zu empfangen und die Aufgabe auszugeben und anzuzeigen, die basierend auf dem empfangenen Ereignis gemäß den benutzerdefinierten Regeln ausgewählt wird.
Vorrichtung nach Anspruch 1, wobei die Clientkomponente den Computer ferner zum Angeben, welche Aufgaben abgeschlossen sind, veranlasst.
Vorrichtung nach Anspruch 1, wobei das empfangene Ereignis von einer Ereigniswarteschlange bereitgestellt wird.
Vorrichtung nach Anspruch 3, wobei die Ereigniswarteschlange mit Ereignissen von anderen Komponenten eines Systems bestückt ist.
Vorrichtung nach Anspruch 3, wobei die Ereigniswarteschlange mit Ereignissen von anderen Anwendungen bestückt ist.
Vorrichtung nach Anspruch 1, wobei das Ziel versicherungsbezogen ist.
Vorrichtung nach Anspruch 1, wobei die ausgegebenen Aufgaben für einen Aufgabenassistenten bereitgestellt werden.
Vorrichtung nach einem der Ansprüche 1 bis 7, die ferner umfasst ein Benutzerschnittstellenformularcodesegment (204), das den Computer zum Sammeln von Daten aus einer Benutzereingabe veranlasst; und ein Clientkomponentenadaptercodesegment (208), das zum Senden von Daten zu einer Serverkomponente (222) eingerichtet ist; wobei die Benutzerschnittstellensteuerungseinrichtung (206) ein Benutzerschnittstellensteuerungseinrichtungscodesegment umfasst, das den Computer zum Handhaben von durch den mit dem Benutzerschnittstellenformularcodesegment (204) interagierenden Benutzer erzeugten Ereignissen zum Bereitstellen einer Validierung in einer Logikarbeitseinheit, die eine Logik zum Interagieren mit einem Geschäftsobjekt oder mehreren Geschäftsobjekten (207) enthält, zum Interagieren mit dem Clientkomponentenadapter (208), zum Hinzufügen, Wiedergewinnen, Modifizieren oder Löschen von Geschäftsobjekten (207) und zum Bereitstellen einer Schmutzzustandsmerkerverarbeitung zum Benachrichtigen eines Benutzers von einer Änderungsverarbeitung veranlasst.
Vorrichtung nach einem der Ansprüche 1 bis 8 zum Ermöglichen einer Kommunikation zwischen einer Vielzahl von Clients und einem Server zum Handhaben von Aufgaben, die umfasst: eine Clientkomponente oder mehrere Clientkomponenten, die in jedem Client enthalten ist oder sind, wobei jede Clientkomponente jedes Clients den Computer zum Kommunizieren und Manipulieren von Daten mit einem ersten Datentyp veranlasst; eine Serverkomponente oder mehrere Serverkomponenten (222), die den Computer zum Kommunizieren und Manipulieren von Daten mit einem zweiten Datentyp veranlasst oder veranlassen; und einen Clientkomponentenadapter oder mehrere Clientkomponentenadapter (208), der oder die in jedem Client enthalten ist oder sind und den Computer zum Übersetzen von Daten von der einen Clientkomponente oder den mehreren Clientkomponenten in den zweiten Datentyp, wenn Daten von dem Client zu dem Server kommuniziert werden, und ferner zum Übersetzen von Daten von der einen Serverkomponente oder den mehreren Serverkomponenten in den ersten Datentyp, wenn Daten von dem Server zu dem Client kommuniziert werden, veranlasst oder veranlassen.