DE60218189T2

DE60218189T2 - Datenverarbeitungssystem und verfahren zum impliziten einreichen ungesicherter daten für eine world-wide-anwendung

Info

Publication number: DE60218189T2
Application number: DE60218189T
Authority: DE
Inventors: John Hillsborough COKER; Anil San Jose MUKUNDAN
Original assignee: Siebel Systems Inc
Current assignee: Siebel Systems Inc
Priority date: 2001-09-29
Filing date: 2002-09-27
Publication date: 2007-11-08
Anticipated expiration: 2022-09-28
Also published as: US20030070000A1; JP2009043268A; US7953760B2; EP1430424A4; DE60218189D1; WO2003029923A2; WO2003029923A3; US20130312015A1; US8359335B2; EP1430424A2; JP2005516272A; US9262245B2; US20050131925A1; EP1430424B1; JP4842305B2; AU2002337779A1; ATE354137T1

Description

Für gewöhnlich müssen bei einer CRM-Implementierungsstrategie folgende Punkte berücksichtigt werden:

– Wissensmanagement (Knowledge Management): einer der wichtigsten Faktoren einer effektiven CRM-Implementierung sind die Erfassung von Informationen über einen Kunden, deren Analyse, gemeinsame Nutzung bzw. Weiterleitung und Verfolgung. Ebenfalls besonders bedeutend für die Nutzung von Wissen bzw. Erkenntnissen für einen Wettbewerbsvorteil ist es, dass Mitarbeiter wissen, welche Maßnahmen als Folge dieses Wissens ergriffen werden müssen.
– Datenbankkonsolidierung: ein weiterer wichtiger Aspekt einer effektiven und effizienten CRM-Läsung ist die Konsolidierung von Kundeninformationen bzw. Kundendaten in einer einzigen Datenbank sowie das Re-Engineering bzw. die Neugestaltung von Geschäftsprozessen rund um den Kunden. Das Ziel ist es, dass alle Interaktionen mit einem Kunden an einem Ort aufgezeichnet werden, um die Produktions-, Marketing-, Vertriebs- und Kundendienstmaßnahmen anzutreiben.
– Integration von Kanälen und Systemen: für eine CRM-Anwendung/Software ist es besonders wichtig, die Fähigkeit bereitzustellen, auf Kunden einheitlich bzw. verträglich und in hoher Qualität über den ausgewählten Kanal anzusprechen, ob über E-Mail, das Telefon, Web-basierte Benutzerschnittstellen, etc. Dies kann die nahtlose Integration verschiedener Kommunikationskanäle mit der Kunden- oder Unternehmensdatenbank erfordern. Ferner kann dies die Integration von CRM mit anderen Teilen der Geschäftssysteme und Anwendungen des Kunden erfordern.
– Technologie und Infrastruktur: zur Verbesserung des Kundendienstes kann eine CRM-Anwendung/Software verschiedene Tools aufweisen, um den Online-Kundendienst zu automatisieren und rationalisieren. Zum Beispiel kann ein Selbsthilfemodell für gewöhnlich unter Verwendung einer Kombination von Tools bzw. Werkzeugen implementiert werden (z.B. Wissensbasen mit einer intuitiven Suchfunktion, Agententechnologie oder automatisierte E-Mail-Funktion, etc.).

Im Allgemeinen sind E-Business-Anwendungen so gestaltet, dass sie es Organisationen ermöglichen, eine einzelne Quelle für Kundendaten bzw. Kundeninformationen zu erzeugen, die es leichter macht, über mehrere Kanäle an Kunden zu verkaufen, diesen Produkte und Dienstleistungen anzubieten, wobei es sich bei den Kanälen zum Beispiel um das Internet, Call Center, den Außendienst, Reseller bzw. Wiederverkäufer, den Einzelhandel und Händlernetze handeln kann. Hoch entwickelte E-Business-Anwendungen werden für gewöhnlich auf einer Komponenten-basierten Architektur aufgebaut und sind als Web-basiert gestaltet, und so dass sie verschiedene Arten von Kunden bzw. Clients auf mehreren IT-Plattformen unterstützen, darunter mobile Clients, ungeschlossene Clients, Thin Clients und Handheld-Clients, etc.
Im Zuge der zunehmenden Verbreitung des Internets in den letzten Jahren ist es wünschenswert, die Funktionalitäten der E-Business-Anwendungen in einer Web-basierten Umgebung bereitzustellen. Ferner ist es für E-Business-Anwendungen, die in einer Web-Basierten Umgebung arbeiten, wünschenswert, der Look-and-Feel von Desktop-basierten E-Business-Anwendungen beizubehalten, mit dem die Benutzer bereits vertraut sind.
Dokumente im World Wide Web (WWW) enthalten häufig Formulare mit für den Benutzer interaktiven Datenfeldern, über welche ein Benutzer Informationen bzw. Daten eingeben kann. Die Informationen umfassen für gewöhnlich alphanumerische Zeichnen. Um einen Eintrag in der Server-Datenbank zu speichern, klickt der Benutzer für gewöhnlich auf eine Schaltfläche mit der Bezeichnung "Speichern" oder "Senden". Für den Benutzer kann es zeitaufwändig, lästig und unbequem sein, die Schaftfläche "Speichern" oder "Senden" jedes Mal anklicken zu müssen, wenn der Benutzer einer Eintrag speichern möchte. Wenn sich de Benutzer abmeldet oder die Ansicht des Web-Browsers auf eine andere Webseite wechselt, bevor er die Informationen speichert, können die Informationen verloren gehen.
ZUSAMMENFASSUNG DER ERFINDUNG
Vorgesehen ist gemäß einem ersten Aspekt der vorliegenden Erfindung ein Verfahren zum impliziten erzwungenen Wegschreiben ungespeicherter Daten für eine World Wide Web-Anwendung gemäß dem gegenständlichen Anspruch 1.
Vorgesehen ist gemäß einem zweiten Aspekt der vorliegenden Erfindung ein computerlesbares Medium gemäß dem gegenständlichen Anspruch 17.
Vorgesehen ist gemäß einem dritten Aspekt der vorliegenden Erfindung ein Computerprogramm gemäß dem gegenständlichen Anspruch 18.
Weitere Ausführungsbeispiele der Erfindung sind in den Unteransprüchen enthalten.
In einem Ausführungsbeispiel umfasst die Erfindung eine World Wide Web-Anwendung mit einem Benutzer interaktiven Datensatz- bzw. Aufzeichnungsfeld. Das Datensatzfeld empfängt einen Datensatzfeldeintrag. Die Anwendung empfängt eine Kontextänderungsanforderung. Als Reaktion auf die Kontextänderungsanforderung übermittelt die Anwendung dynamisch den Datensatzfeldeintrag an einen Server, um in einer Datenbank gespeichert zu werden.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die Merkmale und Vorteile der vorliegenden Erfindung werden in Bezug auf die beigefügten Zeichnungen besser verständlich. In den Zeichnungen zeigen:
1 eine mehrschichtige Systemarchitektur, in der die Lehren der vorliegenden Erfindung implementiert sind;
2 ein Blockdiagramm eines Ausführungsbeispiels einer Systemkonfiguration, in der die Lehren der vorliegenden Erfindung implementiert sind;
3 ein Blockdiagramm einer weiteren logischen Darstellung einer mehrschichtigen Architektur, bei der Anwendungen gemäß den Lehren der vorliegenden Erfindung gestaltet werden können;
4 ein Blockdiagramm eines Ausführungsbeispiels eines Anwendungsrahmens, bei dem die Lehren der vorliegenden Erfindung implementiert werden;
5A einen beispielhaften Rahmen bzw. eine exemplarische Infrastruktur 500 zur Unterstützung eines interaktiven Web-Clients und eines mobilen Web-Clients aus 2;
5B eine alternative Ansicht des beispielhaften Rahmens oder der exemplarischen Infrastruktur aus 5A;
5C ein exemplarisches Ausführungsbeispiel eines Computersystems, das sich zum implizierten erzwungenen Wegschreiben (englisch: Committing) eines Updates bzw. einer Aktualisierung eignet;
6A eine beispielhafte Konfiguration, bei der Objekte des Browsers und durch den Objektmanager (OM) verwaltete Objekte sich in mehreren Computervorrichtungen befinden und in diesen arbeiten, einschließlich eines Clients und eines Servers;
6B eine beispielhafte Konfiguration, bei der Objekte des Browsers und durch den OM verwaltete Objekte sich in einer Computervorrichtung befinden und in dieser arbeiten,
7 ein Beispiel, wie das Paradigma des entfernten Prozeduraufrufs (RPC) eingesetzt werden kann, um ein Programm in Teile zu zerlegen, die auf separaten Computer- bzw. IT-Vorrichtungen ausgeführt werden können;
8 ein beispielhaftes Modell für die in Verbindung mit entfernten Prozeduraufrufen eingesetzte Ausführung;
9 allgemein eine beispielhafte Aufteilung von RPC-Anwendungscodesegmenten, RPC-Schnittstellen, Stubs und der RPC-Laufzeitbibliotheken in dem RPC-Client und dem RPC-Server;
10 allgemein beispielhaft das Marshalling und das Unmarshalling zwischen ASCII-Daten und EBCDIC-Daten;
11 allgemein exemplarische Rollen von RPC-Anwendungscodesegmenten, RPC-Schnittstellen, RPC-Stubs und RPC-Laufzeitbibliotheken während einem entfernten Prozeduraufruf;
12 allgemein eine Übersicht über einen exemplarischen Prozess 1200 des Aufbaus einer verteilten RPC-Anwendung;
13 allgemein die Verknüpfung der lokalen RPC-Laufzeitbibliothek und des aus dem Anwendungscode erzeugten Objektcodes;
14 allgemein einen beispielhaften Prozess der Kommunikation zwischen den Objekten auf Browser-Seite oder Client-Seite und Objekten auf Server-Seite, die in einer Konfiguration mit mehreren Vorrichtungen ausgeführt werden, wie dies in der Abbildung aus 6A dargestellt ist;
15 einen beispielhaften Prozess der Kommunikation, wobei das Applet der Browser-Seite das Verfahren direkt an dem Objekt JSSBusComp aufruft;
die 16, 17 und 18 Beispiele für entsprechende Symbolleisten, Anwendungsebenenmenüs und Applet-Ebenen-Menüs;
19 ein Flussdiagramm eines Ausführungsbeispiels eines Verfahrens bzw. Prozesses zur Erzeugung verschiedener Objekte, die für die Konfiguration und Ausführung der verschiedenen Befehle verwendet werden;
20 ein Flussdiagramm eines Ausführungsbeispiels eines Verfahrens zur Erzeugung eines Befehlsobjekts gemäß den Lehren der vorliegenden Erfindung;
21 ein Ausführungsbeispiel der Eigenschaften eines Befehlsobjekts gemäß den Lehren der vorliegenden Erfindung;
22 ein Flussdiagramm eines Ausführungsbeispiels eines Prozesses zum Erzeugen eines Symbolleistenobjekts gemäß den Lehren der vorliegenden Erfindung;
23 ein Ausführungsbeispiel der Eigenschaften eines Symbolleistenobjekts gemäß den Lehren der vorliegenden Erfindung;
24 ein Flussdiagramm eines Verfahrens zum Erzeugen eines Symbolleistenoptionsobjekts gemäß den Lehren der vorliegenden Erfindung;
25 ein Ausführungsbeispiel der Eigenschaften eines Symbolleistenoptionsobjekts gemäß den Lehren der vorliegenden Erfindung;
26 ein Flussdiagramm eines Ausführungsbeispiels eines Verfahrens zum Erzeugen eines Menüoptionsobjekts gemäß den Lehren der vorliegenden Erfindung;
27 ein Ausführungsbeispiel der Eigenschaften eines Menüoptionsobjekts gemäß den Lehren der vorliegenden Erfindung;
28 ein Flussdiagramm eines Ausführungsbeispiels eines Verfahrens zum Erzeugen eines Applet-Methoden-Menüoptionsobjekts gemäß den Lehren der vorliegenden Erfindung;
29 die Eigenschaften eines Applet-Methoden-Menüoptionsobjekts gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
30 ein Flussdiagramm eines Ausführungsbeispiels eines Verfahrens zum Erzeugen eines Klassenmethoden-Menüobjekts gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
31 die Eigenschaften einer Klassenmethoden-Menüoption gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
32 ein Diagramm der Beziehung zwischen Symbolleistenobjekten, Symbolleistenoptionsobjekten und Befehlsobjekten gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
33 ein Diagramm der Beziehung zwischen einem Menüobjekt, Menüoptionsobjekten und Befehlsobjekten;
34 ein Diagramm der Beziehung zwischen einem Applet-Ebenen-Menüobjekt, Applet-Methoden-Menüoptionsobjekten und Klassenmethoden-Menüoptionsobjekten;
35 ein Blockdiagramm eines Ausführungsbeispiels einer Systemkonfiguration 3500, bei der die Lehren der vorliegenden Erfindung implementiert werden können;
36 ein Flussdiagramm eines Verfahrens gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
37 ein Flussdiagramm eines Verfahrens gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
38 ein Blockdiagramm der Beziehung zwischen verschiedenen Objekten gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
39 ein Blockdiagramm einer logischen Struktur einer Geschäftskomponente gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
40 bestimmte Eigenschaften oder Attribute eines Geschäftskomponentenfelds gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
41 ein Flussdiagramm eines Ausführungsbeispiels eines Verfahrens gemäß den Lehren der vorliegenden Erfindung;
42 ein Blockdiagramm eines Ausführungsbeispiels einer Systemkonfiguration gemäß den Lehren der vorliegenden Erfindung;
43 ein Flussdiagramm eines Verfahrens gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
44 allgemein ein teilweises Blockdiagramm eines Rahmens oder einer Infrastruktur, der bzw. die in einer Konfiguration mit mehreren Vorrichtungen arbeitet, ähnlich der Konfiguration, die in 6A dargestellt und vorstehend in Bezug auf 6A beschrieben worden ist;
45 allgemein die Struktur eines beispielhaften Caches gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
46 allgemein eine Übersicht über ein beispielhaftes Verfahren zum Caching bzw. Cache-Speichern einer Anzeige gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
47 allgemein eine Übersicht über ein beispielhaftes Verfahren zum Umschalten zu einer Anzeige gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
48 ein beispielhaftes Flussdiagramm für ein Ausführungsbeispiel eines Verfahrens zum impliziten erzwungenen Wegschreiben einer Aktualisierung;
49 ein exemplarisches Ausführungsbeispiel der Anzeige; und
50 die Kontextänderung, wobei die Anzeige für ein neues Datensatzfeld ausgewählt wird.
GENAUE BESCHREIBUNG DER ERFINDUNG
Beschreiben werden ein Computer- bzw. IT-System, wobei ungespeicherte Daten für eine World Wide Web-Anwendung ("eine Web-Anwendung") implizit erzwungen an einen Sever weggeschrieben werden als Reaktion auf eine Kontextänderung. Der Benutzer muss dabei zum Beispiel nicht auf eine Schaltfläche Speichern klicken.
In der vorliegenden Beschreibung werden die Begriffe Senden bzw. Übertragen und Posten austauschbar verwendet. Ferner werden die Begriffe Speichern und erzwungen Wegschreiben austauschbar verwendet. Des Weiteren werden die Begriffe ungespeicherte Daten, Änderungen und Aktualisierungen austauschbar verwendet.
In der folgenden genauen Beschreibung sind zahlreiche besondere Einzelheiten ausgeführt, um ein umfassendes Verständnis der vorliegenden Erfindung zu vermitteln. Der Fachmann auf dem Gebiet der Erfindung erkennt jedoch, dass die vorliegende Erfindung auch ohne die besonderen Einzelheiten verstanden und ausgeführt werden kann.
I. Systemüberblick und Architektur insgesamt
In einem Ausführungsbeispiel kann ein System, in dem die Lehren der vorliegenden Erfindung implementiert sind, logisch als eine mehrschichtige Systemarchitektur strukturiert werden kann, wie dies in der Abbildung aus 1 dargestellt ist. In einem Ausführungsbeispiel stellt die logische mehrschichtige Architektur gemäß der Abbildung aus 1 eine Plattform für übliche Dienste für die Unterstützung der verschiedenen Anwendungen bereit. Zu diesen Diensten können eine Benutzerschnittstellenschicht 110, eine Objektmanagerschicht 120, eine Datenmanagerschicht 130 und eine Datenaustauschschicht 140 zählen.
In einem Ausführungsbeispiel kann die Benutzerschnittstellenschicht 110 die Applets, Ansichten, Diagramme und Bereichte, etc. bereitstellen, die einer oder mehreren Anwendungen zugeordnet sind. Diese verschiedenen Arten von Clients können herkömmliche angeschlossene bzw. verbundene Clients aufweisen, entfernte Clients, Thin Clients über ein Intraet, Java Thin Clients oder nicht Windows-basierte Betriebssysteme und HTML-Clients über das Internet, etc.
In einem Ausführungsbeispiel ist die Objektmanagersehicht 120 so gestaltet, dass eine oder mehrere Gruppen von Geschäftsrichtlinien oder Geschäftskonzepten verwaltet werden, die einer oder mehreren Anwendungen zugeordnet sind, und um die Schnittstelle zwischen der Benutzerschnittstellenschicht 110 und der Datenmanagerschicht 130 bereitzustellen. In einem Ausführungsbeispiel können die Geschäftsobjekte als konfigurierbare Softwaredarstellungen der verschiedenen Geschäftsrichtlinien oder -konzepte gestaltet werden, wie etwa als Konten, Kontakte, Gelegenheiten, Dienstanforderungen, Lösungen, etc.
In einem Ausführungsbeispiel ist die Datenmanagerschicht 130 so gestaltet, dass sie logische Ansichten der darunter liegenden bzw. zugrunde liegenden Daten verwaltet und es dem Objektmanager ermöglicht, unabhängig von den darunter liegenden Datenstrukturen oder Tabellen zu arbeiten, in denen Daten gespeichert werden. In einem Ausführungsbeispiel kann der Datenmanager 130 auch bestimmte Datenbankabfragefunktionen bereitstellen, wie etwa die Erzeugung einer strukturierten Abfragesprache (SQL) in Echtzeit für einen Zugriff auf die Daten. In einem Ausführungsbeispiel ist der Datenmanager 130 so gestaltet, dass er Objektdefinitionen in einer Ablagedatei 160 bearbeitet, welche das Datenbankschema definieren. In einem Ausführungsbeispiel stellen die Datenspeicherdienste 170 den Datenspeicher für das einer oder mehreren Anwendungen zugeordnete Datenmodell bereit.
In einem Ausführungsbeispiel ist die Datenaustauschschicht so gestaltet, dass sie die Interaktionen mit einer oder mehreren spezifischen Zieldatenbanken behandelt und die Schnittstelle zwischen der Datenmanagerschicht 130 und den darunter liegenden Datenquellen bereitstellt.
Die Abbildung aus 2 zeigt ein Blockdiagramm eines Ausführungsbeispiels einer Systemkonfiguration, bei der die Lehren der vorliegenden Erfindung implementiert werden.
In einem Ausführungsbeispiel ermöglicht es die mehrschichtige Systemarchitektur, dass sich eine oder mehrere Softwareebenen auf verschiedenen Geräten bzw. Maschinen befinden. In einem Ausführungsbeispiel können sich zum Beispiel die Benutzerschnittstelle bzw. die Bedienoberfläche, der Objektmanager und der Datenmanager alle auf den dedizierten Web-Clients befinden. Für andersartige Clients, wie etwa kabellose Clients (Wireless Clients) können sich in einem Ausführungsbeispiel der Objektmanager und der Datenmanager auf einem Systemserver befinden. Hiermit wird festgestellt, wie dies vom Fachmann auf dem Gebiet verstanden werden wird, dass die Systemkonfiguration aus der Abbildung aus 2a nur Zwecken der Veranschaulichung und Erläuterung dient und abhängig von den speziellen Implementierungen und Anwendungen der Lehren der vorliegenden Erfindung variieren kann.
In einem Ausführungsbeispiel kann die in 2 veranschaulichte Systemumbegung mehr als eine Datenbank 290 aufweisen. Eine oder mehr Teilgruppen der Datenbank 290 können durch einen Replikationsmanager erzeugt oder repliziert werden. Darüber hinaus können mobile Web-Clients zusätzliche entfernte Datenbanken (auch als lokale Datenbanken bezeichnet) aufweisen. Sofern die entfernten oder lokalen Datenbanken, die den mobilen Web-Clients zugeordnet sind, nicht als Nur-Lese-Datenbanken definiert sind, können die mobilen Web-Clients in einem Ausführungsbeispiel Daten lokal erzeugen und aktualisieren, die letztlich zu der primären Datenbank weitergeleitet werden, wenn jeder mobile Web-Client mit dem Systemserver synchronisiert wird.
In einem Ausführungsbeispiel ist die Datenbank 290 so gestaltet, dass sie verschiedenartige Daten speichert, einschließlich eines vordefinierten Datenschemas (z.B. Tabellenobjekte, Indexobjekte, etc.), Ablageobjekte (z.B. Geschäftsobjekte und -komponenten, Ansichtdefinitionen und Sichtbarkeitsregeln, etc.) sowie Benutzer- oder Kundendaten. In einem Ausführungsbeispiel können dedizierte Web-Clients und Serverkomponenten, einschließlich denen, die in Verbindung mit andersartigen Clients arbeiten, eine direkte Verbindung mit der Datenbank 290 herstellen und Änderungen in Echtzeit vornehmen. In einem Ausführungsbeispiel können mobile Web-Clients eine Teilmenge der Serverdaten zur lokalen Verwendung herunterladen und periodisch eine Synchronisierung mit der Server-Datenbank über den Systemserver vornehmen, um sowohl die lokale als auch die Server-Datenbank zu aktualisieren.
In einem Ausführungsbeispiel können verschiedene in der Datenbank 290 enthaltene Tabellen logisch nach den folgenden Typen bzw. Arten organisiert werden: Datentabellen, Schnittstellentabellen und Ablagetabellen, etc.
In einem Ausführungsbeispiel können Datentabellen zum Speichern der Geschäftsdaten, der Verwaltungsdaten, der Seed-Daten und der Transaktionsdaten sowie anderer Daten des Benutzers eingesetzt werden. In einem Ausführungsbeispiel können diese Datentabellen über die verschiedenen Anwendungen und Prozesse populiert und aktualisiert werden. In einem Ausführungsbeispiel können die Datentabellen die Basistabellen und die Schnittmengentabellen, etc. aufweisen. In einem Ausführungsbeispiel können die Basistabellen Spalten aufweisen, die durch die verschiedenen Anwendungen definiert und verwendet werden. In einem Ausführungsbeispiel sind die Basistabellen so gestaltet, dass sie die Spalten für eine Geschäftskomponente bereitstellen, die in der Tabelleneigenschaft der Geschäftskomponente spezifiziert sind. In einem Ausführungsbeispiel sind Schnittmengen- bzw. Kreuzungstabellen Tabellen, die eingesetzt werden, um eine Many-to-Many-Beziehung zwischen zwei Geschäftskomponenten zu implementieren. Sie können ferner Schnittmengen-Datenspalten speichern, die Informationen speichern, die jede Zuordnung betreffen. In einem Ausführungsbeispiel stellen Schnittmengentabellen die Datenstrukturen für Zuordnungs-Applets bereit.
In einem Ausführungsbeispiel werden Schnittstellentabellen eingesetzt, um eine Gruppe von Basistabellen zu einer einzigen Tabelle zu denormalisieren, mit der externe Programme eine Schnittstellenverbindung herstellen können. In einem Ausführungsbeispiel können sie als ein Zwischenspeicherbereich zum Exportieren und Importieren von Daten eingesetzt werden.
In einem Ausführungsbeispiel weisen Ablagetabellen die Objektdefinitionen auf, die eine oder mehrere Anwendungen in Bezug auf folgende Faktoren spezifizieren:

• die Konfiguration der Client-Anwendung
• die eingesetzte Abbildung (Mapping) zum Importieren und Exportieren von Daten
• Regeln für die Übertragung von Daten an mobile Clients.

In einem Ausführungsbeispiel handelt es sich bei dem Dateisystem 295 um ein über das Netzwerk zugreifbares bzw. zugängliches Verzeichnis, das sich auf einem Anwendungsserver befinden kann. In einem Ausführungsbeispiel speichert das Dateisystem 295 die physikalischen Dateien, die von den verschiedenen Anwendungen erzeugt worden sind, wie etwa Dateien, die durch Text-Editoren von Drittanbietern erstellt worden sind sowie andere Daten, die nicht in der Datenbank 290 gespeichert sind. In einem Ausführungsbeispiel können die in dem Dateisystem 295 gespeicherten physikalischen Dateien komprimiert und unter verschiedenen Benennungs- bzw. Bezeichnungskonventionen gespeichert werden. In einem Ausführungsbeispiel können dedizierte Web-Clients Dateien direkt aus und an das Dateisystem 295 lesen und schreiben. In einem Ausführungsbeispiel können mobile Web-Clients ein lokales Dateisystem aufweisen, das sie periodisch mit dem Server-basierten Dateisystem 290 synchronisieren. In einem Ausführungsbeispiel können andersartige Clients, wie etwa Wireless Clients und Web-Clients über den Systemserver auf das Dateisystem 290 zugreifen.
In einem Ausführungsbeispiel handelt es sich bei dem Enterprise-Server 250 um eine logische Gruppierung der Systemserver 255, die einen gemeinsamen Tabelleneigentümer oder eine Datenbank gemeinsam nutzen, auf einen gemeinsamen Gateway-Server zeigen und als Gruppe unter Verwendung des Server-Managers 260 administriert werden können. In einem Ausführungsbeispiel kann die Verbindung zu dem Gateway-Server über TCP/IP aufgebaut werden. In einem Ausführungsbeispiel kann der Enterprise-Server 250 effektiv bzw. wirksam durch den Einsatz von mehreren Systemservern 255 in dem Enterprise-Server 250 skaliert werden, wodurch ein hohes Maß an Skalierbarkeit in der mittleren Ebene (Tier) der Anwendungen bereitgestellt werden kann.
In einem Ausführungsbeispiel führt der Server 255 ein oder mehrere Serverprogramme aus. Er bearbeitet eingehende Verarbeitungsanforderungen und überwacht den Zustand aller Prozesse auf dem Server. In einem Ausführungsbeispiel sind Serverprogramme so gestaltet und konfiguriert, dass sie eine oder mehrere spezifische Funktionen oder Aufgaben ausführen, darunter das Importieren und Exportieren von Daten, das Konfigurieren der Datenbank, das Ausführen eines Workflows bzw. Arbeitsablaufs und die Prozessautomatisierung, die Verarbeitung zur Unterstützung mobiler Web-Clients für eine Synchronisierung und Replikation von Daten sowie das Durchsetzen von Geschäftsregeln, etc. In einem Ausführungsbeispiel kann es sich bei dem Server um einen NT Dienst bzw. Server (unter dem Windows NT Betriebssystem) oder einen Dämon (z.B. einen Shell-Prozess im Hintergrund) unter dem UNIX Betriebssystem handeln. In einem Ausführungsbeispiel unterstützt der Server 255 sowohl Mehrprozess- als auch Multithread-Komponenten und kann Komponenten in Batch-, Service- und interaktiven Modi betreiben.
In einem Ausführungsbeispiel ist der Server-Manager 260 als ein Hilfsprogramm (Utility) konfiguriert, das eine gemeinsame Steuerung, Administration und Überwachung über verschiedene Programme für die Server 255 und den Enterprise-Server 250 ermöglicht. In einem Ausführungsbeispiel kann der Server-Manager 260 eingesetzt werden, um die folgenden Aufgaben auszuführen: Starten, Stoppen, Anhalten und Wiederaufnahme der Server 255, Komponenten und Aufgaben; Statusüberwachung und Erfassung von Statistiken für mehrere Aufgaben, Komponenten und Server in einem Enterprise-Server; und Konfiguration des Enterprise-Servers, der einzelnen Komponenten der einzelnen Server und von Aufgaben, etc.
In einem Ausführungsbeispiel kann der Gateway-Server als logische Instanz konfiguriert werden, die als einzelner Eintrittspunkt für den Zugriff auf Server dient. In einem Ausführungsbeispiel kann er eingesetzt werden, um eine erhöhte Skalierbarkeit, eine verbesserte Lastverteilung und eine hohe Verfügbarkeit an dem Enterprise-Server bereitzustellen. In einem Ausführungsbeispiel kann der Gateway-Server einen Namens-Server (Name Server) und eine Verbindungsmakelkomponente aufweisen. In einem Ausführungsbeispiel ist der Name Server so konfiguriert, dass er die den Servern zugeordneten Parameter verfolgt bzw. überwacht. Zum Beispiel können die den Servern zugeordneten Verfügbarkeits- und Konnektivitätsinformationen in dem Name Server gespeichert werden. Die verschiedenen Komponenten in dem System können den Name Server in Bezug auf verschiedene Informationen in Bezug auf die Verfügbarkeit und die Konnektivität der Server abfragen. In einer Windows NT-Umgebung kann der Name Server als ein NT Dienst ausgeführt werden. In einer UNIX-Umgebung kann der Name Server als ein Dämon-Prozess ausgeführt werden. In einem Ausführungsbeispiel wird die Verbindungsmakelkomponente eingesetzt, um eine Lastverteilungsfunktion auszuführen, wie etwa das Leiten von Client-Verbindungsanforderungen an einen entsprechenden Server (z.B. den am wenigsten beschäftigten Server).
In einem Ausführungsbeispiel gemäß der Abbildung aus 2 können die verschiedenen Arten von Clients, die von dem System unterstützt werden können, die folgenden Clients aufweisen: dedizierte Web-Clients, mobile Web-Clients, Wireless Clients und Handheld-Clients, etc.
In einem Ausführungsbeispiel sind die dedizierten Web-Clients (auch als angeschlossene bzw. verbundene Clients bezeichnet) direkt mit einem Datenbank-Server für einen Datenzugriff verbunden, und zwar über eine LAN- oder WAN-Verbindung. In einem Ausführungsbeispiel speichern diese verbundenen oder dedizierten Web-Clients keine Daten lokal. Diese dedizierten Web-Clients können auch direkt auf das Dateisystem zugreifen. In einem Ausführungsbeispiel befinden sich die Benutzerschnittstellen-, die Objektmanager- und die Datenmanagerschichten der mehrschichtigen Architektur auf dem dedizierten Web-Client.
In einem Ausführungsbeispiel sind die mobilen Web-Clients für einen lokalen Datenzugriff gestaltet und konfiguriert, und sie können somit eine eigene lokale Datenbank und/oder ein lokales Dateisystem aufweisen. In einem Ausführungsbeispiel können mobile Web-Clients mit anderen Komponenten in dem System über den Gateway-Server interagieren. Durch Synchronisierung können die Modifikationen von der lokalen Datenbank und der Server-Datenbank ausgetauscht werden. Mobile Web-Clients werden nachstehend im Text näher beschrieben.
In einem Ausführungsbeispiel wird ein Web-Client in einem Standard-Browserformat über die Vorrichtung des Client ausgeführt. In einem Ausführungsbeispiel kann der Web-Client über einen Web-Server eine Verbindung mit einem System-Server 255 herstellen. In einem Ausführungsbeispiel ist der System-Server 255 so gestaltet und konfiguriert, dass er eine Geschäftslogik ausführt und auf Daten aus der Datenbank 290 und dem Dateisystem 295 zugreift. In einem Ausführungsbeispiel ist der hierin beschriebene Web-Client gemäß den Lehren der vorliegenden Erfindung so gestaltet und konfiguriert, dass er in einem interaktiven Modus arbeitet. In einem Ausführungsbeispiel verwendet der Web-Client-Rahmen gemäß der Beschreibung hierin dynamisch erzeugte Objekte, implementiert in JavaScript auf der Browser-Seite, welche den Objekten auf der Server-Seite entsprechen. In einem Ausführungsbeispiel können diese dynamisch erzeugten Objekte auf der Browser-Seite die aktuelle Ansicht und deren entsprechenden Applets, die aktuellen Geschäftsobjekte und die entsprechenden Geschäftskomponenten, etc. aufweisen. Der Web-Client wird nachstehend im Text näher beschrieben.
In einem Ausführungsbeispiel handelt es sich bei Wireless Clients im Wesentlichen um Thin Clients, die an Wireless-Geräten bzw. kabellosen Geräten freigegeben bzw. aktiviert sind. Die Wireless Clients können eine WAP-basierte Benutzerschnittstelle bzw. Benutzeroberfläche (WAP als englische Abkürzung von Wireless Application Protocol) für die Kommunikation und den Austausch von Informationen/Daten mit dem System-Server verwenden.
Die in der Abbildung aus 2 veranschaulichte Systemkonfiguration wird nachstehend in Bezug auf verschiedene Strukturen, Datenbanken, Tabellen, Dateisysteme, etc. als veranschaulichende Beispiele näher beschrieben.
Die Abbildung aus 3 zeigt ein Blockdiagramm einer weiteren logischen Darstellung einer mehrschichtigen Architektur, wobei Anwendungen gemäß den Lehren der vorliegenden Erfindung erzeugt werden können. Die mehrschichtige Architektur gemäß der Abbildung aus
3 stellt wiederum die Plattform für verschiedene gemeinsame Dienste bereit, die so gestaltet und konfiguriert sind, dass sie die verschiedenen Anwendungen unterstützen. In einem Ausführungsbeispiel können die verschiedenen Dienste eine Präsentationsdienste-Logikschicht 315 aufweisen, die einem Applet-Manager und einer Benutzerschnittstellenschicht 310, eine Anwendungsdienste-Logikschicht 325, die einer Objektmanagerschicht (OM-Schicht) 320 und einer Datenmanagerschicht (DM-Schicht) 330 entspricht, und eine Datendienste-Logikschicht 345, die einer Datenbankschicht 340 entspricht.
In einem Ausführungsbeispiel können die Präsentationsdienste 315 so gestaltet und konfiguriert werden, dass sie verschiedenartige Clients unterstützen, und sie können diese mit Benutzerschnittstellen-Applets, Ansichten, Diagrammen und Berichten, etc. bereitstellen. Wie dies vorstehend im Text beschrieben worden ist, kann eine große Vielzahl von Clients unterstützt werden, darunter Wireless Clients, Handheld-Clients, Web-Clients, mobile Web-Clients und dedizierte (verbundene) Clients, etc.
In einem Ausführungsbeispiel können die Anwendungsdienste 325 Geschäftslogikdienste und Datenbankinteraktionsdienste aufweisen. In einem Ausführungsbeispiel stellen die Geschäftslogikdienste die Klasse und das Verhalten von Geschäftsobjekten und Geschäftskompnenten bereit. In einem Ausführungsbeispiel können Datenbankinteraktionsdienste so gestaltet und konfiguriert werden, dass sie die Benutzerschnittstellen-Anforderung (UI-Anforderung) für Daten von einer Geschäftskomponente verwenden und die erforderlichen Datenbankbefehle (z.B. SQL-Abfragen, etc.) zur Erfüllung der Anforderung erzeugen. Die Dateninteraktionsdienste können zum Beispiel eingesetzt werden, um einen Datenabruf in DBMS-spezifische SQL-Aussagen umzusetzen.
In einem Ausführungsbeispiel können die Datenspeicherdienste 345 so gestaltet und konfiguriert werden, dass sie die Datenspeicherung für das zugrunde liegende Datenmodell bereitstellen, das als Basis für die verschiedenen Anwendungen dient. Zum Beispiel kann das Datenmodell so gestaltet und konfiguriert werden, um verschiedene Softwareprodukte und Anwendungen zu unterstützen, darunter Call Center, Vertrieb, Service bzw. Kundendienst und Marketing, etc., sowie verschiedene vertikale Branchenprodukte und Anwendungen, wie zum Beispiel E-Finance, E-Insurance, E-Communications und E-Healthcare (E-Finanzen, E-Versicherung, E-Kommunikation und E-Gesundheitswesen), etc.
Die Abbildung aus 4 veranschaulicht ein Blockdiagramm eines Ausführungsbeispiels eines Anwendungsrahmens, in dem die Lehren der vorliegenden Erfindung implementiert werden können. Wie dies in der Abbildung aus 4 veranschaulicht ist, kann der Anwendungsrahmen verschiedene logische Gruppierungen verschiedenartiger Dienste aufweisen sowie verschiedenartiger Tools, die zur Gestaltung und Konfiguration der jeweiligen Anwendungen auf der Basis der geschäftlichen Anforderungen und Umgebungen eingesetzt werden können.
In einem Ausführungsbeispiel werden die Kerndienste so gestaltet und konfiguriert, dass der Rahmen bereitgestellt wird, innerhalb dem die Anwendungen ausgeführt werden. In einem Ausführungsbeispiel können die Kerndienste folgendes umfassen:

• den Enterprise-Server, der den Anwendungsserver auf mittlerer Ebene darstellt
• die Netzwerke bzw. Netze, die alle diese Elemente miteinander verknüpfen
• Einrichtungen wie ein Event-Manager und Datenreplikation, die einen Austausch von Daten zwischen mehreren Installationen verschiedener Anwendungen sowie zwischen den verschiedenen Anwendungen und anderen externen Anwendungen ermöglichen
• die Authentifikations- und Zugangssteuerung, die Sicherheitseinrichtungen.

In einem Ausführungsbeispiel können Anwendungsintegrationsdienste so gestaltet und konfiguriert werden, dass sie die Erzeugung von Anwendungen gemäß diesem Rahmen ermöglichen, ohne Kommunikation mit der externen Welt. In einem Ausführungsbeispiel können die verschiedenen Arten von Diensten in dieser logischen Gruppierung so gestaltet und konfiguriert werden, dass sie eine Integration in Echtzeit, in naher Echtzeit und eine Batch-Integration mit externen Anwendungen bereitstellen. Diese Integrationsdienste können zum Beispiel eingesetzt werden, um Kommunikationen zwischen externen Anwendungen und den internen Anwendungen zu ermöglichen, unter Verwendung verfügbarer Verfahren, Technologien und Softwareprodukte. In einem Ausführungsbeispiel ermöglichen es Anwendungsintegrationsdienste, dass die Systeme oder Anwendungen Daten mit anderen externen Enterprise-Anwendungen gemeinsam nutzen und replizieren. Folglich ermöglichen diese Dienste es einer bestimmten Anwendung oder einem bestimmten System, sowohl einen Client darzustellen, der Informationen anfordert, als auch einen Server, der die angeforderten Informationen aufweist.
In einem Ausführungsbeispiel sind Geschäftsprozessdienste so gestaltet und konfiguriert, dass sie es dem Client ermöglichen, Geschäftsprozesse durch die Anwendung zu automatisieren. In einem Ausführungsbeispiel können die verschiedenen Geschäftsprozessdienste folgendes aufweisen:

• die Zuordnung von Aufgaben über den Zuordnungsmanager
• die Durchsetzung von Geschäftspraktiken über den Workflow-Manager
• die Wiederverwendung einer individuellen Geschäftslogik durch Geschäftsdienste
• die Gewährleistung einer ordnungsgemäßen Produktkonfiguration und Preisgestaltung durch den Produktkonfigurator und den Preisgestaltungskonfigurator.

In einem Ausführungsbeispiel kann die Erzeugung bzw. Erstellung von Geschäftsprozessen über Laufzeit-Tools wie etwa Personalization Designer, Workflow Designer, SmartScript Designer, Assignment Administration Views und Model Builder, etc. erfolgen.
In einem Ausführungsbeispiel können Integrationsdienste so gestaltet und konfiguriert werden, dass der Client mit einer Benutzerschnittstelle und Thin Client-Unterstützung bereitgestellt wird. In einem Ausführungsbeispiel können diese Fähigkeiten für die Erzeugung und die Verwaltung von Web-basierten Anwendungen, die Bereitstellung von Web-Unterstützungseinrichtungen aufweisen, wie etwa Profilmanagement, Zusammenarbeitsdienste und E-Mail sowie Faxdienste und hoch entwickeltes Smart Scripting, etc.
In einem Ausführungsbeispiel können Entwicklungszeit-Tools so gestaltet und konfiguriert werden, um die Dienste bereitzustellen, um Integrationspunkte individuell zu gestalten, zu entwickeln und bereitzustellen sowie um die Anwendung zu verwalten. Diese verschiedenen Tools stellen eine gemeinsame Einrichtung für die Definition der Anwendung bereit.
In einem Ausführungsbeispiel sind die Administrationsdienste so gestaltet und konfiguriert, dass sie einen Punkt bzw. eine Einrichtung für die Überwachung und Administration der Anwendungsumgebung bereitstellen. In einem Ausführungsbeispiel ermöglichen es diese Dienste dem Benutzer, die Anwendung entweder über die grafische Benutzeroberfläche (GUI) oder über eine Befehlszeile, etc. zu administrieren.
II. Systemrahmen oder Infrastruktur
Die Abbildung aus 5A veranschaulicht einen beispielhaften Systemrahmen oder eine Systeminfrastruktur 500 zur Unterstützung eines interaktiven Web-Client 205 und eines mobilen Web-Client 210 aus 2 gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Die Abbildung aus 5B veranschaulicht eine alternative Ansicht des exemplarischen Systemrahmens oder der Systeminfrastruktur 500 aus 5A.
Per Rahmen oder die Infrastruktur 500 kann den interaktiven Web-Client 205 (dargestellt in 2) und den mobilen Web-Client 210 (ebenfalls in 2 abgebildet) unterstützen und ist in der Lage, bestimmte Kriterien zu erfüllen, wie etwa die Steigerung der Interaktivität und der Leistung des Web-Clients und des mobilen Web-Clients und die Reduzierung der Anzahl der Seitenaktualisierungen für übliche Maßnahmen bzw. Ereignisse.
Der Rahmen oder die Infrastruktur 500 kann Objekte 502 aufweisen, die dynamisch in dem Browser erzeugt werden können, um entsprechende Objekte 504 nachzuahmen, die durch den Objektmanager verwaltet werden. In einem Ausführungsbeispiel können die von dem Objektmanager (OM) verwalteten Objekte 504 unter Verwendung einer Programmiersprache erzeugt werden, wie etwa C+++, welche das Objekt-orientierte Pradigma unterstützt.
Wie dies in den Abbildungen der 5A und 5B dargestellt ist, können exemplarische Objekte 504, die durch den OM verwaltet werden, ein Objekt 506 aufweisen, das eine Ansicht darstellt, CSSWEView 506. Eine Ansicht ist allgemein ein Anzeigefeld, das aus einer bestimmten Anordnung von Applets besteht. In einem Ausführungsbeispiel kann eine aktive Ansicht zu jedem gegebenen Zeitpunkt angezeigt werden. Bei einem weiteren von dem OM verwalteten Objekt kann es sich um ein Objekt 508 handeln, das ein Applet darstellt, das Applet CSSWEApplet 508. Ein Applet ist allgemein eine visuelle Anwendungseinheit, die auf dem Bildschirm als ein Teil einer Ansicht erscheint. Weitere exemplarische Objekte, die durch den OM verwaltet werden, können ein Objekt 510 zählen, das eine Geschäftskomponente (CSSBusComp 510) darstellt, ein Objekt 512, das ein Geschäftsobjekt (CSSBusObj 512) darstellt, und ein Objekt 514, das einen Rahmen bzw. Frame (CSSWEFrame 514) darstellt. In einem Ausführungsbeispiel kann das Geschäftsobjekt als konfigurierbare Softwaredarstellungen der verschiedenen Geschäftsregeln oder Konzepte gestaltet sein, wie etwa Konten, Kontakte, Möglichkeiten bzw. Gelegenheiten, Serviceanforderungen, Lösungen, etc. In dem vorliegenden Ausführungsbeispiel stellen die Geschäftskomponenten für gewöhnlich eine umlaufende Schicht um Tabellen dar, und die Applets verweisen auf Geschäftskomponenten anstatt auf die darunter liegenden Tabellen. Darüber hinaus ist ein Rahmen bzw. ein Frame allgemein eine Teilkomponente einer Ansicht und kann eines oder mehrere Applets umfassen.
In einem Ausführungsbeispiel können Objekte 502 in dem Browser unter Verwendung von JavaScript erzeugt werden. Wie dies in den Abbildungen der 5A und 5B dargestellt ist, können exemplarische Objekte 502 auf der Browser-Seite JSSBusObj 516, JSSBusComp 518, JSSView 520 und JSSApplet 522 aufweisen, um entsprechend CSSBusObj 512, CSSBusComp 510, CSSWEView 506 und CSSWEApplet 508 zu spiegeln, die durch den OM verwaltete Objekte 504 darstellen.
Die Abbildung aus 5C veranschaulicht ein exemplarisches Ausführungsbeispiel eines Computersystems, das sich zum impliziten erzwungenen Wegschreibeneiner Aktualisierung eignet. Das Computersystem 500 umfasst in der Abbildung den Client 502, der über das RPC-Modul 528 mit dem Server 504 gekoppelt ist. Der Client 502 weist die Anwendung 524 auf, die mit dem RPC-Modul 528, dem aktiven Applet 522 und dem Applet 510 gekoppelt ist. Das aktive Applet 522 ist mit der Anzeige 580 gekoppelt. Das aktive Applet 522 kann ein Datensatzfeld darstellen. Die Anzeige 580 kann eine für den Benutzer interaktive Anzeige darstellen, um einen Aufzeichnungs- bzw. Datensatzwert für das aktive Applet 522 anzuzeigen. Die Anzeige 580 ist ferner mit dem Anzeigeobjekt 516 gekoppelt. Die Applets 522 und 510 sind mit den entsprechenden Geschäftskomponenten 518 und 572 gekoppelt. Die Geschäftskomponente 518 weist einen Cache 568 auf. Ein Benutzer kann einen teilweisen Datensatzwert für das aktive Applet 522 über die Anzeige 580 eingeben. Die Anwendung 524 ist ferner mit dem Befehlsmanager 574, dem lokalen Objekt 576 und dem Alarmmanager 584 gekoppelt. Das aktive Applet 522 kann ein Datensatzfeld darstellen, wobei es jedoch normalerweise eher eine Vielzahl von Feldern aufweist.
Der Server 504 ist mit der Ablage 552 gekoppelt. Die Objekte des Clients 502 weisen die Proxy-Objekte der Objekte des Servers 504 auf. Zum Beispiel ist die Anwendung 524 ein Proxy des Frame-Mangers 526, wobei die Anzeige 580 ein Proxy der Anzeige 588 ist, wobei das aktive Applet 522 ein Proxy des aktiven Applets 508 ist, wobei das Applet 510 ein Proxy des Applets 556 ist, und wobei die Geschäftskomponenten 518 und 572 Proxies der entsprechenden Geschäftskomponenten 510 und 566 sind. Die Anzeige 558 ist mit dem Geschäftsobjekt 512 gekoppelt. Das Geschäftsobjekt 516 ist ein Proxy des Geschäftsobjekts 512.
Die Kommunikationsanforderungen zwischen dem Client 502 und dem RPC-Modul 528 werden durch die Anwendung 524 verarbeitet. Die Kommunikationsanforderungen können eine Kontextänderungsanforderung aufweisen. In einem Ausführungsbeispiel der vorliegenden Erfindung kann die Kontextänderungsanforderung eine Benutzeranforderung für eine neue Webseite aufweisen. In einem anderen Ausführungsbeispiel der vorliegenden Erfindung kann die Kontextänderungsanforderung die Benutzeranforderung aufweisen, um aus dem aktiven Applet 522 zu tabellieren. In einem weiteren Ausführungsbeispiel der vorliegenden Erfindung kann die Kontextänderungsanforderung eine durch den Client 502 erzeugte Kontextänderungsanforderung aufweisen.
Die Anwendung 524 kann automatisch eine ungespeicherte Datumsanforderung an das aktive Applet 522 übermitteln als Reaktion auf den Empfang einer Kontextänderungsanforderung. Die ungespeicherte Datumsanforderung fragt ab, ob das aktive Applet 522 ein ungespeichertes Datum aufweist. Das aktive Applet 522 kann als Reaktion auf den Empfang der Cache-Anforderung automatisch eine Cache-Anforderung zu der Geschäftskomponente 518 übertragen. Die Geschäftskomponente 518 bestimmt automatisch, ob der Cache 568 etwaige ungespeicherte Benutzereinträge aufweist, und zwar als Reaktion auf den Empfang der Cache-Anforderung. Die Geschäftskomponente 518 übermittelt eine Cache-Benachrichtigungsanforderung an das aktive Applet 522. Die Cache-Benachrichtigungsanforderung weist entweder die ungespeicherten Daten oder eine Benachrichtigung auf, dass der Cache 568 keine ungespeicherten Daten aufweist.
Das aktive Applet 522 kann eine Post-Anforderung auslösen als Reaktion auf den Empfang der Cache-Benachrichtigungsanforderung. Die Post-Anforderung kann die ungespeicherten Daten aus dem Cache 568 aufweisen. Das aktive Applet 522 kann ferner eine Anforderung für keine ungespeicherten Daten an die Anwendung 524 übertragen. Die Anforderung für keine ungespeicherten Daten kann anzeigen, dass der Cache 568 keine ungespeicherten Daten aufweist. Die Geschäftskomponente 518 kann den Cache 568 löschen, nachdem die Cache-Benachrichtigungsanforderung übertragen worden ist.
Die Anwendung 524 kann automatisch die Kontextänderungsanforderung über das RPC-Modul 528 an den Server 504 übertragen, und zwar als Reaktion auf den Empfang entweder der Post-Anforderung oder der Anforderung für keine ungespeicherten Daten. Die Anwendung 524 kann die Post-Anforderung über das RPC-Modul 528 an den Server 504 weiterleiten.
Der Server 504 kann automatisch die Post-Anforderung als Reaktion auf den Empfang der Post-Anforderung verarbeiten. Der Server 504 kann die Post-Anforderung verarbeiten, indem bestimmt wird, ob sie 504 die ungespeicherten Daten in eine Datenbank wegschreiben möchte. Der Server 504 kann eine Serverbenachrichtigung an den Client 502 übertragen. Die Serverbenachrichtigung kann entweder eine Erfolgsnachricht aufweisen, die anzeigt, dass die ungespeicherten Daten erfolgreich in der Datenbank gespeichert worden sind, oder eine Fehlernachricht, die anzeigt, dass die ungespeicherten Daten nicht in der Datenbank gespeichert werden können.
Die Anwendung 524 kann die Fehlernachricht auf der Anzeige 580 anzeigen, und zwar als Reaktion auf den Empfang der Fehlernachricht von dem Server 504 über das RPC-Modul 528. Die Anwendung 524 kann die Übermittlung der Kontextänderungsanforderung an den Server 504 als Reaktion auf den Empfang der Fehlernachricht von dem Server 504 zurückhalten. Ferner kann die Anwendung 524 automatisch die Kontextänderungsanforderung über das RPC-Modul 528 an den Server 504 übertragen, und zwar als Reaktion auf den Empfang der Erfolgsnachricht von dem Server 504 über das RPC-Modul 528.
Der Server 504 kann automatisch die Kontextänderungsanforderung als Reaktion auf den Empfang der Kontextänderungsanforderung verarbeiten. Der Server 504 kann die Kontextänderungsanforderung verarbeiten, indem der angeforderte neue Kontext über das RPC-Modul 528 zu dem Client 502 übermittelt wird. Der angeforderte Kontext kann ein Applet oder eine Webseite aufweisen. Die Anwendung 524 kann den neuen Kontext über das RPC-Modul 528 empfangen. Die von dem Server 504 empfangene Webseite kann die über die Anzeige 580 angezeigte Webseite ersetzen. Das von dem Server 504 empfangene Applet kann das Applet 522 als das aktive Applet ersetzen.
Die Objekte 502 in dem Browser und die durch den OM verwalteten Objekte 504 können so konfiguriert werden, dass sie sich auf einer Computervorrichtung oder mehreren Computervorrichtungen befinden und darauf betrieben werden können. Die Abbildung aus 6A veranschaulicht eine beispielhafte Konfiguration 600, bei der sich Objekte 502 in dem Browser und durch den OM verwaltete Objekte 504 auf mehreren Computervorrichtungen 602, 604 befinden und darauf betrieben werden, wobei die Vorrichtungen einen Client 602 und einen Server 604 aufweisen. Die Abbildung aus 6B veranschaulicht eine exemplarische Konfiguration 650, bei der die Objekte 502 in dem Browser und die durch den OM verwalteten Objekte 504 sich auf einer Computervorrichtung 652 befinden und darauf betrieben werden.
In erneutem Bezug auf die Abbildungen der 5A und 5B werden die Objekte 502 in dem Browser allgemein mit entsprechenden oder gespiegelten Objekten 504 synchronisiert, die durch den OM verwaltet werden. Die Synchronisierung kann über einen RPC-Mechanismus 528 (RPC als englische Abkürzung von Remote Procedure Call bzw. entfernter Prozeduraufruf) und einen Benachrichtungsmechanismus 530 erreicht werden. Der RPC-Mechanismus 528 und der Benachrichtigungsmechanismus 530 werden nachstehend im Text näher beschrieben.
Von den Objekten 502 in dem Browser existiert das Objekt JSSApplication 524 für gewöhnlich während einer ganzen Benutzersitzung. Das Objekt JSSApplication 524 sollte anfänglich geladen werden, wenn der Benutzer eine Anwendung startet. Eine Anwendung wird allgemein gestartet, wenn der Benutzer einen Teil der Anwendung über ein Symbol auf dem Desktop oder über das Start-Menü aufruft. Das Objekt JSSApplication 524 führt allgemein eine Rolle aus, die der des Objekts CSSModel 534 ähnlich ist. Das Objekt CSSModel 534 ist allgemein ein globales Sitzungsobjekt, das Zugriff auf Ablagenobjekte bereitstellt, die sich im Einsatz befinden, die aktuelle Geschäftsobjektinstanz in dem Speicher, die Beziehung zwischen dem aktuellen Geschäftsobjekt und den darin enthaltenen Geschäftskomponenten sowie den globalen Zustandsinformationen des Benutzers. Das Objekt CSSModel 534 greift allgemein auf eine Ablage 532 zu, um die benötigten Informationen zu erhalten. Die Ablage 532 stellt allgemein eine Reihe von Objektdefinitionen dar, die eingesetzt werden, um eine Anwendung oder eine Reihe von Anwendungen zu definieren. Das Objekt JSSApplication 524 wird allgemein jedoch abwärts skaliert, um eine Ansicht zu verfolgen, die der verfolgten Ansicht zugeordneten Applets, ein Geschäftsobjekt und die in der Ansicht verwendeten Geschäftskomponenten.
Im Gegensatz zu dem Objekt JSSApplication 524 stellen das Objekt JSSView 520, das Objekt JSSApplet 522, das Objekt JSSBusObj 516 und das Objekt JSSBusComp 518 für gewöhnlich temporäre oder nicht dauerhafte Instanzen dar und werden allgemein ersetzt, wenn eine Seitenaktualisierung erfolgt. Zum Beispiel kann eine Anforderung für eine Navigation zu einer neuen Ansicht bewirken, dass eine neue Reihe von Objekten JSSView 520, JSSApplet 522, JSSBusObj 516 und JSSBusComp 518 für eine Ausführung in dem Browser erzeugt wird.
Demgemäß können die Objekte 502 in dem Browser allgemein als leichte Darstellungen der durch den OM verwalteten gespiegelten oder entsprechenden Objekte 504 beschrieben werden. Jedes Objekt 502 in dem Browser würde für gewöhnlich eine Teilmenge bzw. Untergruppe der Funktionalitäten aufweisen, die in den entsprechenden durch den OM verwalteten Objekten 504 enthalten sind. Zum Beispiel stellt das Objekt JSSView 520, das dem Objekt CSSView 506 ähnlich ist, allgemein eine Sammlung von Applets dar. Das Objekt JSSBusObj 516, das dem Objekt CSSBusObj 512 ähnlich ist, verwaltet allgemein die verschiedenen One-to-Many-Beziehungen zwischen aktiven Geschäftskomponenten, so dass die richtigen Beziehungen eingesetzt werden, wenn diese aktiven Geschäftskomponenten über Abfragen bevölkert werden. Das Objekt JSSBusObj 516 existiert in dem Browser allgemein über die Lebensdauer der aktuellen Ansicht und sollte mit dem entsprechenden Objekt CSSBusObj 512 synchronisiert bleiben.
Wenn der Browser in einem Ausführungsbeispiel eine Anforderung zum Navigieren zu einer neuen Ansicht an die Web-Engine 526 sendet, würde die Web-Engine 526 eine Antwort senden, welche das Ansichtlayout aufweist, das keine Daten aufweist. Danach würde die Web-Engine 526 eine Antwort senden, die eine Datenfolge aufweist, um die Ansicht zu populieren.
Das Objekt JSSApplication 524 verwaltet allgemein Kommunikationen, die in Objekte und aus Objekten in dem Browser fließen. In einem Ausführungsbeispiel würde ein in dem Browser in Bezug auf ein Objekt aufgerufenes Verfahren für gewöhnlich zu dem Objekt JSSApplication 524 geleitet werden, wenn das aufgerufene Verfahren neu auf ein Objekt 504 gerichtet werden soll, das von dem OM verwaltet wird. Das Objekt JSSApplication 524 würde allgemein den RPC-Mechanismus 528 verwenden, um das aufgerufene Verfahren durch die Web-Engine 526 zu dem entsprechenden durch den OM verwalteten Objekt 504 zu führen. Die Web-Engine 526 würde allgemein eingesetzt werden, um Rückgabebenachrichtigungen und Daten von durch den OM verwalteten Objekten 504 zu Objekten 502 in dem Browser zu führen.
Die Browser-Objekte 502 verwenden allgemein entfernte Prozeduraufrufe 528, um Verfahren an den Objekten 504 aufzurufen, die durch den OM verwaltet werden. Diese entfernten Prozeduraufrufe 528 sind allgemein als HTTP-Anforderungen verpackt. Antworten von den durch den OM verwalteten Objekten 504 sind als HTTP-Antworten verpackt, welche Benachrichtigungen und zugeordnete Status- bzw. Zustandsinformationen und -daten enthalten. In einem Ausführungsbeispiel erfolgen entfernte Prozeduraufrufe mit aktivierter Sperre, um die Synchronisierung zwischen den Objekten 502 in dem Browser und den durch den OM verwalteten Objekten 504 sicherzustellen. Bei aktivierter Sperre würde die Steuerung für gewöhnlich nicht zurück auf den aufrufenden Code übertragen, bis die Ausführung der aufgerufenen entfernten Prozedur abgeschlossen ist.
Entfernter Prozeduraufruf (RPC)
Das RPC-Modell verwendet allgemein die gleiche prozedurale Abstraktion wie ein herkömmliches Programm, ermöglicht es jedoch, dass ein Prozeduraufruf die Begrenzung zwischen zwei Computern überschreitet. Die Abbildung aus 7 veranschaulicht ein Beispiel dafür, wie das RPC-Paradigma eingesetzt werden kann, um ein Programm 700 in Teile aufzuteilen, die in separaten Computervorrichtungen 702, 704 ausgeführt werden können. Diese Abbildung zeigt allgemein ein verteiltes Programm mit mehreren Prozeduren. Main() 706, proc_1() 708, proc_2() 710, proc_3() 712, proc_5() 714, proc_6() 716 und proc_7() 718 befinden sich und arbeiten in der ersten Computervorrichtung oder dem Client 702; und proc_4() 729 und proc_8() 822 befinden sich und arbeiten in der zweiten Computervorrichtung oder dem Server 704. Eine durchgezogene Linie 724 von der Prozedur n zu der Prozedur m bezeichnet einen Aufruf von n an m. Eine gestrichelte Linie 726 zeigt, wie die Steuerung von einer Computervorrichtung zu einer anderen Computervorrichtung während einem entfernten Prozeduraufruf wechselt.
Die Abbildung aus 8 veranschaulicht ein beispielhaftes Modell 800 der Ausführung, das in Verbindung mit entfernten Prozeduraufrufen eingesetzt wird. In dieser Abbildung dienen die durchgezogenen Linien 724 allgemein zur Bezeichnung der Ablaufsteuerung in einer Computervorrichtung; und die gestrichelten Linien 726 dienen allgemein der Darstellung, wie die Steuerung von einer Computervorrichtung zu einer anderen Computervorrichtung während einem entfernten Prozeduraufruf wechselt bzw. übergeht.
Dabei führt ein entfernter Prozeduraufruf allgemein eine Prozedur auf, die sich in einem separaten Adressraum von dem aufrufenden Code befindet. Das RPC-Modell wird allgemein von dem Programmierungsmodell lokaler Prozeduraufrufe abgeleitet und nutzt die Tatsache, dass jede Prozedur eine Prozedurvereinbarung aufweist. Die Prozedurvereinbarung definiert die Schnittstelle zwischen dem aufrufenden Code und der aufgerufenen Prozedur. Die Prozedurvereinbarung definiert die Aufrufsyntax und die Parameter der Prozedur. Aufrufe einer Prozedur sollten für gewöhnlich der Prozedurvereinbarung entsprechen.
Anwendungen, die entfernte Prozeduraufrufe verwenden, sehen aus und verhalten sich wie lokale Anwendungen. Eine RPC-Anwendung ist jedoch in zwei Teile aufgeteilt: einen Server, der eine oder mehrere Gruppen von entfernten Prozeduren anbietet, und einen Client, der entfernte Prozeduraufrufe an RPC-Server vornimmt. Ein Server und dessen Client(s) befinden sich allgemein auf separaten bzw. getrennten Systemen und kommunizieren über ein Netzwerk. RPC-Anwendungen sind von der RPC-Laufzeitbibliothek abhängig in Bezug auf die Steuerung der Netzwerkkommunikationen für sie. Die RPC-Laufzeitbibliothek unterstützt allgemein zusätzliche bzw. weitere Aufgaben, wie etwa das Suchen von Servern für Clients und das Verwalten von Servern.
Eine verteilte Anwendung verwendet allgemein verteilte Computerressourcen, wie etwa Zentraleinheiten (CPUs), Datenbanken, Vorrichtungen bzw. Bausteine und Dienste. Die folgenden Beispiele sind veranschaulichende Beispiele für verteilte Anwendungen:

• Eine Kalendermanagementanwendung, die befugten Benutzern den Zugriff auf persönliche Kalender anderer Benutzer ermöglicht;
• Eine Grafikanwendung, die Daten auf CPUs verarbeitet und die Ergebnisse auf Workstations anzeigt; und
• Eine Fertigungsanwendung, die Informationen über Assembly-Komponenten unter Design-, Bestands-, Scheduling- und Abrechnungsprogrammen auf verschiedenen Computern austauscht.

RPC-Software sollte allgemein die grundlegenden Anforderungen für eine verteilte Anwendung erfüllen. Dazu zählen:

• Clients, welche die entsprechenden Server finden;
• Datenumwandlung für den Betrieb in einer heterogenen Umgebung; und
• Netzwerkkommunikationen.

Verteilte Anwendungen umfassen Aufgaben, wie etwa die Verwaltung von Kommunikationen, das Suchen bzw. Finden von Servern, das Bereitstellen von Sicherheit und so weiter. Eine unabhängige verteilte Anwendung muss all diese Aufgaben selbst ausführen. Ohne einen geeigneten Mechanismus für diese verteilten Computer- bzw. Computing-Aufgaben ist das Schreiben verteilter Anwendungen schwierig, teuer und fehleranfällig.
RPC-Software stellt für gewöhnlich den Code bereit, bezeichnet als RPC-Stubs, sowie die RPC-Laufzeitbibliothek, welche verteilte Computing-Aufgaben für Anwendungen ausführt. Die RPC-Stubs und die RPC-Laufzeitbibliothek sollten mit Client- und Serveranwendungscode verknüpft sein, so dass eine RPC-Anwendung gebildet wird.
Die Tabelle 1 zeigt allgemein die grundlegenden Aufgaben für den Client und Server einer verteilten Anwendung. Der Aufruf einer Prozedur und die Ausführung der entfernten Prozedur, dargestellt durch den Text in Klammern, werden durch den Anwendungscode ausgeführt (wie bei einer lokalen Anwendung), wobei sie sich hierbei jedoch in den Client- und Serveradressräumen befinden. In Bezug auf die anderen Aufgaben werden einige dieser automatisch durch die Stubs und die RPC-Laufzeitbibliothek ausgeführt, während andere durch die RPC-Laufzeitbibliothek über API-Aufrufe in dem Anwendungscode ausgeführt werden. Tabelle 1: Grundlegende Aufgaben einer RPC-Anwendung
Die Abbildung aus 9 zeigt allgemein eine beispielhafte Partitionierung 900 von RPC-Anwendungscodesegmenten 904 und 914, RPC-Schnittstellen 906 und 916, Client- und Server-Stubs 908 und 918 und der RPC-Laufzeitbibliotheken 910 und 920 in dem RPC-Client 902 und dem RPC-Server 904.
Der RPC-Client 902 oder der RC-Server 912 weist für gewöhnlich RPC-Anwendungscodesegmente 904 und 914, RPC-Schnittstellen 906 und 916, Stubs 908 und 918 und die RPC-Laufzeitbibliotheken 910 und 920 auf. Die RPC-Anwendungscodesegmente 904, 914 stellen allgemein den Code dar, der für eine spezielle RPC-Anwendung durch den Anwendungsentwickler geschrieben wird. Die RPC-Anwendungscodesegmente 904, 914 implementieren und rufen allgemein entfernte Prozeduren auf und rufen ferner erforderliche Routinen und Prozeduren in der RPC-Laufzeitbibliothek auf. Ein RPC-Stub 908, 918 ist allgemein ein Schnittstellen-spezifisches Codemodul, das eine RPC-Schnittstelle 906, 916 verwendet, um Argumente weiterzuleiten und zu empfangen. Ein Client 902 und ein Server 912 weisen für gewöhnlich komplementäre RPC-Stubs 906, 916 für jede gemeinsam genutzte RPC-Schnittstelle 906, 916 auf. Die RPC-Laufzeitbibliothek 910, 920 verwaltet allgemein Kommunikationen für RPC-Anwendungen. Darüber hinaus sollte die RPC-Laufzeitbibliothek 910, 920 eine Application Programming Interface (API) bzw. Programmierschnittstelle unterstützen, die von dem RPC-Anwendungscode verwendet wird, um es RPC-Anwendungen zu ermöglichen, ihre Kommunikationen aufzubauen, Informationen über Server zu manipulieren und optionale Aufgaben auszuführen, wie etwa die Fernverwaltung von Servern und den Zugriff auf Sicherheitsinformationen.
Die RPC-Anwendungscodesegmente 904, 914 unterscheiden sich für gewöhnlich in Bezug auf Clients und Server. Der RPC-Anwendungscode 914 auf dem Server 912 weist für gewöhnlich die entfernten Prozeduren auf, die eine RPC-Schnittstelle implementieren. Der RPC-Anwendungscode 904 auf dem entsprechenden Code 902 weist für gewöhnlich Aufrufe der entfernten Prozeduren auf.
Die RPC-Stubs 908, 918 führen allgemein grundlegende Unterstützungsfunktionen für entfernte Prozeduraufrufe aus. Zum Beispiel bereiten die RPC-Stubs 908, 918 Eingabe- und Ausgabeargumente für die Übertragung zwischen Systemen mit unterschiedlichen Formen der Datendarstellung vor. Die RPC-Stubs 908, 918 verwenden die RPC-Laufzeitbibliothek 910, 920 für die Behandlung der Übertragung bzw. Übermittlung zwischen dem Client 902 und dem Server 904. RPC-Stubs 908 an dem Client 902 können auch die lokale RPC-Laufzeitbibliothek 910 nutzen, um die entsprechenden Server für den Client 902 zu finden.
Die Abbildung aus 10 zeigt allgemein ein beispielhaftes Marshalling (Entgegennehmen und Umwandeln) und Unmarshalling (Wiederherstellen) zwischen Client-Datenstrukturen und Server-Datenstrukturen. Wenn der Client-RPC-Anwendungscode eine entfernte Prozedur aufruft, sollte der Client-RPC-Stub 908 die Eingabeargumente 1002 für die Übermittlung vorbereiten. Der Prozess zur Vorbereitung der Argumente für die Übermittlung ist als "Marshalling" bekannt.
Das Marshalling 1004 wandelt allgemein Eingabe- oder Aufrufargumente 1002 in ein Byte-Stromformat um und ordnet diese zur Übermittlung an. Nach dem Empfang der Aufrufargumente führt ein Server-RPC-Stub 918 deren Unmarshalling 1014 aus. Das Unmarshalling 1014 ist allgemein der Prozess, durch den ein Stub eingehende Netzwerkdaten zerlegt und diese unter Verwendung eines Formats, das das lokale System versteht, in Anwendungsdaten umwandelt. Das Marshalling 1004, 1016 und das Unmarshalling 1014, 1006 treten jeweils zweimal für jeden entfernten Prozeduraufruf auf. Der Client-RPC-Stub 908 führt ein Marshalling 1004 der Eingabeargumente 1002 aus sowie ein Unmarshalling 1006 der Ausgabeargumente 1008. Der Server-RPC-Stub 918 für ein Unmarshalling 1014 der Eingabeargumente 1006 aus sowie ein Marshalling 1016 der Ausgabeargumente 1008. Das Marshalling und das Unmarshalling ermöglichen es Client- und Serversystemen, unterschiedliche Datendarstellungen für äquivalente Daten zu verwenden. Zum Beispiel kann das Client-System ASCII-Daten 1002, 1008 verwenden, und wobei das Serversystem Unicode-Daten 1018 verwenden kann, wie dies in der Abbildung aus 10 dargestellt ist.
Der IDL-Kompilierer (ein Tool für die Anwendungsentwicklung) erzeugt Stubs, indem eine von Anwendungsentwicklern geschriebene RPC-Schnittstellendefinition kompiliert wird. Der Kompilierer erzeugt Marshalling- und Unmarshalling-Routinen für plattformunabhängige IDL-Datentypen. Für den Aufbau des Clients für eine RPC-Anwendung verknüpft ein Entwickler Client-Anwendungscode mit den Client-Stubs aller RPC-Schnittstellen, welche die Anwendung einsetzt. Für den Aufbau des Servers verknüpft der Entwickler den Server-Anwendungscode mit den entsprechenden Server-Stubs.
Zusätzlich zu einem oder mehreren RPC-Stubs sollte jeder RPC-Server und RPC-Client mit einer Kopie der RPC-Laufzeitbibliothek verknüpft sein. Die RPC-Laufzeitbibliothek stellt allgemein Laufzeitoperationen bereit, wie etwa die Steuerung von Kommunikationen zwischen Clients und Servern sowie das Finden von Servern für Clients auf Anforderung. RPC-Stubs in dem Client und dem Server tauschen für gewöhnlich Argumente über die RPC-Laufzeitbibliothek aus, die entsprechend lokal an dem Client und dem Server angeordnet ist. Die RPC-Laufzeitbibliothek auf dem Client übermittelt für gewöhnlich entfernte Prozeduraufrufe an den Server. Die RPC-Laufzeitbibliothek auf dem Server empfängt allgemein die entfernten Prozeduraufrufe von dem Client und gibt jeden Aufruf bzw. Anruf an den entsprechenden RPC-Stub auf dem Server ab. Die RPC-Laufzeitbibliothek sendet danach die Ergebnisse jedes Aufrufs an die RPC-Laufzeitbibliothek auf dem Client.
Der RPC-Anwendungscode auf dem Server muss ferner Serverinitialisierungscode aufweisen, der Routinen in der RPC-Laufzeitbibliothek auf dem Server aufruft, wenn der Server startet bzw. hochfährt und herunterfährt. RPC-Anwendungscode auf dem Client kann ebenfalls RPC-Laufzeitbibliothekroutinen für Initialisierungszwecke aufrufen. Ferner kann RPC-Anwendungscode auf dem Server und RPC-Anwendungscode auf dem Client auch Aufrufe an RPC-Stub-Unterstützungsroutinen aufweisen. RPC-Stub-Unterstützungsroutinen ermöglichen es allgemein, dass Anwendungen Programmierungsaufgaben verwalten, wie zum Beispiel die Zuweisung und Freigabe von Speicher.
Die Abbildung aus 11 zeigt allgemein exemplarischen Rollen für RPC-Anwendungscodesegmente 904 und 914 RPC-Schnittstellen 906 und 916, RPC-Stubs 908 und 918 und RPC-Laufzeitbibliotheken 910 und 920 während einem entfernten Prozeduraufruf. Der Anwendungscode des Client oder der aufrufende Code 908 ruft einen entfernten Prozeduraufruf auf, leitet die Eingabeargumente 1002 durch die RPC-Schnittstelle 906 des Client zu dem Client-Stub 908. Der Client-Stub 908 führt ein Marshalling der Eingabeargumente 1002 aus und gibt den Aufruf an die RPC-Laufzeitbibliothek 910 des Client ab. Die RPC-Laufzeitbibliothek 910 des Client übermittelt die Eingabeargumente 1002 an die RPC-Laufzeitbibliothek 920 des Servers, welche den Aufruf an den Server-Stub 918 für die RPC-Schnittstelle 916 der aufgerufenen Prozedur abgibt. Der Server-Stub 918 führt ein Unmarshalling der Eingabeargumente 1002 aus und leitet diese zu der aufgerufenen entfernten Prozedur 914. Der Server-Anwendungscode oder die entfernte Prozedur 914 wird ausgeführt und gibt danach etwaige Ausgabeargumente 1008 an den Server-Stub 918 zurück. Der Server-Stub 918 führt ein Marshalling der Ausgabeargumente 1008 aus und gibt diese an die RPC-Laufzeitbibliothek 920 des Servers zurück. Die Server-RPC-Laufzeitbibliothek 920 gibt die Ausgabeargumente 1008 an die Client-RPC-Laufzeitbibliothek 910 zurück, welche sie an den Client-Stub 901 abgibt. Der Client-Stub 908 führt ein Unmarshalling der Ausgabeargumente 1008 aus und gibt diese an den aufrufenden Code 904 zurück.
In einem Ausführungsbeispiel erfolgen entfernte Prozeduraufrufe mit aktivierter Sperre, um die Synchronisierung zwischen den Objekten 502 in dem Browser und durch den OM verwalteten Objekten 504 zu gewährleisten (dargestellt in den 5A und 5B). Bei aktivierter Sperre würde die Steuerung für gewöhnlich nicht auf den aufrufenden Code zurück übertragen, bis die aufgerufene entfernte Prozedur die Ausführung abgeschlossen hat.
Die Abbildung aus 12 stellt einen Überblick über ein beispielhaftes Verfahren 1200 der Gestaltung einer verteilten RPC-Anwendung bereit. Das Verfahren weist allgemein die folgenden grundlegenden Aufgaben auf:

• Gestaltung der Anwendung, Entscheidung, welche Prozeduren benötigt werden, und welche der benötigten Prozeduren entfernte Prozeduren sind, und Entscheidung, wie die entfernten Prozeduren in RPC-Schnittstellen gruppiert werden (Block 1205);
• Einsatz des UUID-Generators (UUID als englische Abkürzung von Universal Unique Identifier) zur Erzeugung eines UUID für jede der RPC-Schnittstellen (Block 1210);
• Einsatz der Interface Definition Language (IDL) zum Beschreiben der RPC-Schnittstellen für geplante Datentypen und entfernte Prozeduren (Block 1215);
• Erzeugen der Client- und Server-Stubs durch Kompilieren der IDL-Beschreibung unter Verwendung eines IDL-Kompilierers (Block 1220);
• Schreiben oder Modifizieren von Anwendungscode unter Verwendung einer Programmiersprache, die mit den RPC-Stubs kompatibel ist, so dass der Anwendungscode mit den Stubs funktionsfähig ist (Block 1225);
• Erzeugen von Objektcode aus Anwendungscode (Block 1230); und
• Verknüpfen der lokalen RPC-Laufzeitbibliothek und des aus dem Anwendungscode erzeugten Objektcodes zum Erzeugen von ausführbarem Code (Block 1235).

Die Abbildung aus 13 veranschaulicht allgemein die Verknüpfung der lokalen RPC-Laufzeitbibliothek und des aus dem Anwendungscode erzeugten Objektcodes. Für den Client werden der Objektcode des Client-Stubs 908, der Client-Anwendungscode oder der aufrufende Code 904 und die Client-RPC-Laufzeitbibliothek 910 unter Verwendung eines Binders bzw. Linkers 1302 verknüpft, um einen für den ausführbaren Client-Code 1304 zu erzeugen. Für den Server werden der Objektcode für den Server-Stub 918, der Initialisierungscode 1308 des Servers, der Server-Anwendungscode oder entfernte Prozeduren 914 und die Server-RPC-Laufzeitbibliothek 916 unter Verwendung des Binders bzw. Linkers 1302 verknüpft, um den ausführbaren Server-Code 1306 zu erzeugen.
Traditionell nutzen der aufrufende Code und die aufgerufenen Prozeduren den gleichen Adressraum. Bei einer RPC-Anwendung sind der aufrufende Code und die aufgerufenen entfernten Prozeduren nicht verknüpft; stattdessen kommunizieren sie über eine RPC-Schnittstelle indirekt miteinander. Eine RPC-Schnittstelle ist allgemein eine logische Gruppierung von Operationen, Datentypen und Konstanten, die als ein Kontrakt für eine Anordnung von entfernten Prozeduren fungiert. RPC-Schnittstellen werden für gewöhnlich aus formalen Schnittstellendefinitionen kompiliert, die von Anwendungsentwicklern unter Verwendung der Interface Definition Language (IDL) geschrieben werden.
Bei der Entwicklung einer verteilten Anwendung sollte eine Schnittstellendefinition in IDL definiert sein. Der IDL-Kompilierer verwendet allgemein die Schnittstellendefinition, um eine Header-Datei, eine Client-Stub-Datei und eine Server-Stub-Datei zu erzeugen. Der IDL-Kompilierer kann Header-Dateien in einer Standard-Programmiersprache erzeugen, und Stubs als Quellendateien oder als Objektdatei. Für bestimmte Anwendungen kann eine Attribute Configuration File (ACF) definiert werden, welche die Schnittstellendefinition begleitet. Wenn eine ACF existiert, interpretiert der IDL-Kompilierer die ACF, wenn er die Schnittstellendefinition kompiliert. Informationen in der ACF werden zur Modifikation des Codes verwendet, den der Kompilierer erzeugt.
Der Header jeder RPC-Schnittstelle weist für gewöhnlich einen Universal Unique Identifier (UUID) auf, der eine hexadezimale Zahl darstellt, die eine Instanz eindeutig identifiziert. Ein UUID, der eine RPC-Schnittstelle identifiziert, ist allgemein als ein Schnittstellen-UUID bekannt. Der Schnittstellen-UUID gewährleistet, dass die Schnittstelle in allen möglichen Netzwerkkonfigurationen eindeutig identifiziert werden kann. Zusätzlich zu einem Schnittstellen-UUID weist jede RPC-Schnittstelle höchste und niedrigste Versionsnummern auf. Gemeinsam bilden der Schnittstellen-UUID und die Versionsnummern einen Schnittstellenbezeichner, der eine Instanz einer RPC-Schnittstelle über Systeme und im Zeitverlauf identifiziert.
Benachrichtigungen
In erneutem Bezug auf die Abbildungen der 5A und 5B werden Objekte 502 in dem Browser allgemein synchronisiert mit entsprechenden oder gespiegelten Objekten 504, die durch den OM verwaltet werden, so dass Änderungen wiedergegeben werden können. Die Synchronisierung kann durch einen Mechanismus 528 für einen entfernten Prozeduraufruf (PRC) und einen Benachrichtigungsmechanismus 530 erfolgen.
Der Benachrichtigungsmechanismus 530 stellt allgemein das Mittel bereit, durch das Daten in einem Objekt 502 in dem Browser (z.B. JSSBusComp 518) aktualisiert werden können, wenn Daten oder Status bzw. Zustand in einem entsprechenden durch den OM verwalteten Objekt 504 verändert werden (z.B. CSSBusComp 510). In einem Ausführungsbeispiel würde das Objekt CSSSWEView 506 eine oder mehrere Benachrichtigungen sammeln und diese am Ende des Anzeigedarstellungszyklus zu den Objekten 502 in dem Browser senden.
In einem Ausführungsbeispiel können die folgenden beispielhaften oder veranschaulichenden Benachrichtigungen übermittelt werden. Hiermit wird festgestellt, dass bestimmte der nachstehend aufgeführten Benachrichtigungen Parameter benötigen. In andern Fällen kann der Rahmen den Kontext für diese Benachrichtigungen verstehen, indem er einfach deren aktuellen Zustand kennt.

• NotifyBeginNotifys – Zeigt den Anfang einer Reihe von Benachrichtigungen an.
• NotifyEndNotifts – Zeigt das Ende einer Reihe von Benachrichtigungen an.
• NotifyStateChanged – Zeigt an, dass sich der Zustand geändert hat. Ein beispielhaftes Szenario; in dem eine Zustandsänderung auftreten kann, ist es, wenn das System in einen Abfragezustand eintritt (wobei der Benutzer Abfragebedingungen eingeben, eine Abfrage ausführen kann) und danach in einen anstehenden Wegschreibezustand wechselt (in dem der Benutzer die Datenwerte aktualisieren kann).
• NotifyBeginQuery – Zeigt an, dass sich die Geschäftskomponente in einem Zustand befindet, der bereit ist, Abfragezustände anzunehmen.
• NotifyExecute – Zeigt an, dass die Geschäftskomponente ausgeführt worden ist (d.h. eine Abfrage in der Datenbank ausgeführt hat und sich wieder selbst mit neuen Daten gefüllt hat). Diese Benachrichtigung kann optionale Parameter zur Bereitstellung von Abfragespezifikationen aufweisen.
• NotifyEndQuery – Zeigt an, dass eine Abfrage vollständig ausgeführt worden ist.
• NotifyDeleteRecord – Zeigt an, dass ein Datensatz aus der Datenbank gelöscht worden ist.
• NotifyDeleteWorkSet – Zeigt an, dass ein Datensatz aus der arbeitenden Anordnung entfernt worden ist. Diese Benachrichtigung kann einen Parameter aufweisen, der den Index der aktiven Gruppenzeile bereitstellt, die entfernt werden muss.
• NotifyInsertWorkSet – Zeigt an, dass ein Datensatz der aktuell aktiven Gruppe bzw. Anordnung hinzugefügt worden ist. Diese Benachrichtigung kann Parameter aufweisen, um den Index des neuen Datensatzes in der aktiven Anordnung bereitzustellen.
• NotifyInsertWSFieldVals – Zeigt an, dass ein bzw. mehrere bestimmte Wert(e) einem Feld in der aktiven Anordnung hinzugefügt werden muss bzw. müssen.
• NotifyNewActiveField – Zeigt an, dass ein neues Feld aktiv bzw. aktuell ist.
• NotifyNewActiveRow – Zeigt an, dass eine neue Zeile (d.h. Datensatz) aktiv bzw. aktuell ist.
• NotifyNewData – Zeigt an, dass die Daten geändert worden sind.
• NotifyNewDataWS – Zeigt an, dass die Daten in der aktiven Anordnung geändert worden sind.
• NotifyNewFieldData – Zeigt an, dass ein bestimmtes Feld neue Daten aufweist. Diese Benachrichtigung weist Parameter auf, die den Namen des Felds bereitstellen.
• NotifyNewFieldQuerySpec – Zeigt an, dass ein bestimmtes Feld eine neue Abfrage oder Suchspezifikation aufweist.
• NotifyNewPrimary – Zeigt an, dass ein neuer Datensatz zu dem primären Datensatz geworden ist.
• NotifyNewRecord – Zeigt an, dass ein neuer Datensatz erstellt worden ist.
• NotifyNewRecordData – Zeigt an, dass ein neu erstellter Datensatz neue Daten aufweist.
• NotifyNewRecordDataWS – Zeigt an, dass ein neu erzeugter Datensatz neue Daten aufweist, die in die aktive Anordnung aufgenommen werden sollen.
• NotifyNewSelection – Zeigt die Auswahl und Aufhebung der Auswahl eines Datensatzes an.
• NotifyNewSellds – Zeigt die Auswahl mehrerer Datensätze an.
• NotifyPageRefresh – Zeigt an, dass der UI erneuert werden muss. Diese Benachrichtigung wird für gewöhnlich eingesetzt, wenn eine allgemein substantielle Veränderung des UI außer der Aktualisierung von Daten erforderlich ist. Diese Benachrichtigung kann eine Serverauslösung zur Erfassung einer neuen Seite und zu deren Anzeige in dem Browser bewirken.
• NotifyScrollData – Zeigt an, dass die Datensätze nach oben oder nach unten einem Bildlauf unterzogen werden müssen. Bestimmte Benutzeroberflächenobjekte, wie etwa Listen-Applets, können diese Benachrichtigung einsetzen, um einen Bildlauf nach oben oder nach unten vorzunehmen, um verschiedene Zeilen zu zeigen.
• NotifyChangeSelection – Zeigt an, dass die Datensatzauswahl geändert worden ist (d.h. die aktuelle Zeile wurde entweder ausgewählt oder deren Auswahl aufgehoben).
• NotifySelModeChange – Zeigt eine Änderung in dem Auswahlmodus an. In einem Ausführungsbeispiel gibt es zwei mögliche Auswahlmodi, (i) die Auswahl jeweils eines Datensatzes gleichzeitig und (ii) die gleichzeitige Auswahl mehrerer Datensätze (z.B. Löschen mehrerer Datensätze mittels eines Befehls).
• NotifyTotalsChanged – Zeigt an, dass die Gesamtwerte geändert werden müssen. Wenn mehrere Datensätze angezeigt werden, können in bestimmten Fällen einige Felder auch die Summierung der Werte in allen Datensätzen anzeigen. Diese Benachrichtigung zeigt an, dass sich der Gesamtwert geändert hat.
• NotifyLongOpProgress – Zeigt an, dass eine lange (d.h. zeitaufwändige) Aktion gerade ausgeführt wird. Diese Benachrichtigung wird von der Benutzeroberfläche eingesetzt, um dem Benutzer Feedback zu geben, wie etwa die Darstellung einer Fortschritts- oder Statusleiste, die zeigt, welcher Teil der Aufgabe aktuell ausgeführt worden ist.
• NotifyGeneric – Dies ist eine generische Benachrichtigung, die eingesetzt wird, um das Benutzeroberflächenobjekt über bestimmte besondere Bedingungen zu benachrichtigen, die nicht durch die aufgeführte und vorstehend beschriebene Liste von Benachrichtigungen abgedeckt werden. Jede Art der generischen Benachrichtigung kann einen Parameter aufweisen, der einen Namen für die generische Benachrichtigung bereitstellt, so dass eine Art der generischen Benachrichtigung von einer anderen Art der generischen Spezifikation unterschieden werden kann. Jede Art der generischen Benachrichtigung kann eigene Parameter aufweisen.

Allgemeine Kommunikationsprozesse
Wie dies bereits vorstehend im Text beschrieben worden ist, können Objekte in dem Browser und durch den OM verwaltete Objekte so konfiguriert werden, dass sie sich auf einer oder mehreren Computervorrichtungen befinden und dort arbeiten. Wie dies vorstehend beschrieben worden ist, zeigt die Abbildung aus 6A eine beispielhafte Konfiguration 600, bei der die Objekte 502 in dem Browser und durch den OM verwaltete Objekte 504 auf mehreren Computervorrichtungen 602 und 604 angeordnet sind und dort arbeiten, wobei die Vorrichtungen einen Client 602 und einen Server 604 aufweisen. Die Abbildung aus 6B veranschaulicht eine beispielhafte Konfiguration 650, bei der Objekte 502 in dem Browser und durch den OM verwaltete Objekte 504 sich auf einer Computervorrichtung 652 befinden und dort arbeiten.
Die Abbildung aus 14 veranschaulicht allgemein einen beispielhaften Prozess 1400 der Kommunikation zwischen den Objekten 502 auf Browser-Seite oder Client-Seite und den Objekten 504 auf Server-Seite, die in einer Konfiguration 600 mit mehreren Vorrichtungen gemäß der Abbildung aus 6A ausgeführt werden. Der beispielhafte Prozess 1400 der Kommunikation aus 14 erfolgt für gewöhnlich durch Benutzereingabe und wird zuerst an einem Applet auf Browser-Seite behandelt, dem JSSApplet (Block 1405). Wenn der Benutzer einen Link oder ein Merkmal auf der Benutzeroberfläche anklickt, wird ein Aufrufverfahren erzeugt. Das JSSApplet ist für gewöhnlich das erste Objekt, das das erzeugte Aufrufverfahren empfängt (Block 1410). Das JSSApplet kann danach einen entfernten Prozeduraufruf ausgeben, über JSSApplication, um das Aufrufverfahren erneut in Bezug auf das Applet auf Serverseite anzusprechen, CSSWEApplet (Block 1415). Das angesprochene Applet auf Serverseite, CSSWEApplet, kann allgemein auf ein RPC-Aufrufverfahren von dem Applet auf Browser-Seite, JSSApplet, ansprechen, indem eine Statusflagge gesetzt wird (Block 1420). In einem Ausführungsbeispiel kann die Statusflagge auf einen der folgenden Werte gesetzt werden:

• Continue – (Fortsetzen) Dieser Wert zeigt allgemein an, dass das Applet auf Serverseite, CSSWEApplet, seinen Teil der Behandlung des Aufrufverfahrens ausgeführt hat (oder keine auszuführende Rolle aufweist), und dass JSSApplet in dem Browser die Aktion abschließen muss. Benachrichtigungen werden in der Antwort bereitgestellt, sind jedoch häufig leer.
• Completed – (Abgeschlossen) Dieser Wert zeigt allgemein an, dass das Applet auf Serverseite die Behandlung des Aufrufverfahrens abgeschlossen hat, und dass der Browser keine weitere Maßnahme bzw. Aktion ausführen muss, als auch in der Antwort bereitgestellte Benachrichtigungen zu antworten.
• NewPage – (Neue Seite) Dieser Wert zeigt allgemein an, dass die Antwort auf die Aufuranforderung bzw. die Anforderung Aufrufen oder einen anderen Befehl eine Seitenaktualisierung erfordert, einschließlich der erneuten Erzeugung aller temporären Objekte auf Browser-Seite. Eine URL wird an den Browser gesendet, so dass die neue Seite erhalten werden kann. Es gibt jedoch keine Benachrichtigungen. Dieser Wert wird für gewöhnlich in Fällen gesetzt, wie etwa wenn ein Tiefergehen auf eine andere Ansicht angefordert wird.
• Error – (Fehler) Dieser Wert zeigt allgemein an, dass die Anforderung für das Aufrufverfahren fehlgeschlagen ist. Nach dem Empfang eines Status Fehler (Error), zeigt das JSSApplet für gewöhnlich eine Fehlerseite an.

Wenn ein Applet auf Browser-Seite, JSSApplet, den Server über die RPC aufruft, prüft das Applet auf Browser-Seite für gewöhnlich die Statusflagge in der Antwort und behandelt diese dann (Block 1425). Wenn der zurückgegebene Status Fehler (Error) lautet, zeigt das Applet auf Browser-Seite eine Fehlerseite an. Wenn der zurückgegebene Status Abgeschlossen (Completed) lautet, zeigt der Server allgemein an, dass er das Aufrufverfahren bereits behandelt hat und dass für den Browser nichts mehr zu tun ist. Wenn der zurückgegebene Status Fortsetzen (Continue) lautet, zeigt der Server allgemein an, dass er das Aufrufverfahren nicht behandelt. Das Applet auf Browser-Seite würde allgemein auf einen zurückgegebenen Status Fortsetzen ansprechen, indem das Verfahren zu dem Objekt JSSBusComp umgeleitet wird, durch Aufrufen des Verfahrens direkt an dem Objekt JSSBusComp. Das Objekt JSSBusComp kann in der Lage sein, die Aufrufverfahrenanforderung zu erfüllen oder es kann seinen eigenen RPC-Aufruf über JSSApplication an die entsprechende Geschäftskomponente auf Serverseite senden müssen.
Die Abbildung aus 15 zeigt einen beispielhaften Prozess 1500 der Kommunikation, wobei das Applet auf Browser-Seite das Verfahren direkt an dem Objekt JSSBusComp aufruft. Hiermit wird festgestellt, dass der Prozess 1500 aus 15 nachstehend so beschrieben wird, als wäre der Prozess in einer Konfiguration mit mehreren Vorrichtungen gemäß der Abbildung aus 6A aufgetreten. In Block 1505 leitet das Applet auf Browser Seite, JSSApplet, das Verfahren zu dem Objekt JSSBusComp um. In dem Block 1510 würde danach das Geschäftskomponentenobjekt auf Client-Seite, JSSBusComp, einen entfernten Prozeduraufruf über das Objekt JSSApplication an eine Geschäftskomponente auf Serverseite, CSSBusComp, ausgeben. Die Geschäftskomponente auf Serverseite verarbeitet allgemein den RPC-Verfahrensaufruf, legt einen Status fest und sendet diesen zurück, und sie gibt ferner eine Reihe von Benachrichtigungen in entsprechenden Situationen zurück (Block 1515). In einem Ausführungsbeispiel kann die Statusflagge die folgenden Werte aufweisen:

• Completed – (Abgeschlossen) Dieser Wert zeigt allgemein an, dass die Geschäftskomponente auf Serverseite, CSSBusComp, das Aufrufverfahren allgemein erfolgreich abgeschlossen hat. Für gewöhnlich treten Benachrichtigungen auf.
• Error – (Fehler) Dieser Wert zeigt allgemein an, dass die Geschäftskomponente auf Serverseite, CSSBusComp, den Aufruf für das Aufrufverfahren erfolglos verarbeitet hat. Nach dem Empfang eines Status Fehler (Error), zeigt der Browser für gewöhnlich eine Fehlerseite an.

In dem Block 1520 prüft die Geschäftskomponente auf Client-Seite (JSSBusComp) die zurückgegebene Statusflagge und reagiert bzw. antwortet entsprechend. Hiermit wird festgestellt, dass der Server kontaktiert wird, wenn ein Aufruf für einen Verfahrensaufruf Aktionen ausführt, die eine Synchronisierung zwischen den Geschäftskomponenten des Browsers und des Servers erfordern. Hiermit wird ferner festgestellt, dass Umstände gegeben sein können, unter denen das Objekt JSSBusComp in der Lage sein kann, die Anforderung lokal zu behandeln, ohne dass Kontakt zu dem Server aufgenommen werden muss. Ein Beispiel für derartige Umstände ist es, wenn der Benutzer eine Operation der nächsten Datensatzaufzeichnung ausführt und danach eine Operation des Aufzeichnens eines vorherigen Datensatzes, ohne dabei Daten zu ändern.
Verfahren, die potenziell durch Objekte der Browser-Seite unterstützt werden In einem Ausführungsbeispiel können die Verfahren, die potenziell durch die Objekte auf Browser-Seite unterstützt werden können, in die folgenden Kategorien unterteilt werden: grundlegende Objektverfahren, Anwendungsverfahren, Geschäftskomponentenverfahren, Dienstverfahren und Applet-Verfahren. Zu Veranschaulichungszwecken werden nachstehend beispielhafte Verfahren aufgeführt und allgemein beschrieben.
Die meisten Objekte der Browser-Seite weisen für gewöhnlich die folgenden grundlegenden Objektverfahren auf:
AddErrorMsg(errcode, params, append)

Allgemeine Beschreibung: Fügt der Fehlerkette für das aktuelle Objekt eine Fehlernachricht hinzu.

AddErrorMsgText(errCode, errMsg, append)

ClearErrorMsg()

Allgemeine Beschreibung: Löscht die Fehlerkette für das aktuelle Objekt.

CopyErrormsg(inputObject)

Allgemeine Beschreibung: Kopiert die Fehlerkette von dem weitergeleiteten Objekt, inputobject, zu dem aktuellen Objekt.

FormatString(format, parameters)

Allgemeine Beschreibung: Ersetzt Parameter in das Format durch Ersetzen von "%W' in dem Format mit dem äquivalenten Parameter gemäß der Spezifikation in der Parameteranordnung.

GetApplication()

Allgemeine Beschreibung: Gibt das globale Anwendungsobjekt zurück.

GetErrorCode()

Allgemeine Beschreibung: Gibt den obersten Fehlercode in der Fehlerkette zurück. Ein Fehlercode ist allgemein eine Folge (String) Eine leere Zeichenfolge zeigt für gewöhnlich an, dass kein Fehler vorliegt.

GetErrorCount()

Allgemeine Beschreibung: Gibt die Länge der Fehlerkette für das aktuelle Objekt zurück.

GetErrorMsg(index)

Allgemeine Beschreibung: Gibt die n-te Fehlernachricht-Textfolge von der Fehlerkette für das aktuelle Objekt zurück. Hiermit wird festgestellt, dass der Index auf Null basiert.

GetNthErrorCode(index)

Allgemeine Beschreibung: Gibt den n-ten Fehlercode von der Fehlerkette für das aktuelle Objekt zurück.

HasErrorMsg()

Allgemeine Beschreibung: Prüft, um festzustellen, ob das aktuelle Objekt etwaige registrierte Fehler aufweist.

LockErrorMsg()

Allgemeine Beschreibung: Verhindert die Registrierung oder das Löschen weiterer Fehler für das aktuelle Objekt.

SetErrorMog(errCode, params, child)

Allgemeine Beschreibung: Registriert einen Fehler in dem aktuellen Objekt. ErrCode ist allgemein ein registrierter Schlüssel in der Nachrichtentabelle und abgebildet in eine Fehlernachrichtformat-Zeichenfolge. Params kann Null entsprechen, wenn das Format keine Parameter verwendet, wenn eine Anordnung die Zeichenfolgen-Parameterwerte aufweist oder wenn ein einzelner Wert für "%1" ersetzt wird.

SetErrorMsgText(errCode, errMsg)

Allgemeine Beschreibung: Registriert einen Fehler in dem aktuellen Objekt.

TextToHTML(text)

Allgemeine Beschreibung: Gibt eine HTML-sichere Zeichenfolge für den eingegebenen Text zurück.

TranslateError(errCode, params)

Allgemeine Beschreibung: Gibt eine formatierte Zeichenfolge für den spezifizierten Nachrichtenschlüssel und die Parameter zurück.

UnLockErrorMsg()

Allgemeine Beschreibung: Nimmt die Behandlung der Fehlerregistrierung und Löschung an dem aktuellen Objekt wieder auf.

In einem Ausführungsbeispiel kann jedes Anwendungsobjekt auf Browser-Seite für gewöhnlich die folgenden Anwendungsverfahren unterstützen:
AddBusobj(busObj)

Allgemeine Beschreibung: Fügt BusObj für die Instantiierung einer Ansicht hinzu. Der Aufruf erfolgt nur durch SWE.

AddRowCounterTemplate (key, templ)

Allgemeine Beschreibung: Fügt die Zeichenfolgenformatvorlage für eines der möglichen Zeilenzählerformate hinzu.

AddView(view)

Allgemeine Beschreibung: Fügt ein neues Ansichtobjekt hinzu.

CanInvokeMethod(name)

Allgemeine Beschreibung: Verifiziert, ob ein bestimmtes Verfahren aufgerufen werden kann.

ClosePOPUP()

Allgemeine Beschreibung: Schließt das aktive Popup-Applet/Steuerung.

CreateObj(jssObjName)

Allgemeine Beschreibung: Erzeugt ein JavaScript-Objekt bei gegebenem Typennamen.

DispatchBCNotifications(returnPropSet)

Allgemeine Beschreibung: Leitet durch RPC an den SWE-Server zurückgegebene Benachrichtigungen an die entsprechenden BusComp-Instanzen.

EnumBusObjs(first)

Allgemeine Beschreibung: Iteriert durch die mit der Anwendung registrierten Geschäftsobjekte.

EnumServices(first)

Allgemeine Beschreibung: Iteriert durch die durch den Client geladenen Dienste.

EnumViews(first)

Allgemeine Beschreibung: Iteriert durch die mit der Anwendung registrieren Ansichten.

GetBusObj(name)

Allgemeine Beschreibung: Gibt ein Geschäftsobjekt nach Namen zurück.

GetBusObjZone(zone)

Allgemeine Beschreibung: Gibt die "Zone" der Web Engine (WE) zurück, die einem Geschäftsobjekt zugeordnet ist.

GetCommandMgr()

Allgemeine Beschreibung: Gibt den Befehlsmanager auf oberster Ebene zurück, der UI-Befehle für Symbolleisten und Menüs behandelt und ausgibt.

GetEditCaption()

Allgemeine Beschreibung: Gibt den Text für Applets im Bearbeitungsmodus zurück.

GetEditCtlType()

Allgemeine Beschreibung: Gibt die Steuerart für Applets im Bearbeitungsmodus zurück.

GetHtmlFrameMgr()

Allgemeine Beschreibung: Gibt das Objekt zurück, das Frames bzw. Rahmen zum Herunterladen von neuem Inhalt verwaltet.

GetJSSInfo(busObjZone, appletName, url)

Allgemeine Beschreibung: Verwendet den HTML-Frame-Manager zum Laden der spezifizierten URL.

GetLocalString(key)

Allgemeine Beschreibung: Gibt die umgesetzte bzw. übersetzte Zeichenfolge für den spezifizierten Schlüssel zurück. Die übersetzten Zeichenfolgen werden für gewöhnlich in der Nachrichtentabelle gespeichert und beim Hochfahren in den Client geladen.

GetLocale()

Allgemeine Beschreibung: Gibt das regionale Objekt zurück.

GetMainView()

Allgemeine Beschreibung: Gibt die aktuelle Ansicht der Anwendung zurück.

GetPageURL()

Allgemeine Beschreibung: Gibt die URL für die aktuelle Seite der obersten Ebene zurück.

GetProfileAttr(attrName)

Allgemeine Beschreibung: Gibt den Wert des benannten Profilattributs auf dem Server zurück.

GetRowCounterTemplate(key)

Allgemeine Beschreibung: Gibt die Zeichenfolgenformatvorlage für eines der Zeilenzählerformate zurück.

GetService(name)

Allgemeine Beschreibung: Lädt ein spezifiziertes Dienstobjekt lokal und auf dem Server. Wenn der spezifizierte Dienst bereits geladen ist, wird nur der Referenzzählwert erhöht.

GetView(busObjZone)

Allgemeine Beschreibung: Holt die Ansicht, die einer "Zone" eines Geschäftsobjekts entspricht.

InvokeMethod(name, inputPropSet)

Allgemeine Beschreibung: Ruft das bezeichnete Verfahren an der Anwendung auf.

ProcessClosePopup(returnPropSet)

Allgemeine Beschreibung: Schließt das Popup wenn gepostet.

ProcessConfirmDialog(errObj, returnPropSet)

Allgemeine Beschreibung: Behandelt einen Bestätigungsdialog wie gepostet.

ProcessError(object)

Allgemeine Beschreibung: Holt einen Fehlerdialog hoch für den an dem jeweiligen Objekt registrierten Fehler.

ProcessNewPage(returnPropSet)

Allgemeine Beschreibung: Ruft die Erzeugung einer neuen Seite wie gepostet auf.

ProcessRPCErrors(errObj, returnPropSet)

Allgemeine Beschreibung: Behandelt Fehler, die durch einen Aufruf an die Web Engine auf dem Server zurückgegeben werden.

ProcessRPCNotifications(errObj, returnPropSet)

Allgemeine Beschreibung: Behandlet Benachrichtigungen, die in einem Aufruf an die Web Engine zurückgegeben werden.

ProcessRPCRetPropSetStr(errObj, returnPropSetStr)

Allgemeine Beschreibung: Behandelt die zurückgegebene Eigenschaftsanordnung von einem Aufruf der Web Engine.

ReleaseService(service)

Allgemeine Beschreibung: Gibt den Dienst unmittelbar frei, unabhängig von dem Referenzzählwert.

RemoveBusObj(busObj)

Allgemeine Beschreibung: Entfernt ein Geschäftsobjekt der Liste der aktiven Objekte.

RemoveObjFromArray(obj, arrayObj)

Allgemeine Beschreibung: Entfernt ein Objekt aus einer Anordnung von Objekten.

WEAppletCanInvoke(appletName, viewName, busObjZone, method)

Allgemeine Beschreibung: Ruft die Web Engine auf, um zu bestimmen, ob ein Verfahren an einem Applet aufgerufen werden kann.

WEApplicationCanInvoke(method)

Allgemeine Beschreibung: Ruft die Web Engine auf, um zu bestimmen, ob ein Verfahren in einer Anwendung aufgerufen werden kann.

WEBusCompCanInvoke(busCompName, busObjZone, method)

Allgemeine Beschreibung: Ruft die Web Engine auf, um zu bestimmen, ob ein Verfahren an einer Geschäftskomponente aufgerufen werden kann.

WECallApplet(appName, viewName, busObjZone, method, inputPropSet)

Allgemeine Beschreibung: Ruft die Web Engine auf, um einen spezifizierten entfernten Prozeduraufruf an einem Applet aufzurufen.

WECallApplication(method, inputPropSet)

Allgemeine Beschreibung: Ruft die Web Engine auf, um einen spezifizierten entfernten Prozeduraufruf in einer Anwendung aufzurufen.

WECailBusComp(busCompName, busObjZone, method, inputPropSet)

Allgemeine Beschreibung: Ruft die Web Engine auf, um einen spezifizierten entfernten Prozeduraufruf an einer Geschäftskomponente aufzurufen.

WECallService (serviceName, method, inputPropSet)

Allgemeine Beschreibung: Ruft die Web Engine auf, um einen spezifizierten entfernten Prozeduraufruf in einem Dienst aufzurufen.

WELoadService(name)

Allgemeine Beschreibung: Ruft die Web Engine auf, um einen neuen Dienst zu laden.

WEServiceCanInvoke(serviceName, method)

Allgemeine Beschreibung: Ruft die Web Engine auf, um zu bestimmen, ob ein Verfahren in einem Dienst aufgerufen werden kann.

SetEditCaption(editCaption)

Allgemeine Beschreibung: Legt den für den Bearbeitungsmodus verwendeten Text fest.

SetEditCtlType(editCtlType)

Allgemeine Beschreibung: Legt den verwendeten Steuerungstyp für den Bearbeitungsmodus fest.

SetHtmlFrameMgr(htmlFrameMgr)

Allgemeine Beschreibung: Legt die HTML-Frame-Manager-Instanz fest.

SetMain View(view)

Allgemeine Beschreibung: Definiert die Hauptansicht.

SetPageURL(pageUrl)

Allgemeine Beschreibung: Legt die Basis-URL für die Anwendung fest.

SetProfileAttr(attrName, value)

Allgemeine Beschreibung: Ändert das benannte Benutzerprofilattribut in den spezifizierten Wert.

SetWSFrame(wsFrameName)

Allgemeine Beschreibung: Definiert einen besonderen Rahmen bzw. Frame für den HTML-Frame-Manager.

ShowPopup(url, height, width)

Allgemeine Beschreibung: Bringt ein Popup-Applet oder eine entsprechende Steuerung hervor.

In einem Ausführungsbeispiel kann jede Geschäftskomponente auf der Browser-Seite für gewöhnlich die folgenden Geschäftskomponentenverfahren unterstützen:
AddField(name, ...)

Allgemeine Beschreibung: Spezifiziert die Konfigurationsinformationen für die Felder, wenn die Geschäftskomponente initialisiert wird.

AddPickList(fieldName, picklist)

Allgemeine Beschreibung: Spezifiziert die Auswahllistenkonfiguration für Felder, wenn die Geschäftskomponente initialisiert wird.

AddRecord(record)

Allgemeine Beschreibung: Spezifiziert anfängliche Datensatzdaten, wenn die Geschäftskomponente initialisiert wird.

AddUserProp(propName, value)

Allgemeine Beschreibung: Spezifiziert die konfigurierten Benutzereigenschaften für die Geschäftskomponente während der Initialisierung.

AddField UserProp(fieldName,propName, value)

Allgemeine Beschreibung: Spezifiziert die konfigurierten Benutzereigenschaften für ein Feld während der Initialisierung der Geschäftskomponente.

CallServerBC(method, inputProps)

Allgemeine Beschreibung: Sendet ein Verfahren an die Geschäftskomponente auf dem Server.

CanDelete()

Allgemeine Beschreibung: Bestimmt, ob der Benutzer den aktuellen Datensatz aus der aktuellen Geschäftskomponente löschen kann.

CanInsert(dynamic)

Allgemeine Beschreibung: Bestimmt, ob ein neuer Datensatz in die aktuelle Geschäftskomponente eingefügt werden kann.

CanInvokeMethod(Method)

Allgemeine Beschreibung: Bestimmt, ob das bezeichnete Verfahren auf der aktuellen Geschäftskomponente aufgerufen werden kann.

CanMergeRecords()

Allgemeine Beschreibung: Bestimmt, dass der Benutzer Datensätze in der aktuellen Geschäftskomponente zusammenführen kann.

CanQuery()

Allgemeine Beschreibung: Bestimmt, ob die aktuelle Geschäftskomponente Abfragen unterstützt.

CanUpdate(dynamic)

Allgemeine Beschreibung: Bestimmt, ob der aktuelle Datensatz aktualisiert werden kann.

CanUpdateField(fieldName)

Allgemeine Beschreibung: Bestimmt, ob ein spezifiziertes Feld aktualisiert werden kann.

Cleanup()

Allgemeine Beschreibung: Führt eine Säuberung durch, bevor Objekte zerstört werden.

ClearUpdates()

Allgemeine Beschreibung: Entfernt ausstehende Aktualisierungen des aktuellen Datensatzes, die noch nicht an den Server übermittelt worden sind.

CopyRecord(before)

Allgemeine Beschreibung: Erstellt einen neuen Datensatz und kopiert die Werte des aktuellen Datensatzes in den neuen Datensatz.

DeleteRecord()

Allgemeine Beschreibung: Löscht den aktuellen Datensatz.

DisableNotify()

Allgemeine Beschreibung: Hält Benachrichtigungsnachrichten zurück.

EnableNotift()

Allgemeine Beschreibung: Nimmt das Senden von Benachrichtigungsnachrichten wieder auf.

End()

Allgemeine Beschreibung: Verschiebt den aktuellen Datensatz zu dem letzten Datensatz.

EnumPields(first)

Allgemeine Beschreibung: Iteriert durch die an der Geschäftskomponente definierten Felder.

EnumUserProps(start)

Allgemeine Beschreibung: Iteriert durch die an der Geschäftskomponente definierten Benutzereigenschaften.

EnumFieldUserProps(start, fieldName)

Allgemeine Beschreibung: Iteriert durch die an dem bezeichneten Feld definierten Benutzereigenschaften.

GetActiveFieldArray()

Allgemeine Beschreibung: Gibt eine Anordnung von Namen der aktuell aktiven Felder zurück.

GetActiveRow()

Allgemeine Beschreibung: Gibt den Index in die ausgeführte Anordnung der aktuellen Zeile zurück.

GetBusObj()

Allgemeine Beschreibung: Gibt das Geschäftsobjekt zurück, das Eigentümer der aktuellen Geschäftskomponente ist.

GetFieldDef(fieldName)

Allgemeine Beschreibung: Gibt das Feldobjekt für das bezeichnete Feld zurück.

GetFieldIndex(fieldName)

Allgemeine Beschreibung: Gibt den Index in die Feldanordnung und Datensatzanordnungen für das jeweilige Feld zurück.

GetIdValue()

Allgemeine Beschreibung: Gibt den Zeilen-ID-Wert für den aktuellen Datensatz zurück.

GetFieldTotal(fieldName)

Allgemeine Beschreibung: Gibt den Gesamtwert für das bezeichnete Feld zurück.

GetFieldValue(fieldName)

Allgemeine Beschreibung: Gibt den Wert für das bezeichnete Feld aus der aktuellen Zeile zurück.

GetFormattedValue(fieldName, format)

Allgemeine Beschreibung: Gibt den Wert für das bezeichnete Feldaus der aktuellen Zeile zurück, formatiert für die aktuellen regionalen Einstellungen und gemäß des Feldtyps.

GetLocale()

Allgemeine Beschreibung: Gibt das regionale Objekt für das System zurück.

GetName()

Allgemeine Beschreibung: Gibt den Namen der Geschäftskomponente zurück.

GetNotifyObj(ntfyid)

Allgemeine Beschreibung: Gibt das Benachrichtigungsobjekt für die jeweilige ID zurück.

GetNumRows()

Allgemeine Beschreibung: Gibt den Zählwert der Zahle der Zeilen zurück, wie dies die aktuelle Geschäftskomponente sieht.

GetParentBC()

Allgemeine Beschreibung: Gibt die Mutter-Geschäftskomponente der aktuellen Geschäftskomponente zurück, sofern verfügbar.

GetPickList(fieldName)

Allgemeine Beschreibung: Gibt das Auswahllistenobjekt für das bezeichnete Feld zurück.

GetRowNum()

Allgemeine Beschreibung: Gibt die Zeilenzahl zurück.

GetSearchSpec()

Allgemeine Beschreibung: Gibt die für die aktuelle Abfrage effektive Suchspezifikation zurück.

GetFieldSearchSpec(fieldName)

Allgemeine Beschreibung: Gibt die für das spezifizierte Feld effektive Suchspezifikation zurück.

GetSortSpec()

Allgemeine Beschreibung: Gibt die für die aktuelle Abfrage effektive Sortierungsspezifikation zurück.

GetUserProp(propname)

Allgemeine Beschreibung: Gibt den Wert der bezeichneten Benutzereigenschaft an der aktuellen Geschäftskomponente zurück.

GetField UserProp(fieldName, propName)

Allgemeine Beschreibung: Gibt den Wert der bezeichneten Benutzereigenschaft an dem spezifizierten Feld zurück.

HandleServerNotification(propSet)

Allgemeine Beschreibung: Verarbeitet Benachrichtigungsnachrichten von dem Server für die aktuelle Geschäftskomponente. Dieses Verfahren sammelt Informationen, die von dem Server zurückgeleitet werden, um dessen internen Zustand zu aktualisieren. Breitet auch die Benachrichtigungen in geeigneter Weise aus.

HasPickList(fieldName)

Allgemeine Beschreibung: Bestimmt, ob ein bestimmtes Feld eine definierte Auswahlliste aufweist.

HasFieldTotals()

Allgemeine Beschreibung: Bestimmt, ob die Geschäftskomponente Gesamtwerte für alle etwaigen Felder berechnen kann.

Home()

Allgemeine Beschreibung: Legt die aktuelle Zeile als die erste Zeile in der Abfrage fest.

Initialize()

Allgemeine Beschreibung: Richtet den Status der Geschäftskomponente ein, nachdem diese vollständig geladen worden ist und bevor sie eingesetzt wird.

InvokeMethod(name, inputPropSet)

Allgemeine Beschreibung: Ruft das bezeichnete Verfahren an der aktuellen Geschäftskomponente auf.

IsCurWSRecActive(ntfyid)

Allgemeine Beschreibung: Bestimmt, ob es sich bei dem aktuellen Datensatz des Benachrichtigungsobjekts um den aktuellen Datensatz in der aktiven Anordnung der Geschäftskomponente handelt.

IsCurWSRecSelected(ntfyid)

Allgemeine Beschreibung: Bestimmt, ob der aktuelle Datensatz in dem Benachrichtigungsobjekt in der Geschäftskomponente ausgewählt worden ist.

IsNumRowsKnown()

Allgemeine Beschreibung: Bestimmt, ob die Gesamtanzahl der Datensätze der Abfrage bekannt sit.

NextRecord()

Allgemeine Beschreibung: Verschiebt den aktuellen Datensatz in der Geschäftskomponente zu dem nächsten Datensatz in der Abfrage.

NextSet()

Allgemeine Beschreibung: Führt einen Bildlauf der aktiven Anordnung aus.

NewActiveRow(index)

Allgemeine Beschreibung: Aktualisiert den internen Zustand, wenn sich die aktuelle Zeile ändert.

NewFieldData(fieldName, value)

Allgemeine Beschreibung: Aktualisiert den internen Zustand, wenn ein Feldwert auf dem Server verändert wird.

NewRecord(before)

Allgemeine Beschreibung: Erzeugt einen neuen Datensatz in der Geschäftskomponente mit Standard-Feldwerten.

PositionByid(id)

Allgemeine Beschreibung: Lokalisiert den Datensatz in der aktuellen Abfrage mit der spezifizierten Zeilen-ID (ROW-ID) und macht sie zu dem aktuellen Datensatz.

PriorRecord()

Allgemeine Beschreibung: Verschiebt den aktuellen Datensatz in der aktuellen Abfrage um eine Zeile zurück.

PriorSet()

Allgemeine Beschreibung: Führt einen Bildlauf der aktiven Anordnung nach oben aus.

RedoRecord()

Allgemeine Beschreibung: Wendet vorher entfernte Änderungen erneut an.

RegNotifyObj(notify)

Allgemeine Beschreibung: Registriert ein Benachrichtigungsobjekt mit der Geschäftskomponente.

SetActiveRow(row)

Allgemeine Beschreibung: Setzt die aktuelle Zeile in der Geschäftskomponente auf den spezifizierten Index in der aktiven Anordnung fest.

SetBusObj(busObj)

Allgemeine Beschreibung: Setzt das Geschäftsobjekt fest, das die aktuelle Geschäftskomponente besitzt bzw. beherrscht.

SetFieldValue(fieldName, value)

Allgemeine Beschreibung: Ändert den Wert in dem aktuellen Datensatz auf den gegebenen Wert.

SetFormattedValue(FieldName, value, format)

Allgemeine Beschreibung: Legt den Wert des spezifzierte Felds in dem aktuellen Datensatz auf den bestimmten Wert fest.

SetName(name)

Allgemeine Beschreibung: Legt den Namen der Geschäftskomponente fest.

SetParentBC(busComp)

Allgemeine Beschreibung: Legt die Mutter-Geschäftskomponente für einen Abkömmling fest.

SetSearchSpec(spec)

Allgemeine Beschreibung: Legt die für die anfängliche Abfrage effektive Suchspezifikation fest.

SetFieldSearchSpec(fieldName, spec)

Allgemeine Beschreibung: Legt die für das spezifische Feld effektive Suchspezifikation fest.

SetSortSpec(spec)

Allgemeine Beschreibung: Legt die geltende Sortierungsspezifikation für die anfängliche Abfrage fest.

SetTotalsRecord(record)

Allgemeine Beschreibung: Legt den Datensatz fest, der die Gesamtwerte für die aktuelle Abfrage aufweist.

SetWorkSetSize(ntfyid, size)

Allgemeine Beschreibung: Legt die Anzahl der Datensätze fest, die in der aktiven Anordnung für ein spezifiziertes Benachrichtigungsobjekt angezeigt werden.

toString()

Allgemeine Beschreibung: Gibt eine Zeichenfolge zurück, die den Namen der Geschäftskomponente aufweist.

UndoRecord()

Allgemeine Beschreibung: Macht alle Änderungen seit dem letzten Aufruf von WriteRecord() rückgängig.

UnRegNotifyObj(ntfyid)

Allgemeine Beschreibung: Entfernt die Registrierung des durch die ID spezifizierten Benachrichtigungsobjekts.

UpdateRecord()

Allgemeine Beschreibung: Füg den aktuellen Datensatz in einen Modus ein, in dem SetFieldValue() aufgerufen werden kann.

WriteRecord()

Allgemeine Beschreibung: Sendet alle etwaigen ausstehenden Änderungen an den Server und schreibt sie in die Datenbank.

WSEnd(ntfyid)

Allgemeine Beschreibung: Verschiebt den aktuellen Datenstz für das spezifizierte Benachrichtigungsobjekt an das Ende der Abfrage.

WSGetFieldValue(ntfyid, fieldName)

Allgemeine Beschreibung: Gibt den Feldwert des aktuellen Datensatzes des spezifizierten Benachrichtigungsobjekts zurück.

WSGetFormattedValue(ntfyid, fieldName, format)

Allgemeine Beschreibung: Gibt den Feldwert des aktuellen Datensatzes für das aktuelle Benachrichtigungsobjekt zurück.

WSGetBegRow(ntfyid)

Allgemeine Beschreibung: Gibt die Zeilenzahl zurück, die dem ersten Datensatz in der aktiven Anordnung des spezifizierten Benachrichtigungsobjekts entspricht.

WSGetCurrRow(ntfyid)

Allgemeine Beschreibung: Gibt den Index des aktuellen Datensatzes in dem spezifizierten Benachrichtigungsobjekt zurück.

WSHome(ntfyid)

Allgemeine Beschreibung: Verschiebt den aktuellen Datensatz für das spezifizierte Benachrichtigungsobjekt an den Anfang der Abfrage.

WSNextRecord(ntfyid)

Allgemeine Beschreibung: Verschiebt den aktuellen Datensatz zu dem nächsten Datensatz für das spezifizierte Benachrichtigungsobjekt.

WSSelectRow(ntfyid, row)

Allgemeine Beschreibung: Verschiebt den aktuellen Datensatz für das spezifizierte Benachrichtigungsobjekt zu dem in dieser aktiven Anordnung spezifizierten Index.

WSSelectRowByid(ntfyid, id)

Allgemeine Beschreibung: Findet die Zeile in diesem Benachrichtigungsobjekt nach Zeilen-ID und Aufruf von WSSelectRow().

WSSetCurrRow(ntfyid, currrow)

Allgemeine Beschreibung: Verschiebt den aktuellen Datensatz für den Datensatz des Benachrichtigungsobjekts in der durch die Zeilen-ID identifizierten Abfrage.

In einem Ausführungsbeispiel kann jedes Dienstobjekt der Browser-Seite für gewöhnlich die folgenden Dienstverfahren unterstützen:
AddRef()

Allgemeine Beschreibung: Fügt eine Referenz einem Dienst hinzu, so dass dieser nicht automatisch freigegeben wird.

CanInvokeMethod(name)

Allgemeine Beschreibung: Bestimmt, ob das benannte Verfahren an dem aktuellen Dienst aufgerufen werden kann.

FindApplet(name)

Allgemeine Beschreibung: Findet das bezeichnete Applet mit der Hauptansicht.

GetApplication()

Allgemeine Beschreibung: Gibt einen Zeiger auf das globale Anwendungsobjekt zurück.

GetBusComp()

Allgemeine Beschreibung: Gibt die dem aktuellen Dienst zugeordnete Geschäftskomponente zurück.

GetName()

Allgemeine Beschreibung: Gibt den Namen des aktuellen Dienstes zurück.

InvokeMethodAsString(name, argString)

Allgemeine Beschreibung: Dieses Verfahen ist allgemein eine praktische Schnittstelle zu InvokeMethod(), wenn die Zeichenfolge bereits eine formatierte Eigenschaftsanordnung darstellt. Ruft InvokeMethod() für eine Implementierung auf.

Invokemethod(name, inputPropSet)

Allgemeine Beschreibung: Ruft das Verfahren in dem aktuellen Dienst auf.

Release()

Allgemeine Beschreibung: Entfernt die durch AddRef() erzeugte Referenz, so dass der Dienst freigegeben werden kann.

SetApplication(app)

Allgemeine Beschreibung: Setzt den Anwendungsobjektzeiger in dem Dienst.

SetBusComp(busComp)

Allgemeine Beschreibung: Legt die Geschäftskomponente in Verbindung mit dem aktuellen Dienst fest.

SetName(name)

Allgemeine Beschreibung: Legt den Namen des Servers während der Initialisierung fest. Aufruf nur durch SWE.

StringToPropSet(string)

Allgemeine Beschreibung: Wandelt die Argumentzeichenfolge in eine Eigenschaftsanordnung um.

In einem Ausführungsbeispiel kann jedes Applet der Browser-Seite für gewöhnlich die folgenden Applet-Verfahren unterstützen:
AddConditional(spanlD, ...)

Allgemeine Beschreibung: Legt die durch das Applet zu implementierende Bedingung fest.

AddControl(name, ...)

Allgemeine Beschreibung: Legt die Steuerungen an dem Applet fest.

AddMenu(menu)

Allgemeine Beschreibung: Legt das dem Applet zugeordnete Menü fest.

AddUserProp(propName, value)

Allgemeine Beschreibung: Legt die Benutzereigenschaften für das Applet fest.

AddControlUserProp(controlName, propName, value)

Allgemeine Beschreibung: Legt die Benutzereigenschaften für eine Steuerung fest.

ButtonMethod(name, inputPropSet)

Allgemeine Beschreibung: Dieses Verfahren ist allgemein eine Schnittstelle zu InvokeMethod(), die zuerst sicherstellt, dass es sich bei dem Applet um das aktive Applet handelt.

CallServerApplet(method, inputProps)

Allgemeine Beschreibung: Leitet Nachrichten an den WE-Frame weiter, der dem aktuellen Applet entspricht.

CanInvokeMethod(name)

Allgemeine Beschreibung: Bestimmt, ob ein bestimmtes Verfahren an dem aktuellen Applet aufgerufen werden kann.

DeletePopup()

Allgemeine Beschreibung: Schließt ein aktives Popup des aktuellen Applets.

Close()

Allgemeine Beschreibung: Entfernt das aktuelle Applet aus der Ansicht. Für ein Popup-Applet wird der Zustand in dem Mutter-Applet wiederhergestellt.

Cleanup()

Allgemeine Beschreibung: Bereinigt jeden Zustand, bevor ein Objekt zerstört wird.

EnumUserProps(start)

Allgemeine Beschreibung: Iteriert durch die an dem aktuellen Applet definierten Benutzereigenschaften.

EnumControlUserProps(start, controlName)

Allgemeine Beschreibung: Iteriert durch die Benutzereigenschaften an der bezeichneten Steuerung.

GetBusComp()

Allgemeine Beschreibung: Gibt die Geschäftskomponente zurück, auf der das aktuelle Applet basiert.

GetControl(controlName)

Allgemeine Beschreibung: Gibt die Steuerdatenstruktur für die bezeichnete Steuerung zurück.

GetFieldControl(fieldName)

Allgemeine Beschreibung: Gibt das Steuerobjekt zurück, das sich oben in dem bezeichneten Feld befindet.

GetFieldSorting(fieldName)

Allgemeine Beschreibung: Gibt den Sortierungszustand für das bezeichnete Feld zurück.

GetId()

Allgemeine Beschreibung: Gibt die dem aktuellen Applet zugeordnete ID zurück.

GetInputValue(input)

Allgemeine Beschreibung: Gibt den Wert zurück, der sich in einem gegebenen INPUT (Steuer-) Element befindet.

GetInputValueByName(name)

Allgemeine Beschreibung: Gibt den Wert von der Eingabe für die bezeichnete Steuerung zurück.

GetName()

Allgemeine Beschreibung: Gibt den Applet-Namen zurück.

GetNotifyObj()

Allgemeine Beschreibung: Gibt das durch das Applet während der Initialisierung registrierte Benachrichtigungsobjekt zurück.

GetTitle()

Allgemeine Beschreibung: Gibt den Titel des Applets zurück.

GetVariable()

Allgemeine Beschreibung: Gibt den HTML-Namen der Variable zurück, die auf das aktuelle Applet zeigt.

GetUserProp(propName)

Allgemeine Beschreibung: Gibt den Wert der bezeichneten Benutzereigenschaft zurück.

GetControlUserProp(controlName, propName)

Allgemeine Beschreibung: Gibt den Wert der bezeichneten Benutzereigenschaft für die gegebene Steuerung zurück.

GetView()

Allgemeine Beschreibung: Gibt die Mutter-Ansicht für das aktuelle Applet zurück.

GetPopupMethod()

Allgemeine Beschreibung: Gibt den internen Zustand des Popup-Applets zurück.

GetPopupControl()

Allgemeine Beschreibung: Gibt die Steuerung des Popup-Applets zurück. Aufruf durch JavaScript-Rahmen.

GetPopupApplet()

Allgemeine Beschreibung: Gibt den internen Zustand des Popup-Applets zurück.

GetPopupBookmark()

Allgemeine Beschreibung:.

GetParentApplet()

Allgemeine Beschreibung: Gibt den internen Zustand des Popup-Applets zurück.

Initialize()

Allgemeine Beschreibung: Legt den Zustand an dem Applet fest, nachdem dieser erzeugt worden ist und bevor er verwendet wird.

InvokeMethod(name, inputPropSet)

Allgemeine Beschreibung: Ruft das spezielle Verfahren an diesem Applet auf. Dies ist die primäre Methode, wie besondere Applets neue Verfahren bzw. Methoden registrieren.

IsActiveApplet()

Allgemeine Beschreibung: Bestimmt, ob es sich bei dem aktuellen Applet um das aktive Applet in der Ansicht handelt.

LeaveField(field)

Allgemeine Beschreibung: Das Verfahren wird für gewöhnlich aufgerufen, wenn der Fokus ein Eingabeelement verlässt, das einer Steuerung entspricht.

Populate()

Allgemeine Beschreibung: Legt alle UI-Elemente an dem Applet mit Status von der Geschäftskomponente fest.

ProcessError(objet)

Allgemeine Beschreibung: Bringt einen Fehlerdialog für den an dem gegebenen Objekt registrierten Fehler hervor.

SetAppletActive(isActive, newActiveApplet)

Allgemeine Beschreibung: Legt das spezifizierte Applet als aktiv oder inaktiv fest. Wenn das erste Argument erfüllt ist, wird das spezifizierte Applet aktiv gemacht.

SetBusComp(busComp)

Allgemeine Beschreibung: Legt die Geschäftskomponente fest, auf der das aktuelle Applet basiert.

SetDocument(doc)

Allgemeine Beschreibung: Legt das HTUL-Dokument für das aktuelle Applet fest.

SetHighlightClasses(elementID, activeClass, inactiveClass)

Allgemeine Beschreibung: Legt den Zustand zum Anzeigen des Highlights des aktiven Applets fest.

SetId(id)

Allgemeine Beschreibung: Legt die ID für das aktuelle Applet fest, um es von den anderen Applets der Ansicht zu unterscheiden.

SetInputValue(input, value)

Allgemeine Beschreibung: Legt den aktuellen Wert des aktuellen Werts des Eingabeelements auf einen spezifizierten Wert fest.

SetName(name)

Allgemeine Beschreibung: Legt den Namen des Applets fest.

SetNotifyObj(notifyObj)

Allgemeine Beschreibung: Legt das gegebene Benachrichtigungsobjekt als das aktive Objekt für dieses Applet fest.

SetTitle(title)

Allgemeine Beschreibung: Legt den Titel des Applets fest.

SetPopupMethod(popupMethod)

Allgemeine Beschreibung: Legt den Zustand des Popup-Applets fest.

SetPopupControl(popupControl)

Allgemeine Beschreibung: Legt den Zustand des Popup-Applets fest.

SetPopupApplet(popupApplet)

Allgemeine Beschreibung: Legt den Zustand des Popup-Applets fest.

SetPopupBookmark(popupbookmark)

Allgemeine Beschreibung: Legt den Zustand des Popup-Applets fest.

SetParentApplet(parentApplet)

Allgemeine Beschreibung: Legt den Zustand eines Popup-Applets fest.

SetVariable(variable)

Allgemeine Beschreibung: Legt die HTML-Variable fest, die auf das Applet-Objekt verweist.

SetView(view)

Allgemeine Beschreibung: Legt die Mutter-Ansicht bzw. Oberansicht für das aktuelle Applet fest.

toString()

Allgemeine Beschreibung: Gibt eine Zeichenfolge zurück, die den Applet-Namen aufweist.

TryCondition(service, method, args)

Allgemeine Beschreibung: Bestimmt, ob die gegebene Bedingung einen wahren Wert zurückgibt. TryCondition() ruft das Dienstverfahren auf und gibt den Zustand zurück.

UpdateConditionals()

Allgemeine Beschreibung: Bewertet Bedingungen neu so, dass sich ein bestimmter signifikanter Zustand geändert hat.

UpdateRowCounter()

Allgemeine Beschreibung: Erzeugt die Zeilenzählerzeichenfolge neu und aktualisiert den angezeigten Zeichenzähler.

Befehlsmanager
In einem Ausführungsbeispiel werden verschiedene Benutzeroberflächenelemente oder Steuerungen, wie etwa Symbolleisten, Menüs, Tastatursteuerungen (hierin auch Tastatur-Shortcuts oder Tastenkombinationen genannt), etc. eingesetzt, um die Mittel für den Benutzer bereitzustellen, um verschiedene Aktionen oder Befehle einzuleiten. In einem Ausführungsbeispiel können Symbolleisten so entwickelt und konfiguriert werden, dass sie in einem eigenen Rahmen nahe dem oberen Ende der Anwendung in dem Browser-Fenster erscheinen, und wobei die Anwendungsmenüs (z.B. Datei, Ansicht und Hilfe, etc) so gestaltet und konfiguriert werden können, dass sie unter der der primären Reiterleiste (z.B. First-Level-Navigation) erscheinen. In einem Ausführungsbeispiel können die Menüs auf Applet-Ebene über die Schaltfläche Applet-Menü in der Funktionsleiste im oberen Bereich eines Applets aufgerufen werden. Die Abbildungen der 16, 17 und 18 veranschaulichen entsprechende Beispiele für Symbolleisten, Menüs auf Anwendungsebene und Menüs auf Applet-Ebene. In einem Ausführungsbeispiel kann jedes Benutzeroberflächenelement oder Objekt in einer Symbolleiste, einem Menü auf Anwendungsebene, einem Menü auf Applet-Ebene oder ein bestimmter Tastatur-Shortcut oder eine Tastenkombination (z.B. Strg+N) so konfiguriert werden, dass es einem bestimmten Befehl zugeordnet ist oder auf diesen abgebildet wird, der als Reaktion auf die Benutzerauswahl oder Aktivierung des entsprechenden Benutzeroberflächenelements ausgeführt wird (z.B. durch Anklicken eines Menüelements, durch Drücken einer Tastenkombination wie etwa Strg+N, etc.). In einem Ausführungsbeispiel kann jeder Befehl so definiert und konfiguriert werden, dass eines oder mehrere spezielle Verfahren aufgerufen werden, um eine oder mehrere bestimmte Funktionen oder Aktionen auszuführen, die von dem Benutzer angefordert werden. In einem Ausführungsbeispiel kann eine hierin als ein Befehlsobjekt bezeichnete Datenstruktur so definiert und konfiguriert werden, dass sie einen speziellen Befehl darstellt, dessen Ausführung zum Aufrufen eines oder mehrerer spezieller Verfahren führen kann, das dem entsprechenden Befehlsobjekt zugeordnet ist. Befehlsobjekte werden nachstehend im Text näher beschrieben.
In einem Ausführungsbeispiel wird eine Auswahl oder Aktivierung eines Symbols der Symbolleiste oder eines Menüelements bzw. einer Menüoption (z.B. Benutzer, die auf ein Symbol einer Symbolleiste oder eine Menüoption klicken, etc.) normalerweise in einen Aufruf eines Aufrufverfahrens umgesetzt, das sich in einem Dienst in dem Browser oder auf dem Server oder in Klassen in der Browser-Anwendung oder Serverinfrastruktur befinden kann (z.B. Applet- oder Geschäftskomponentenklassen, SWE-Frame-Manager oder Modell, etc.). In einem Ausführungsbeispiel kann ein Benutzerschnittstellenelement, wie etwa ein Symbol einer Symbolleiste, eine Menüoption oder ein Tastatur-Shortcut so konfiguriert werden, dass ein Verfahrensname, eine Verfahrens-Behandlungsroutine (von der eine neue Anpeilung automatisch erfolgen kann, wenn sie nicht gefunden worden ist) und optional ein Dienst angepeilt bzw. ins Ziel genommen wird.
In einem Ausführungsbeispiel können Elemente auf Anwendungsebene (die sowohl Symbole einer Symbolleiste, Menüs auf Anwendungsebene und Tastatur-Shortcuts, etc. aufweisen können) unter Verwendung von Befehlsobjektdefinitionen in Tools implementiert werden, die danach in Symbolleistenelement- oder Menüoptions-Objektdefinitionen abgebildet werden. In einem Ausführungsbeispiel verwenden Menüs auf Applet-Ebene keine Befehlsobjektdefinitionen, wobei die Anordnung der Eigenschaften für das Targeting und Aufrufen des entsprechenden Verfahrens denen ähnlich ist, die sich in dem Befehlsobjekttyp finden.
In einem Ausführungsbeispiel in den Web Engine-Vorlagen kann das Symbolleisten-Tag eingesetzt werden, um eine bezeichnete Symbolleiste zu spezifizieren (wobei der Name der Namenseigenschaft in der Symbolleisten-Objektdefinition in der Ablage entspricht), und wobei das Symbolleistenelement-Tag zwischen dem Symbolleistenanfangs- und Symbolleistenenden-Tags rekursiv alle der Symbolleistenelemente für die Symbolleiste aus der Ablage abruft.
In einem Ausführungsbeispiel wird für die Menüs auf Applet-Ebene eine Entwicklungszeit-Menüaktivierungs/-unterdrückungseigenschaft bereitgestellt. Diese Eigenschaft bzw. dieses Merkmal stellt die Fähigkeit bereit, eine Menüoption global für Applets einer bestimmten Klasse und Unterklassen zur Verfügung zu stellen und sie danach in bestimmten Applets zu unterdrücken, in denen sie nicht gewünscht wird. In einem Ausführungsbeispiel kann die Entwicklungszeit-Menüaktivierungs/-unterdrückungseigenschaft unter Verwendung des Objekttyps Klassenmethoden-Menüoption (Class Method Menu Item) implementiert werden, der eingesetzt werden kann, um die Menüoption in dem Menü auf Applet-Ebene aller Applets in der spezifizierten Applet-Klasse zu implementieren, mit Ausnahme, wenn eine Unterdrückung gegeben ist, gemäß der Definition in der Eigenschaft Menüoption unterdrücken (Suppress Menu Item). Die Menüoption Applet-Verfahren, die Menüoption Klassenverfahren und die Unterdrückung der Menüoption werden nachstehend im Text näher beschrieben.
Die Abbildung aus 19 zeigt ein Flussdiagramm eines Ausführungsbeispiels eines Verfahrens bzw. Prozesses 1900 zum Erzeugen verschiedener Objekte, die für die Konfiguration und Ausführung der verschiedenen Befehle eingesetzt werden. Wie dies in 19 dargestellt ist, kann der Prozess die folgenden Aktionen aufweisen:

• Erzeugen eines oder mehrerer Befehlsobjekte (in Block 1910)
• Erzeugen eines oder mehrerer Symbolleistenobjekte (in Block 1920)
• Erzeugen eines oder mehrerer Symbolleistenelementobjekte (in Block 1930)
• Erzeugen eines oder mehrerer Menüobjekte auf Anwendungsebene (in Block 1940)
• Erzeugen eines oder mehrerer Menüoptionsobjekte auf Anwendungsebene (in Block 1950)
• Erzeugen eines oder mehrerer Applet-Verfahren-Menüoptionsobjekte (in Block 1960)
• Erzeugen eines oder mehrerer Klassenverfahren-Menüoptionsobjekte (in Block 1970)
• Erzeugen eines oder mehrerer Tastenkombinationsobjekte, hierin auch als Tastatur-Shortcuts oder Funktionstasten bezeichnet (in Block 1980).

Die Abbildung aus 20 zeigt ein Flussdiagramm eines Ausführungsbeispiels eines Prozesses 2000 zum Erzeugen eines Befehlsobjekts gemäß den Lehren der vorliegenden Erfindung. Das Erzeugen eines Befehlsobjekts kann allgemein das Definieren einer Befehlsobjektdefinition aufweisen (in dem Block 2010) und das Spezifizieren der Eigenschaften, die dem definierten Befehlsobjekt zugeordnet sind (in dem Block 2020).
Die Abbildung aus 21 veranschaulicht ein Ausführungsbeispiel der Eigenschaften eines Befehlsobjekts gemäß den Lehren der vorliegenden Erfindung. In einem Ausführungsbeispiel kann ein Befehlsobjekt die folgenden Eigenschaften aufweisen: Target 2110, Geschäftsdienst 2120, Verfahren 2130, Verfahrensargument 2140, Popup zeigen 2150, HTML-Popup-Abmessungen 2160, Bitmap/HTML-Bitmap 2170 und Quickinfo-Text 2180. Befehlsobjekte und ihre Eigenschaften werden nachstehend im Text näher beschrieben.
In einem Ausführungsbeispiel wird eine Befehlsobjektdefinition erzeugt und konfiguriert, um zu spezifizieren, welches Aufrufverfahren aufgerufen wird, wenn ein Symbol einer Symbolleiste oder eine Menüoption auf Anwendungsebene, die dem Befehl zugeordnet ist, ausgeführt wird. Ferner kann eine Befehlsobjektdefinition verwendet werden, um zu spezifizieren, welche Bitmap auf dem Symbolleistensymbol für Symbolleistenelemente erscheint. In einem Ausführungsbeispiel wird auf die Befehlsobjektdefinitionen durch die Objektdefinitionen Symbolleistenelement (Toolbar Item) oder Menüoption (Menu Item) verwiesen. Wie dies in der Abbildung aus 21 veranschaulicht ist, weist eine Befehlsobjektdefinition die folgenden Eigenschaften auf:

• Die Eigenschaft Ziel bzw. Target 2110 spezifiziert allgemein, welche Instanz das Aufrufverfahren behandelt, welches der Befehl aufruft. In einem Ausführungsbeispiel stehen die folgenden Optionen zur Verfügung: • Browser: In diesem Fall kann es sich bei der Verfahrensbehandlungsroutine um einen JavaScript-Dienst in dem Browser handeln oder die JavaScript-Anwendung, abhängig davon, ob ein Dienst in der Eigenschaft Geschäftsdienst (Business Service) spezifiziert ist oder nicht. • Server: In diesem Fall kann es sich bei der Verfahrensbehandlungsroutine um einen Objektmanagerdienst auf dem Server handeln oder die Objektmanagerinfrastruktur (z.B. SWE UDF Loader oder sekundär das Modell), abhängig davon, ob ein Dienst in der Geschäftsdiensteigenschaft spezifiziert ist oder nicht.
• Die Eigenschaft Geschäftsdienst (Business Service) 2120 spezifiziert allgemein den Dienst (abhängig von der Eigenschaft Ziel entweder in dem Browser oder auf dem Server), welche das Aufrufverfahren behandelt. Wenn in einem Ausführungsbeispiel die Eigenschaft leer gelassen wird, ist die Browser- oder Server-Infrastruktur das Ziel an Stelle eines spezifischen Dienstes. Wenn in einem Ausführungsbeispiel ein Dienst spezifiziert ist, behandelt dieser CanInvokeMethod und InvokeMethod für das in der Eigenschaft Verfahren (Method) spezifizierte Verfahren.
• Die Eigenschaft Verfahren (Method) 2130 wird allgemein eingesetzt, um den Namen des aufzurufenden Verfahrens zu spezifizieren, wenn ein Benutzeroberflächenelement (z.B. eine Menüoption, ein Symbol einer Symbolleiste, etc.) ausgewählt wird. In einem Ausführungsbeispiel handelt es sich bei dieser Eigenschaft um eine erforderliche Eigenschaft.
• Die Eigenschaft Verfahrensargument (Method Argument) 2140 wird allgemein eingesetzt, um einen Mechanismus bereitzustellen, um ein Argument zu dem Aufrufverfahren zu leiten, das in der Eigenschaft Verfahren spezifiziert ist. Zum Beispiel kann ein Befehlselement, das ein neues Fenster öffnet und zu einer URL in diesem Fenster navigiert, das Verfahren GotoURL in der Eigenschaft Verfahren spezifizieren sowie die URL, zu der in der Eigenschaft Verfahrensargument navigiert werden soll.
• Die Eigenschaft Popup zeigen (Show Popup) 2150. In einem Ausführungsbeispiel wird diese Eigenschaft auf WAHR (True) gesetzt, um zu spezifizieren, dass ein neues Browser-Fenster geöffnet wird, bevor das Verfahren aufgerufen wird. Sie wird auf FALSCH (False) gesetzt, um zu spezifizieren, dass das Verfahren in dem aktuellen Browser-Fenster aufgerufen wird.
• Die Eigenschaft HTML Popup-Abmessungen (HTML Popup Dimensions) 2160. In einem Ausführungsbeispiel wird diese Eigenschaft eingesetzt, um die Abmessungen des Popup-Fensters in Pixeln zu spezifizieren, wenn die Eigenschaft Popup zeigen 2150 WAHR ist. Ein Beispiel ist 640×480 (spezifiziert mit dem "×" und ohne Leerzeichen).
• Die Eigenschaft Bitmap/HTML Bitmap 2170.
• Die Eigenschaft Quickinfo-Text (Tooltip Text) 2180. In einem Ausführungsbeispiel wird diese Eigenschaft eingesetzt, um den Quickinfo-Text zu spezifizieren, der erscheint, wenn sich der Cursor über einem Symbol einer Symbolleiste befindet. In einem Ausführungsbeispiel für integrierte Verfahren sollte der Quickinfo-Text leer gelassen werden, was anzeigt, dass das Verfahren dynamisch den Text bereitstellt, und wobei die Sprachlokalisierung als Teil dieses Prozesses erfolgt. Für durch Entwickler definierte Verfahren kann literaler Text für diese Eigenschaft eingegeben werden. Wenn in einem Ausführungsbeispiel literaler Text für diese Eigenschaft eingegeben wird, wird die Sprachlokalisierung für diesen Quickinfo-Text ausgeschaltet.

Die Abbildung aus 22 zeigt ein Flussdiagramm eines Ausführungsbeispiels eines Prozesses 2200 zum Erzeugen eines Symbolleistenobjekts gemäß den Lehren der vorliegenden Erfindung. Das Erzeugen eines Symbolleistenobjekts kann allgemein das Definieren eines Symbolleistenobjekts aufweisen (in dem Block 2210) sowie das Spezifizieren der Eigenschaften, die dem definierten Symbolleistenobjekt zugeordnet sind (in dem Block 2220).
Die Abbildung aus 23 veranschaulicht ein Ausführungsbeispiel der Eigenschaften eines Symbolleistenobjekts gemäß den Lehren der vorliegenden Erfindung. In einem Ausführungsbeispiel kann ein Symbolleistenobjekt die folgenden Eigenschaften aufweisen: Klasse 2310, Name 2320, Anzeigename 2330 und Popup Indikator-Bitmap 2340. Symbolleistenobjekte und ihre Eigenschaften werden nachstehend im Text näher beschrieben.
In einem Ausführungsbeispiel kann für jede Symbolleiste in der Anwendung eine Symbolleisten-Objektdefinition in dem Objektlisteneditor (Object List Editor) erzeugt werden. Dies stellt eine bezeichnete Symbolleiste bereit, die der Benutzer in verschiedenen Anwendungen aktivieren oder deaktivieren kann, und der Symbole der Symbolleisten (z.B. Objektdefinitionen für Symbolleistenelemente) zugewiesen sowie von ihr entfernt werden können. Die Funktionalität der Symbolleiste für Anwendungen kann unter Verwendung von HTML-Symbolleisten implementiert werden. In einem Ausführungsbeispiel handelt es sich bei einer HTML-Symbolleiste bei den Schaltflächen um statische Bilder, die abgeblendet werden können, um anzuzeigen, dass sie nicht verfügbar sind, wobei sie anderweitig jedoch nicht durch eine Programmlogik in dem Browser manipuliert werden. Im Gegensatz dazu können CTI-Anwendungen (Computer Telephony Integration) Symbole von Symbolleisten erfordern, die als Reaktion auf bestimmte Ereignisse verändert werden können, wie etwa das Blinken eines bestimmten Symbols einer Symbolleiste bei einem eingehenden Anruf. In einem Ausführungsbeispiel kann dies den Einsatz von Java-Symbolleisten voraussetzen. In einem Ausführungsbeispiel wird zur Spezifikation, dass es sich bei einer Symbolleiste um eine Java-Symbolleiste handelt, ein Klassenname in die Eigenschaft Klasse (Class) eingegeben. Wie dies in der Abbildung aus 23 dargestellt ist, kann ein Symbolleistenobjekt die folgenden Eigenschaften aufweisen.

• Die Eigenschaft Klasse (Class) 2310. In einem Ausführungsbeispiel wird diese Eigenschaft für eine HTML-Symbolleiste leer gelassen und für eine Java-Symbolleiste spezifiziert (z.B. wird der Name der Java-Klasse eingegeben, welche die Symbolleiste implementiert).
• Die Eigenschaft Name 2320. In einem Ausführungsbeispiel erfolgt der Verweis auf diese Eigenschaft durch andere Objektdefinitionen sowie durch das Symbolleisten-Tag in "name=".
• Die Eigenschaft Name anzeigen (Display Name) 2330. In einem Ausführungsbeispiel wird diese Eigenschaft für die Schaltfläche Verlauf (History) eingesetzt sowie zur Darstellung oder zum Ausblenden/Verstecken von Symbolleisten nach Namen.
• Die Eigenschaft Popup Indikator-Bitmap (Popup Indicator Bitmap) 2340. In einem Ausführungsbeispiel wird diese Eigenschaft eingesetzt, um ein seitliches Symbolleisten-Popup zu spezifizieren.

Die Abbildung aus 24 zeigt ein Flussdiagramm eines Prozesses 2400 zum Erzeugen eines Symbolleistenelementobjekts gemäß den Lehren der vorliegenden Erfindung. Das Erzeugen eines Symbolleistenelementobjekts kann allgemein die Definition eines Symbolleistenelementobjekts (in dem Block 2410) und das Spezifizieren der dem definierten Symbolleistenelementobjekt zugeordneten Eigenschaften umfassen (in dem Block 2420).
Die Abbildung aus 25 veranschaulicht ein Ausführungsbeispiel der Eigenschaften eines Symbolleistenelementobjekts gemäß den Lehren der vorliegenden Erfindung. In einem Ausführungsbeispiel kann ein Symbolleistenelementobjekt die folgenden Eigenschaften aufweisen: die Eigenschaft Befehl 2510, die Eigenschaft HTML-Typ 2520, die Eigenschaft Name 2530, die Eigenschaft Sequenz 2540 und die Eigenschaft Position 2550. Die Symbolleistenobjekte und ihre Eigenschaften werden nachstehend im Text näher beschrieben.
In einem Ausführungsbeispiel ist ein Symbolleistenelementobjekt so definiert und konfiguriert, dass eine Objektdefinition für Befehl (die durch Namen als eine Eigenschaft in der Eigenschaft Befehl des Symbolleistenelementobjekts identifiziert wird) einer Symbolleistenobjektdefinition zugeordnet wird (welche die Mutter des Symbolleistenelementobjekts ist). In einem Ausführungsbeispiel platziert diese Zuordnung ein Symbol einer Symbolleiste, deren Bitmap-Bild, Aufrufverfahren und Ziel in der Objektdefinition von Befehl spezifiziert sind, auf der spezifizierten Symbolleiste an einer bestimmten Position (z.B. einer Position im Verhältnis zu den anderen Symbolleistensymbolen in dieser Symbolleiste). In einem Ausführungsbeispiel gemäß der Abbildung aus 25 kann ein Symbolleistenelementobjekt so definiert sein, dass es die folgenden Eigenschaften aufweist:

• Die Eigenschaft Befehl (Command) 2510. In einem Ausführungsbeispiel spezifiziert diese Eigenschaft den Namen der Objektdefinition von Befehl, welche dass Bitmap, Verfahren und Ziel für das entsprechende Symbolleistenelement bereitstellt. In einem Ausführungsbeispiel können ein oder mehrere Bindestriche an Stelle des Namens eines Objekts Befehl spezifiziert werden, um dem System mitzuteilen, einen Separator bzw. ein Trennzeichen zwischen Symbolen einzufügen.
• Die Eigenschaft HTML-Typ (HTML Type) 2520. In einem Ausführungsbeispiel wird diese Eigenschaft eingesetzt, um die Art der Steuerung zu identifizieren, die in der entsprechenden Symbolleiste in dem Browser angezeigt wird. In einem Ausführungsbeispiel können die verschiedenen Optionen folgende Optionen aufweisen: ComboBox, Button (Schaltfläche), Edit (Bearbeiten), Label (Etikett), Hyperlink, MiniButton und Timer, etc.
• Die Eigenschaft Name 2530. In einem Ausführungsbeispiel spezifiziert diese Eigenschaft den Namen des Symbolleistenelements. In einem Ausführungsbeispiel muss die Eigenschaft Name innerhalb einer Symbolleiste einzigartig bzw. eindeutig sein.
• Die Eigenschaft Sequenz (Sequence) 2540. In einem Ausführungsbeispiel spezifiziert diese Eigenschaft eine ganze Zahl (Integer), die das Symbolleistenelement in der Mutter-Symbolleiste von links nach rechts ordnet. Zum Beispiel platziert eine höhere Sequenznummer im Verhältnis zu anderen Symbolleistenelementen dieses Symbol weiter rechts als die anderen.
• Die Eigenschaft Position 2550. In einem Ausführungsbeispiel wird diese Eigenschaft eingesetzt für seitliche Symbolleisten. Zum Beispiel kann ein Wert von 0,1, 0,2, etc. eingesetzt werden.

In einem Ausführungsbeispiel kann ein Menüobjekt für jedes Menü auf Anwendungsebene definiert und konfiguriert werden. In einem Ausführungsbeispiel gilt ein Menüobjekt als ein Mutter- bzw. übergeordnetes Objekt der entsprechenden Menüoptionsobjekte. Ein Menüoptionsobjekt wird eingesetzt, um ein Anwendungshauptmenü oder eine Menüoption innerhalb der übergeordneten Menüobjektdefinition zu definieren.
Die Abbildung aus 26 zeigt ein Flussdiagramm eines Ausführungsbeispiels eines Prozesses 2600 zum Erzeugen eines Menüoptionsobjekts gemäß den Lehren der vorliegenden Erfindung. Das Erzeugen eines Menüoptionsobjekts kann allgemein das Definieren eines Menüoptionsobjekts aufweisen (in dem Block 2610) und das Spezifizieren der Eigenschaften für das definierte Menüoptionsobjekt (in dem Block 2620).
Die Abbildung aus 27 veranschaulicht ein Ausführungsbeispiel der Eigenschaften eines Menüoptionsobjekts gemäß den Lehren der vorliegenden Erfindung. In einem Ausführungsbeispiel kann ein Menüoptionsobjekt die folgenden Eigenschaften aufweisen: Die Eigenschaft Name 2710, die Eigenschaft Befehl 2720, die Eigenschaft Text 2730 und die Eigenschaft Position 2740. Diese Eigenschaften werden nachstehend im Text näher beschrieben:

• Die Eigenschaft Name 2710. In einem Ausführungsbeispiel wird diese Eigenschaft eingesetzt, um das Menü oder die Menüoption eindeutig zu identifizieren.
• Die Eigenschaft Befehl (Command) 2720. In einem Ausführungsbeispiel spezifiziert diese Eigenschaft den Namen der entsprechenden Objektdefinition von Befehl, die eingesetzt wird, um das Verfahren und das Ziel für die entsprechende Menüoption bereitzustellen.
• Die Eigenschaft Text (Caption) 2730. In einem Ausführungsbeispiel spezifiziert diese Eigenschaft den Text, der in dem Menü oder der Menüoption angezeigt wird.
• Die Eigenschaft Position 2740. In einem Ausführungsbeispiel spezifiziert diese Eigenschaft die Position des Menüs oder der Menüoption in dem Menübaum. Zum Beispiel kann es sich bei den Top Level-Positionen für Menüs (anstatt von Optionen in den Menüs) um einzelne ganze Zahlen wie etwa 1, 2 und 3 (oder 10, 20 und 30) handeln). Die Positionswerte für Menüoptionen (z.B. 2nd-Level und darunter in dem Menübaum) können unter Verwendung einer Punktbezeichnung spezifiziert werden, wobei der Wert rechts neben dem am weitesten rechts angeordneten Punkt die Reihenfolge der Option auf dem Level spezifiziert, und wobei der Wert oder die Werte links davon das übergeordnete Menü oder die übergeordnete Menüoption spezifiziert. Zum Beispiel kann 3.1 definiert sein als das erste Element bzw. die erste Option in dem Untermenü der dritten Option in dem Top Level-Menü. Hiermit wird festgestellt, dass die Werte auf einer Ebene bzw. einem Level nicht unbedingt aufeinanderfolgend sein müssen, wobei zum Beispiel die Werte 1110, 1115, 1120 und 1130 eingesetzt werden können, um vier Menüoptionen auf dem gleichen Level anzuzeigen, und wobei deren Folge bzw. Sequenz deren Reihenfolge der Anzeige in dem Menü bestimmt.

In einem Ausführungsbeispiel wird das Menüoptionsobjekt Applet-Verfahren eingesetzt, um eine Menüoption in dem Menü Applet-Level für die Objektdefinition des übergeordneten Applets zu definieren. In einem Ausführungsbeispiel basieren Applet-Menüs im Gegensatz zu Menüs auf Anwendungsebene nicht auf Befehlsobjekten. Die Gruppe der eingesetzten Eigenschaften für das Targeting des Verfahrens ist jedoch ähnlich den Eigenschaften, die man in dem Befehlsobjekttyp findet. Die Abbildung aus 28 zeigt ein Flussdiagramm eines Ausführungsbeispiels des Prozesses 2800 zum Erzeugen eines Menüoptionsobjekts für ein Applet-Verfahren gemäß den Lehren der vorliegenden Erfindung. Das Erzeugen eines Menüoptionsobjekts für ein Applet-Verfahren kann allgemein das Definieren eines Applet- Verfahren-Menüoptionsobjekts aufweisen (in dem Block 2810) und das Spezifizieren der Eigenschaften für das definierte Applet-Verfahren-Menüoptionsobjekt (in dem Block 2820).
Die Abbildung aus 29 veranschaulicht die Eigenschaften eines Applet-Verfahren-Menüoptionsobjekts gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. In einem Ausführungsbeispiel kann ein Applet-Verfahren-Menüoptionsobjekt die folgenden Eigenschaften aufweisen: die Eigenschaft Menütext (Menu Text) 2910, die Eigenschaft Ziel (Target) 2920, die Eigenschaft Verfahren (Method) 2930, die Eigenschaft Geschäftsdienst (Business Service) 2940, die Eigenschaft Menüoption unterdrücken (Suppress Menu Item) 2950 und die Eigenschaft Position 2960. Diese Eigenschaften werden nachstehend im Text näher beschrieben.

• Die Eigenschaft Menütext (Menu Text). In einem Ausführungsbeispiel wird diese Eigenschaft eingesetzt, um den Text zu spezifizieren, der in der Menüoption angezeigt wird.
• Die Eigenschaft Ziel (Target). In einem Ausführungsbeispiel wird diese Eigenschaft eingesetzt, um zu spezifizieren, welche Instanz das in der Eigenschaft Verfahren spezifizierte Aufrufverfahren behandelt. In einem Ausführungsbeispiel stehen die folgenden Optionen zur Verfügung: • Browser. In diesem Fall kann es sich bei der Verfahrensbehandlungsroutine um einen JavaScript-Dienst in dem Browser handeln oder die JavaScript-Applet-Klasse (oder sekundär die JavaScript-Geschäftskomponentenklasse), abhängig davon, ob ein Dienst in der Eigenschaft Geschäftsdienst (Business Service) spezifiziert ist oder nicht. • Server. In diesem Fall kann es sich bei der Verfahrensbehandlungsroutine um einen Objektmanagerdienst auf dem Server handeln oder das Applet und die Geschäftskomponente und deren Unterklassen, abhängig davon, ob ein Dienst in der Geschäftsdiensteigenschaft spezifiziert ist oder nicht.
• Die Eigenschaft Verfahren (Method). In einem Ausführungsbeispiel wird diese Eigenschaft eingesetzt, um das Verfahren zu spezifizieren, das aufgerufen werden soll, wenn die entsprechende Menüoption ausgewählt worden ist.
• Die Eigenschaft Geschäftsdienst (Business Service). Wenn diese Eigenschaft spezifiziert ist, identifiziert sie den Dienst, bei dem das spezifizierte Verfahren aufgerufen werden soll. Ohne Spezifizierung wird das spezifizierte Verfahren an der Applet-Klasse in dem Browser oder auf dem Server (gemäß der Spezifikation in der Eigenschaft Ziel) aufgerufen, mit folgender neuem Targeting, wenn keine Behandlung erfolgt ist.
• Die Eigenschaft Menüoption unterdrücken (Suppress Menu Item). In einem Ausführungsbeispiel ist diese Eigenschaft standardmäßig auf FALSCH (False) eingestellt. Wenn die Eigenschaft auf WAHR (True) gesetzt wird, bewirkt dies, dass die Menüoption auf Klassenebene des spezifizierten Namens aus dem Menü auf Applet-Ebene in dem Applet dort entfernt wird, wo die Eigenschaft spezifiziert ist.
• Die Eigenschaft Position. In einem Ausführungsbeispiel wird diese Eigenschaft eingesetzt, um die Sequenz der Menüoption in der Liste von Menüoptionen mit einem Level bzw. einer Ebene zu spezifizieren.

Die Abbildung aus 30 zeigt ein Flussdiagramm eines Ausführungsbeispiels eines Prozesses 3000 zum Erzeugen eines Klassenverfahrens-Menüobjekts gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. In einem Ausführungsbeispiel kann eine Klassenverfahrens-Menüoption so definiert und konfiguriert werden, dass eine Menüoption in Menüs auf Applet-Ebene für alle Applets der spezifizierten Applet-Klasse und deren Unterklassen hinzugefügt oder daraus entfernt wird. Die Erzeugung eines Menüoptionsobjekts Klassenverfahren kann allgemein die Definition eines Menüoptionsobjekts Klassenverfahren aufweisen (in Block 3010) sowie das Spezifizieren der Eigenschaften für das definierte Menüoptionsobjekt Klassenverfahren (in dem Block 3020).
Die Abbildung aus 31 veranschaulicht Eigenschaften eine Klassenverfahrens-Menüoption gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. In einem Ausführungsbeispiel kann ein Menüoptionsobjekt Klassenverfahren die folgenden Eigenschaften aufweisen: die Eigenschaft Ziel (Target) 3110, die Eigenschaft Menütext (Menu Text) 3120, die Eigenschaft Verfahren (Method) 3130, die Eigenschaft Geschäftsdienst (Business Service) 3140, die Eigenschaft Menüoption unterdrücken (Suppress Menu Item) 3150 und die Eigenschaft Position 3160. Diese Eigenschaften werden nachstehend im Text näher beschrieben.

• Die Eigenschaft Ziel (Target). In einem Ausführungsbeispiel wird diese Eigenschaft eingesetzt, um zu spezifizieren, welche Instanz das in der Eigenschaft Verfahren spezifizierte Aufrufverfahren behandelt. In einem Ausführungsbeispiel stehen die folgenden Optionen zur Verfügung: • Browser. In diesem Fall kann es sich bei der Verfahrensbehandlungsroutine um einen JavaScript-Dienst in dem Browser handeln oder die JavaScript-Applet-Klasse (oder sekundär die JavaScript-Geschäftskomponentenklasse), abhängig davon, ob ein Dienst in der Eigenschaft Geschäftsdienst (Business Service) spezifiziert ist oder nicht. • Server. In diesem Fall kann es sich bei der Verfahrensbehandlungsroutine um einen Objektmanagerdienst auf dem Server handeln oder das Applet und die Geschäftskomponente und deren Unterklassen, abhängig davon, ob ein Dienst in der Geschäftsdiensteigenschaft spezifiziert ist oder nicht.
• Die Eigenschaft Menütext (Menu Text). In einem Ausführungsbeispiel wird diese Eigenschaft eingesetzt, um den Text zu spezifizieren, der in der Menüoption angezeigt wird.
• Die Eigenschaft Verfahren (Method). In einem Ausführungsbeispiel wird diese Eigenschaft eingesetzt, um das Verfahren zu spezifizieren, das aufgerufen werden soll, wenn die entsprechende Menüoption ausgewählt worden ist.
• Die Eigenschaft Geschäftsdienst (Business Service). Wenn diese Eigenschaft spezifiziert ist, identifiziert sie den Dienst, bei dem das spezifizierte Verfahren aufgerufen werden soll. Ohne Spezifizierung wird das spezifizierte Verfahren an der Applet-Klasse in dem Browser oder auf dem Server (gemäß der Spezifikation in der Eigenschaft Ziel) aufgerufen, mit folgender neuem Targeting, wenn keine Behandlung erfolgt ist.
• Die Eigenschaft Menüoption unterdrücken (Suppress Menu Item). In einem Ausführungsbeispiel ist diese Eigenschaft standardmäßig auf FALSCH (False) eingestellt. Wenn die Eigenschaft auf WAHR (True) gesetzt wird, bewirkt dies, dass die Menüoption auf Klassenebene des spezifizierten Namens aus dem Menü auf Applet-Ebene in dem Applet dort entfernt wird, wo die Eigenschaft spezifiziert ist.
• Die Eigenschaft Position. In einem Ausführungsbeispiel wird diese Eigenschaft eingesetzt, um die Sequenz der Menüoption in der Liste von Menüoptionen mit einem Level bzw. einer Ebene zu spezifizieren.

Die Abbildung aus 32 zeigt ein Diagramm, das die Beziehung zwischen Symbolleistenobjekten, Symbolleisten-Optionsobjekten und Befehlsobjekten gemäß einem Ausführungsbeispiel der vorliegenden Erfindung veranschaulicht. Gemäß der Abbildung aus 32 kann ein Symbolleistenobjekt gemäß der Beschreibung hierin allgemein einem oder mehreren Symbolleisten-Optionsobjekten zugeordnet werden. In einem Ausführungsbeispiel kann jedes Symbolleisten-Optionsobjekt einem entsprechenden Befehlsobjekt zugeordnet oder darauf abgebildet werden (z.B. unter Verwendung der Befehlseigenschaft des entsprechenden Symbolleisten-Optionsobjekts). Anders ausgedrückt kann auf ein Befehlsobjekt durch ein Symbolleisten-Optionsobjekt unter Verwendung der Befehlseigenschaft des Symbolleisten-Optionsobjekts verwiesen werden, um den Namen des Befehlsobjekts gemäß der vorstehenden Beschreibung zu spezifizieren.
Die Abbildung aus 23 zeigt ein Diagramm der Beziehung zwischen einem Menüobjekt, Menüoptionsobjekten und Befehlsobjekten. Gemäß der Abbildung aus 33 kann ein Menüobjekt gemäß der Beschreibung hierin allgemein einem oder mehreren Menüoptionsobjekten zugeordnet werden. In einem Ausführungsbeispiel kann jedes Menüoptionsobjekt einem entsprechenden Befehlsobjekt zugeordnet oder auf dieses abgebildet werden (z.B. unter Verwendung der Befehlseigenschaft des entsprechenden Menüoptionsobjekts). Anders ausgedrückt kann auf ein Befehlsobjekt durch ein Menüoptionsobjekt verwiesen werden unter Verwendung der Befehlseigenschaft des Menüoptionsobjekts, um den Namen des Befehlsobjekts gemäß der vorstehenden Beschreibung zu spezifizieren.
Die Abbildung aus 34 zeigt ein Diagramm der Beziehung zwischen einem Menüobjekt auf Applet-Ebene, Menüoptionsobjekten des Applet-Verfahrens und Menüoptionsobjekten des Klassenverfahrens. Gemäß der Abbildung aus 34 kann ein Menü auf Applet-Ebene allgemein einem oder mehreren Menüoptionsobjekten des Applet-Verfahrens zugeordnet sein. In einem Ausführungsbeispiel kann jedes Menüoptionsobjekt Applet-Verfahren einem Menüoptionsobjekt Klassenverfahren zugeordnet oder darauf abgebildet werden (z.B. unter entsprechender Verwendung der Eigenschaft Menüoption unterdrücken gemäß der Beschreibung hierin).
Aktivierung und Unterdrückung von Menüoption und Symbolleistenelement
In einem Ausführungsbeispiel der vorliegenden Erfindung können Menüoptionen (z.B. sowohl auf Anwendungsebene als auch auf Applet-Ebene) und Symbolleistenelemente in Laufzeit aktiviert oder deaktiviert werden durch den Einsatz des Mechanismus CanInvokeMethod. In einem Ausführungsbeispiel wird CanInvokeMethod (für das in dem Objekt Befehl, dem Objekt Applet-Verfahren Menüoption oder Klassenverfahren Menüoption, etc. spezifizierte Verfahren) automatisch für jedes Element bzw. jede Option aufgerufen, bevor das Menü oder die Symbolleiste angezeigt wird. Wenn CanInvokeMethod FALSCH zurückgibt, sind das Symbolleistenelement oder die Menüoption deaktiviert (z.B. werden nicht angezeigt). Die Logik CanInvokeMethod ist allgemein erneut von der Browser-Anwendung auf die Applet-Klassenhierarchie in dem Server gerichtet und von dort zu der Geschäftskomponenten-Klassenhierarchie. Die Targeting-Sequenz wird nachstehend im Text näher beschrieben.
Wie dies hierin beschrieben ist, werden die Unterdrückung und die Aktivierung der einzelnen Menüoptionen auf Applet-Ebene zum Zeitpunkt der Entwicklung unterstützt durch den Einsatz der Eigenschaft Menüoption unterdrücken in den Objekttypen Klassenverfahren-Menüoption und Applet-Verfahren-Menüoption. In einem Ausführungsbeispiel ist dieser Mechanismus oder dieses Merkmal anwendbar auf Menüs auf Applet-Ebene, auf Menüs nicht auf Anwendungsebene oder Symbolleisten, wobei die Option bzw. das Element explizit hinzugefügt oder entfernt wird. Die Menüaktivierung/-unterdrückung zum Zeitpunkt der Entwicklung für Menüs auf Applet-Ebene stellt den Mechanismus bereit, um eine Menüoption global für Applets einer bestimmten Klasse und deren Unterklassen verfügbar zu machen, und um sie danach in bestimmten Applets zu unterdrücken, wo sie nicht gewünscht wird. Zum Beispiel erscheinen verschiedene Menüoptionen auf Applet-Ebene in praktisch allen Applets (wie etwa Kopieren, Bearbeiten und Löschen, etc.), während andere in praktisch allen Listen-Applets auftreten (z.B. angezeigte Spalten), usw., wobei aber auch Situationen existieren können, in denen eine "Standard" Menüoption für die Klasse des Applets für ein bestimmtes Applet unterdrückt werden muss.
In einem Ausführungsbeispiel wird zum Hinzufügen von Menüoptionen auf Applet-Klassenebene eine Menüoption Klassenverfahren für eine Standard-Menüoption für eine bestimmte Applet-Klasse hinzugefügt. In einem Ausführungsbeispiel müsste diese Menüoption nicht mehr neu als Objektdefinitionen der Menüoption Applet-Verfahren in Applets aufgenommen werden, in denen die Menüoption erscheinen soll. In einem Ausführungsbeispiel werden die Objektdefinitionen für die Menüoption Applet-Verfahren in zwei Fällen erzeugt: um eine Menüoption (nicht bereits bereitgestellt durch die Klasse des Applets) dem Applet hinzuzufügen, oder um die Anzeige einer Option auf Applet-Klassenebene zu unterdrücken, welche das Applet normalerweise aufweisen würde. Im letzteren Fall wird eine Objektdefinition einer Menüoption Appeet-Verfahren mit der gleichen Menüoption auf Applet-Klassenebene erzeugt, die unterdrückt werden soll, und ein Wert FALSCH wird für die Eigenschaft Menüoption unterdrücken eingegeben.
Aufrufverfahren als Ziel
Gemäß einem hierin beschriebenen Ausführungsbeispiel der vorliegenden Erfindung sind die Eigenschaften Verfahren, Geschäftsdienst und Ziel in dem Objekttyp Befehl (zur Verwendung in Symbolleisten und Menüs auf Anwendungsebene) und in den Objekttypen der Menüoption Klassenverfahren sowie der Menüoption Applet-Verfahren enthalten (zur Verwendung in Menüs auf Applet-Ebene). In einem Ausführungsbeispiel stehen zwei Einstellungen oder Optionen für die Eigenschaft Ziel zur Verfügung, mit dem folgenden Verhalten:

• Browser-Ziel: Die Verfahrensbehandlungsroutine für dieses Ziel kann die JavaScript-Anwendung sein, ein JavaScript-Applet oder ein JavaScript-Dienst auf der Browser-Seite. In einem Ausführungsbeispiel, unabhängig davon, welche Instanz die Verfahrensbehandlungsroutine aufweist, muss ein Verfahrensname in der Eigenschaft Verfahren spezifiziert werden. In einem Ausführungsbeispiel ist ein Dienst das Ziel, wenn ein Dienstname in der Eigenschaft Dienst spezifiziert ist. Wenn ein Dienst in der Eigenschaft Dienst nicht spezifiziert ist, unterscheidet sich die Verfahrensbehandlung abhängig davon, ob es sich bei der aufrufenden Instanz um eine Instanz auf Anwendungsebene oder Applet-Ebene handelt, wie folgt: • Anwendungsebene: das Ziel ist das spezifizierte Verfahren in der JavaScript-Anwendung. In diesem Fall erfolgt kein erneutes Targeting. • Applet-Ebene: das Ziel ist das spezifizierte Verfahren in dem JavaScript-Applet. Ohne Behandlung wird das spezifizierte Verfahren erneut als Ziel verwendet in der entsprechenden JavaScript-Geschäftskomponente. In diesem Fall erfolgt keine Vererbung oder ein zusätzliches erneutes Targeting.
• Server-Ziel: Dieses Ziel dient dem Aufrufen eines Verfahrens auf einem Server (z.B. ein Verfahren in einer C++ Klasse auf dem Server), entweder in Bezug auf einen Dienst oder die Infrastruktur. Wenn ein Eigenschaftswert Dienst nicht spezifiziert ist, richtet sich das Aufrufverfahren an die Infrastruktur. Es richtet sich unterschiedlich an die Infrastruktur abhängig davon, ob das Menü oder das Symbol der Symbolleiste, welches das Verfahren aufruft, auf Applet-Ebene (nur Menü) oder auf Anwendungsebene (Menü oder Symbolleiste) gegeben ist, wobei die Unterschiede wie folgt gegeben sind: • Anwendungsebene: bei der Verfahrensbehandlungsroutine handelt es sich ursprünglich um den SWE UDF-Loader auf der Server-Seite und sekundär das Modell. • Applet-Ebene: die Verfahrensbehandlungsroutine entspricht ursprünglich der Applet-Klasse, welcher das Applet angehört, und sie wird wiederholt angesprochen entlang der Hierarchie der Applet-Klasse bis zu CSSSWEFrame. Wenn noch keine Behandlung stattgefunden hat, wird die Behandlung erneut auf die Geschäftskomponentenklasse der Geschäftskomponente des Applets gerichtet und in der Folge nach oben durch die Hierarchie der Geschäftskomponentenklasse bis zu CSSBusComp.

Wenn ein Dienst in der Eigenschaft Dienst spezifiziert ist, handelt es sich bei der Verfahrensbehandlungsroutine um den spezifizierten Dienst. Dieses Targeting ist auch davon abhängig, ob es sich bei der aufrufenden Menüoption oder dem Symbol der Symbolleiste um eine Applet-Ebene oder Anwendungsebene handelt, und zwar wie folgt:

• Anwendungsebene. bei der Verfahrensbehandlungsroutine handelt es sich ursprünglich um den spezifizierten OM-Dienst. In diesem Fall erfolgt kein erneutes Targeting.
• Applet-Ebene: die Verfahrensbehandlungsroutine führt einen Aufruf SetBC aus, um die Geschäftskomponente des Applets festzulegen, und sie ruft danach den spezifizierten OM-Dienst auf. In diesem Fall erfolgt kein erneutes Targeting.

Die folgende Matrix oder Tabelle veranschaulicht die Ergebnisse der möglichen Einstellungen der Eigenschaften Ziel (Target) und Geschäftsdienst (Business Service) auf Applet-Ebene und Anwendungsebene gemäß einem Ausführungsbeispiel der vorliegenden Erfindung.
Die Abbildung aus 35 veranschaulicht ein Blockdiagramm eines Ausführungsbeispiels einer Systemkonfiguration 3500, in der die Lehren der vorliegenden Erfindung implementiert werden können. Die Systemkonfiguration 3500 weist einen Befehlsmanager auf Client-Seite auf, der so konfiguriert ist, dass er die Verarbeitung verschiedener Befehle verwaltet, die durch einen Benutzer des Systems initiiert werden, auf der Basis der in den Eigenschaften definierten Informationen, die den entsprechenden Befehlen zugeordnet sind. Gemäß der Abbildung aus 35 umfasst die Systemkonfiguration ferner einen Befehlsmanagerdienst auf der Server-Seite und einen Befehlsmanager auf der Server-Seite. In einem Ausführungsbeispiel ist der Befehlsmanagerdienst so konfiguriert, dass er von dem Befehlsmanager auf Client-Seite die Befehle empfängt, die an den Server gerichtet sind. In einem Ausführungsbeispiel fungiert der Befehlsmanagerdienst als Fokus für den Empfang und die Weiterleitung der empfangenen Befehle zu dem Befehlsmanager auf Server-Seite. In einem Ausführungsbeispiel ist der Befehlsmanager auf Server-Seite so konfiguriert, dass die Befehle verarbeitet werden, die an den Server gerichtet sind. In einem Ausführungsbeispiel ist der Befehlsmanager auf Server-Seite so konfiguriert, dass er auf der Basis der Eigenschaften, die den entsprechenden Befehlen zugeordnet sind, bestimmt, welche Instanz das Verfahren behandeln soll, das in dem entsprechenden Befehl spezifiziert ist. Wie dies vorstehend im Text beschrieben worden ist, kann ein Befehl auf ein Benutzeroberflächenelement abgebildet werden (hierin auch bezeichnet als Befehlselement, Steuerung oder Steuerelement), wie etwa ein Symbolelement, eine Menüoption, eine Tastenkombinationsoption (hierin auch als Tastatur-Shortcut oder Funktionstaste bezeichnet), etc. Im Allgemeinen wird die Auswahl des Benutzers oder die Einleitung eines Befehls (z.B. durch Anklicken eines Symbols einer Symbolleiste, einer Menüoption oder durch Drücken einer Tastenkombination, etc.) in einen Aufruf zum Aufrufen eines Verfahrens umgesetzt, das sich in einem Dienst in dem Browser oder auf dem Server befinden kann, oder in den entsprechenden Klassen in der Browser-Anwendung oder der Server-Infrastruktur (z.B. Applet- oder Geschäftskomponenten-Klassen, etc.). Wie dies vorstehend im Text beschrieben worden ist, ist ein Symbol einer Symbolleiste, eine Menüoption oder eine Tastenkombination so konfiguriert, dass ein Verfahren eine Verfahrensbehandlungsroutine (von der ein erneutes Targeting automatisch erfolgen kann, wenn sie nicht gefunden wird) und optional ein Dienst ins Ziel genommen werden.
Die Abbildung aus 36 zeigt ein Flussdiagramm eines Prozesses 3600 gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. In dem Block 3610 wird bestimmt, ob ein Befehlselement, das einem Menü, einer Symbolleiste oder einer Tastatur zugeordnet ist, aktiviert ist (z.B. ob das dem Befehlselement zugeordnete Verfahren aufgerufen werden kann). Wie dies bereits vorstehend im Text beschrieben worden ist, können Menüoptionen (auf Anwendungsebene und Applet-Ebene) und Symbolleistenelemente in Laufzeit aktiviert und deaktiviert werden unter Verwendung des Mechanismus CanInvokeMethod gemäß der vorstehenden Beschreibung. In einem Ausführungsbeispiel wird CanInvokeMethod für jedes Element aufgerufen, bevor das Menü oder die Symbolleiste angezeigt wird. In einem Ausführungsbeispiel gibt CanInvokeMethod einen Wert (z.B. FALSCH) zurück, um anzuzeigen, dass das Befehlselement nicht freigegeben ist (z.B. das Verfahren kann nicht aufgerufen werden), und ein anderer Wert (z.B. WAHR) zum Anzeigen, dass das Befehlselement aktiviert ist (z.B. das Verfahren kann aufgerufen werden). Wenn in einem Ausführungsbeispiel das entsprechende Befehlselement nicht aktiviert ist (z.B. CanInvokeMethod gibt einen Wert FALSCH zurück), so kann auf das entsprechende Element durch den Benutzer nicht zugegriffen werden (z.B. die Menüoption oder das Symbolleistenelement wird nicht angezeigt, ausgeblendet, etc.). Wenn in dem Block 3620 das entsprechende Element aktivier ist (z.B. CanInvokeMethod gibt einen Wert TRUE zurück), so wird dem Benutzer angezeigt, dass das entsprechende Element ausgewählt werden kann (z.B. Anzeigen der Menüoption oder des Symbolleistenelements an den Benutzer). In dem Block 3630 wird als Reaktion auf die Auswahl des entsprechenden Befehlselements durch den Benutzer (z.B. ein Benutzer klickt auf die Menüoption oder das Symbolleistenelement oder durch Drücken der Tastenkombination bzw. der Funktionstaste, etc.) der dem entsprechenden Element zugeordnete Befehl zu einem entsprechenden Ziel geleitet (z.B. die Verfahrensbehandlungsroutine), und zwar zur Verarbeitung auf der Basis der Ziel- und Diensteigenschaften und ob es sich bei der aufrufenden Instanz um die Applet-Ebene oder die Anwendungsebene handelt, wie dies bereits vorstehend im Text beschrieben worden ist. In dem Block 3640 wird der dem ausgewählten Befehlselement zugeordnete Befehl verarbeitet.
Die Abbildung aus 37 zeigt ein Flussdiagramm eines Prozesses 3700 gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. In dem Block 3710 wird ein Befehlsobjekt gemäß der vorstehenden Beschreibung definiert. In dem Block 3720 wird ein Benutzeroberflächen-Elementobjekt (z.B. ein Symbolleisten-Elementobjekt, ein Menüoptionsobjekt, ein Tastenkombinationselementobjekt, etc.) gemäß der vorstehenden Beschreibung definiert. In dem Block 3730 wird ein Benutzerschnittstellen-Elementobjekt einem entsprechenden Befehlsobjekt zugeordnet. In einem Ausführungsbeispiel bereitet der Server in Laufzeit Befehle auf der Basis der Befehlsobjektdefinitionen vor. In einem Ausführungsbeispiel werden danach verschiedene Befehle an ihren entsprechenden Befehlselementen angebracht (z.B. Menüoptionen, Symbolleistenelemente, Tastenkombinationselemente, etc.). In einem Ausführungsbeispiel wird ein Befehl als eine Zeichenfolge vorbereitet, welche die Eigenschaften aufweist, die erforderlich sind, um den Befehl zu verarbeiten, wenn er durch den Benutzer ausgewählt oder eingeleitet wird (z.B. die Eigenschaft Ziel, die Eigenschaft Verfahren, die Eigenschaft Geschäftskomponente, etc.). In dem Block 3740 wird bestimmt, ob das Benutzerschnittstellenelement (z.B. Menüoption, Symbolleistenelement, etc.) aktiviert ist, wie dies vorstehend im Text beschrieben worden ist.
Wenn das Element aktiviert ist, wird in dem Block 3750 dem Benutzer angezeigt, dass es ausgewählt werden kann. In dem Block 3760 wird in Reaktion auf die Auswahl des Befehlselements durch den Benutzer eine entsprechend geeignete Instanz (z.B. Verfahrensbehandlungsroutine) bestimmt, um den ausgewählten Befehl zu verarbeiten, und zwar auf der Basis verschiedener vorstehend beschriebenen Faktoren, darunter die Eigenschaft Ziel und die Eigenschaft Geschäftskomponente, die dem ausgewählten Befehl zugeordnet sind, und ob es sich bei der aufrufenden Instanz um eine auf Applet-Ebene oder auf Anwendungsebene handelt. In dem Block 3770 wird der ausgewählte Befehl zu dem bestimmten Ziel geleitet (der Verfahrensbehandlungsroutine). In dem Block 3780 wird der ausgewählte Befehl verarbeitet (z.B. Aufruf des spezifizierten Verfahrens, das dem ausgewählten Befehl zugeordnet ist).
Direktes Post-When-Change (Direktes Senden bei Änderung)
Die Abbildung aus 38 zeigt ein Blockdiagramm der Beziehung zwischen verschiedenen Objekten gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Wie dies in der Abbildung aus 38 dargestellt ist, kann ein Geschäftsobjekt definiert und konfiguriert werden als eine logische Gruppierung oder Abbildung verschiedener Geschäftskomponenten (z.B. ein Geschäftsobjekt gruppiert für gewöhnlich eine oder mehrere Geschäftskomponenten in eine logische Informationseinheit). Wie dies hierin beschrieben und in der Abbildung aus 38 dargestellt ist, kann eine Geschäftskomponente definiert und konfiguriert werden als eine logische Gruppierung oder Abbildung zugrunde liegender Tabellen (z.B. Datenbanktabellen). Anders ausgedrückt stellt eine Geschäftskomponente für gewöhnlich eine Schicht der Umschließung (Wrapping) von zugrunde liegenden Tabellen dar. Jede zugrunde liegende Tabelle (z.B. Datenbanktabelle) weist für gewöhnlich eine Reihe von Datensätzen oder Zeilen auf. Jeder Datensatz oder jede Zeile kann eine Mehrzahl von Spalten oder Feldern aufweisen.
Die Abbildung aus 39 zeigt ein Blockdiagramm einer logischen Struktur einer Geschäftskomponente gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Wie dies in der Abbildung aus 39 dargestellt ist, kann eine Geschäftskomponente eine Reihe von Eigenschaften aufweisen, welche die entsprechende Geschäftskomponente betreffen (z.B. Name, wodurch der logische Name der Geschäftskomponente spezifiziert wird, Tabellenname, wodurch der tatsächliche Name der zugrunde liegenden Tabelle spezifiziert wird, etc.). Eine Geschäftskomponente weist ferner eine Reihe von Feldern auf, von denen jedes eine Reihe zugeordneter Eigenschaften aufweisen kann. Zum Beispiel kann ein Feld eine Eigenschaft Name aufweisen, die den Namen des Felds spezifiziert, eine Eigenschaft Spaltenname, die die Spalte der zugrunde liegenden Tabelle identifiziert, in welche das entsprechende Feld abgebildet wird, etc.
Für gewöhnlich kann der Wert eines bestimmten Felds abhängig sein von dem Wert eines anderen Felds. Die Abhängigkeit oder direkte Abhängigkeit zwischen Feldwerten kann auf unterschiedliche Art und Weise gegeben sein. Wenn zum Beispiel angenommen wird, dass ein Benutzer eine Adresse eingeben möchte, die für gewöhnlich mehrere Felder aufweist, so kann der Wert, den der Benutzer für ein bestimmtes Feld (z.B. das Feld Bundesland) eingibt, die Gruppe der gültigen Werte bestimmen, die der Benutzer in ein anderes Feld (z.B. das Feld Ort) eingeben kann. Als weiteres Beispiel kann ein bestimmtes Feld deaktiviert oder zum Nur-Lese-Feld werden, wenn sich der Wert in einem anderen Feld ändert. Ferner können Situationen gegeben sein, in denen sich die Art der Benutzeroberflächensteuerung oder des Benutzeroberflächenformats ändern kann, die bzw. das zur Darstellung eines bestimmten Felds eingesetzt werden kann, auf der Basis des in ein anderes Feld eingegebenen Wertes verändern. Zum Beispiel kann die Benutzerschnittstellensteuerung für ein bestimmtes Feld so konfiguriert werden, dass sie sich von einem Textfeld, in das der Benutzer einen Wert eingeben kann, in ein Kombinationsfeld ändert, in dem der Benutzer aus einer Liste vorhandener Werte auswählen kann.
In herkömmlicher Weise in einer Client-Server-Umgebung wartet der Client darauf, dass der Benutzer die Eingabe einer Reihe von Änderungen abschließt, die Änderungen an den Server zur Verarbeitung sendet und danach dem Benutzer eine andere Seite mit abhängigen Informationen zwischen Feldwerten anzeigt. Bei einer herkömmlichen Anwendung oder einem herkömmlichen System wartet der Client zum Beispiel darauf, dass der Benutzer die Eingabe aller Adressinformationen abschließt, wie zum Beispiel Bundesland, Ort, etc. und danach alle Änderungen an den Server sendet. Der Server sendet danach eine neue Seite an den Client zur Anzeige an den Benutzer, wobei diese relevante abhängige Informationen zwischen Feldern aufweisen kann. Dieses herkömmliche Verfahren oder diese herkömmliche Methode der Behandlung und Verarbeitung der Abhängigkeit oder direkten Abhängigkeit zwischen Feldwerten ist nicht effektiv, da Änderungen als Folge der direkten Abhängigkeit zwischen Feldwerten von dem Benutzer nicht direkt wahrgenommen werden, was die Benutzeroberflächenumgebung deutlich weniger interaktiv gestaltet. Nachdem der Benutzer zum Beispiel den Wert eines bestimmten Felds geändert hat (von dem der Wert und/oder das Layout eines anderen Felds abhängt), erkennt oder sieht der Benutzer nicht den Effekt der Änderung, bis nicht alle Änderungen an den Server gesendet worden sind und die neue Seite angezeigt wird.
Um das vorstehend genannte Problem zu lösen, wird gemäß einem Aspekt der vorliegenden Erfindung ein Verfahren bereitgestellt, bei dem eine Änderung eines Werts eines Felds, von dem Werte, Format oder Funktionalität anderer Felder abhängig sind, unverzüglich an den Server zur Verarbeitung gesendet wird (dies wird hierin auch als direkte Post-when-Change-Funktion oder direkter Post-when-Change-Mechanismus bzw. direktes Senden bei Änderung bezeichnet).
Gemäß einem Ausführungsbeispiel der vorliegenden Erfindung sind die Felder, von denen das bzw. die anderen Felder) abhängig sind, für direktes Post-when-Change in der Ablage gekennzeichnet. Diese Informationen stehen somit als Teil der Metadaten zur Verfügung. In einem Ausführungsbeispiel verwendet der Rahmen auf Client-Seite diese Informationen für die Entscheidung, wenn Änderungen von Feldwerten zur Verarbeitung an den Server gesendet werden sollen. Der Server reagiert danach unter Verwendung des vorstehend beschriebenen Benachrichtigungsmechanismus, so dass abhängige Änderungen als Folge der durch den Server verarbeiteten Änderungen zurück gesendet werden. Wenn zum Beispiel detektiert wird, dass sich der Wert eines bestimmten Felds geändert hat (dieses Feld ist für direktes Post-when-Change gekennzeichnet), so sendet der Client den Wert des speziellen Felds und die Werte anderer Felder auf Client-Seite, die sich geändert haben, direkt zur Verarbeitung an den Server. Der Server antwortet daraufhin unter Verwendung des Benachrichtigungsmechanismus, so dass die abhängigen Änderungen zurück gesendet werden, so dass der Client auf der Basis der abhängigen Änderungen entsprechende Maßnahmen ergreifen kann. Wenn die Änderung des Wertes eines ersten Felds zum Beispiel bewirkt, dass sich der Wert und/oder das Format eines zweiten Felds ändert, ändert der Client nach dem Empfang der Benachrichtigungen von dem Server den Wert und/oder das Format des Felds entsprechend. In einem Ausführungsbeispiel wird die Logik zur Ausführung des Prozesses des direkten Post-when-Change als Teil des Javascript-Codes implementiert, der auf der Client-Seite ausgeführt wird.
Die Abbildung aus 40 zeigt einige Eigenschaften oder Attribute eines Geschäftskomponentenfelds gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Zusätzlich zu den typischen Eigenschaften oder Attributen, wie Name, Spaltenname, etc., kann ein Geschäftskomponentenfeld auch eine Eigenschaft oder ein Attribut aufweisen, die bzw. das zur Kennzeichnung des entsprechenden Geschäftskomponentenfelds für eine direkte Verarbeitung mit direktem Senden bei Änderung (Post-when-Change) gemäß der vorstehenden Beschreibung verwendet wird. Zu Zwecken der Erläuterung und Veranschaulichung kann diese Eigenschaft als Eigenschaft "direktes Senden bei Änderung" bezeichnet werden. In einem Ausführungsbeispiel kann diese Eigenschaft auf einen Wert (z.B. WAHR) gesetzt werden, um anzuzeigen, dass das entsprechende Geschäftskomponentenfeld für eine Verarbeitung des direkten Sendens bei Änderung gekennzeichnet ist und im anderen Fall auf einen anderen Wert (z.B. FALSCH) gesetzt werden. Wie dies vorstehend im Text beschrieben worden ist, wird diese Information von dem Rahmen auf Client-Seite dazu verwendet, zu entscheiden, wann Änderungen von Feldwerten zur Verarbeitung an den Server gesendet werden.
Die Abbildung aus 41 zeigt ein Flussdiagramm eines Ausführungsbeispiels eines Verfahrens bzw. Prozesses gemäß den Lehren der vorliegenden Erfindung. In dem Block 4110 werden ein oder mehrere Felder identifiziert, von denen andere Felder) abhängig sind. In dem Block 4120 werden die identifizierten Felder für eine Verarbeitung des direkten Sendens bei Änderung markiert. Wie dies bereits vorstehend im Text beschrieben worden ist, werden in einem Ausführungsbeispiel die identifizierten Felder in der Ablage markiert (z.B. durch Setzen der entsprechenden Eigenschaft dieser Felder auf einen bestimmten Wert), und somit steht diese Information als Teil der Metadaten zur Verfügung. In dem Block 4130 detektiert der Client in Laufzeit, ob die Werte der markierten bzw. gekennzeichneten Felder sich geändert haben. Wenn die Werte der gekennzeichneten Felder sich geändert haben, sendet der Client in dem Block 4140 deren Werte und die Werte der anderen Felder auf Client-Seite, die sich geändert haben, zur Verarbeitung an den Server. In dem Block 4150 verarbeitet der Server die Änderungen und reagiert unter Verwendung des Benachrichtigungsmechanismus, indem die abhängigen Änderungen zu dem Client gesendet werden.
Busy State Manager (Manager für beschäftigten Zustand)
Eines der auftretenden Probleme in einer traditionellen HTML- oder Web-basierten Anwendung ist es, dass wenn ein Client (z.B. der Browser) eine Anforderung zur Verarbeitung an einen Server sendet, diese abläuft, wenn der Server nicht innerhalb eines bestimmten Zeitraums antwortet bzw. reagiert. Dieser Ablaufzustand tritt trotz der Tatsache in Kraft, dass bestimmte Anforderungen eine lange Verarbeitungszeit benötigen, abhängig von verschiedenen Faktoren, wie etwa der Art der Anforderung, den verfügbaren Ressourcen an dem Server und der Anzahl der Anforderungen, die verarbeitet werden, oder darauf warten, durch den Server verarbeitet zu werden, etc. Zum Beispiel kann ein Client in einer traditionellen Web-basierten HTML-Anwendung eine Anforderung senden, die eine sehr zeitaufwändige Abfrageoperation in einer großen Datenbank beinhaltet. Diese Anforderung kann unter Umständen noch nicht abgeschlossen sein, wenn der Ablaufzustand eintritt.
Gemäß einem Ausführungsbeispiel der vorliegenden Erfindung wird ein Mechanismus bereitgestellt, so dass wenn ein Client eine Anforderung an einen Server sendet, die lange laufende oder zeitaufwändige Operationen auf der Server-Seite umfasst, der Server den Client entsprechend unter Verwendung des vorstehend beschriebenen Benachrichtigungsmechanismus informieren kann. Auf der Basis der durch den Server bereitgestellten Informationen in Bezug auf die Anforderung kann der Client entsprechende Maßnahmen unternehmen, um einen Benutzer über den Status der Anforderung zu informieren (z.B. durch Anzeigen einer Fortschrittsanzeige, die anzeigt, welcher Anteil der Aufgabe bislang ausgeführt worden ist, etc.). In einem Ausführungsbeispiel können die Kommunikationen in Bezug auf den Status und den Fortschritt der Anforderung so verwaltet werden, wie dies nachstehend im Text näher beschrieben ist.
Die Abbildung aus 42 zeigt ein Blockdiagramm eines Ausführungsbeispiels einer Systemkonfiguration gemäß den Lehren der vorliegenden Erfindung. Wie dies in der Abbildung aus 42 dargestellt ist, kann der Client eine Komponente aufweisen, die als Busy State Manager (Manager für beschäftigten Zustand) bezeichnet wird, die so konfiguriert ist, dass sie den Status und den Fortschritt einer an den Server gesendeten Anforderung überwacht und den Benutzer entsprechend darüber informiert, und zwar auf der Basis der durch den Server bereitgestellten Informationen (z.B. durch den Server bereitgestellte Informationen in Bezug auf den Status und den Fortschritt der Anforderungsverarbeitung). In einem Ausführungsbeispiel kann der Server auch einen Busy State Manager (Manager für beschäftigten Zustand) auf der Server-Seite aufweisen, der so konfiguriert ist, dass er den Client über den Status und den Fortschritt der von dem Client empfangenen Anforderung informiert. In einem Ausführungsbeispiel ist der Busy State Manager (Manager für beschäftigten Zustand) auf der Server-Seite so konfiguriert, dass er nach dem Empfang der Anforderung von dem Client bestimmt, ob die Anforderung lange laufende Server-Operationen umfassen kann oder lange bis zur vollständigen Ausführung benötigen kann, auf der Basis verschiedener Faktoren. In einem Ausführungsbeispiel können diese verschiedenen Faktoren den Typ der Anforderung aufweisen, die Priorität der Anforderung, die für die Anforderungsverarbeitung verfügbaren Ressourcen, die Anzahl der ausstehenden Anforderungen, die Anforderungen aufweisen können, die verarbeitet werden, sowie Anforderungen, die in einer Warteschlange auf die Verarbeitung durch den Server warten, etc.
Nach der Bestimmung, dass die von dem Client empfangene Anforderung lange benötigen kann, um verarbeitet zu werden (z.B. die Anforderung umfasst lange ausgeführte Server-Operationen, etc.), benachrichtigt der Server in einem Ausführungsbeispiel den Client entsprechend. Nachdem der Client in einem Ausführungsbeispiel durch den Server informiert worden ist, dass die Verarbeitung der Anforderung lange Zeit in Anspruch nehmen kann, kann der Client den Benutzer darüber informieren, dass die Verarbeitung der Anforderung begonnen hat, und wobei die Benutzeroberfläche während der Zeit gesperrt werden kann, während der die Anforderung durch den Server verarbeitet wird. In einem Ausführungsbeispiel informiert der Server den Client weiter über den Fortschritt der Anforderung, und der Client kann die entsprechenden Maßnahmen ergreifen, um den Benutzer entsprechend zu informieren, bis die Verarbeitung der Anforderung abgeschlossen ist. Nach dem Empfang der Fortschrittsinformationen von dem Server über Benachrichtigungen kann der Client zum Beispiel eine Fortschrittsanzeige aktualisieren, um dem Benutzer zu zeigen, welcher Anteil der Aufgabe bis zu diesem Zeitpunkt abgeschlossen worden ist. In einem Ausführungsbeispiel bleibt die Benutzeroberfläche weiter gesperrt, bis die Anforderungsverarbeitung abgeschlossen ist.
Die Abbildung aus 43 zeigt ein Flussdiagramm eines Prozesses 4300 gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. In dem Block 4310 sendet der Client eine Anforderung an einen Server. In dem Block 4320 bestimmt der Server, dass die Verarbeitung der Anforderung lange Zeit in Anspruch nehmen kann (z.B. die Anforderung umfasst lange laufende Server-Operationen, etc.). In dem Block 4330 benachrichtigt der Server den Client darüber, dass die vollständige Ausführung der Anforderung lange Zeit in Anspruch nehmen kann. In einem Ausführungsbeispiel kommuniziert der Server diese Informationen an den Client unter Verwendung des vorstehend beschriebenen Benachrichtigungsmechanismus. In dem Block 4340 sperrt der Client die Benutzeroberfläche und informiert den Benutzer darüber, dass die Anforderungsverarbeitung begonnen hat und deren vollständige Ausführung lange Zeit in Anspruch nehmen kann. In dem Block 4350 benachrichtigt der Server den Client über den Fortschritt der Verarbeitung der Anforderung. In dem Block 4360 informiert der Client den Benutzer über den Fortschritt der Verarbeitung der Anforderung (z.B. unter Verwendung einer Fortschrittsanzeige) auf der Basis der durch den Server bereitgestellten Informationen. In dem Schritt 4370 sperrt der Client weiter die Benutzeroberfläche und informiert den Benutzer über den Fortschritt der Anforderung auf der Basis der durch den Server bereitgestellten Fortschrittsinformationen bis die Verarbeitung der Anforderung abgeschlossen ist.
III. Caching
Wie dies bereits vorstehend im Text beschrieben worden ist, können Objekte in dem Browser und von dem OM verwaltete Objekte so konfiguriert werden, dass sie sich an einer oder mehreren Computervorrichtungen befinden und darin betrieben werden. Wie dies vorstehend dargestellt worden ist, veranschaulich die Abbildung aus 6A eine beispielhafte Konfiguration 600, bei der Objekte 502 in dem Browser und durch den OM verwaltete Objekte 504 sich an mehreren Computervorrichtungen 602 und 604 befinden und dort arbeiten, wobei die Vorrichtungen einen Client 602 und einen Server 604 aufweisen. Die Abbildung aus 6B veranschaulicht eine beispielhafte Konfiguration 650, bei der sich Objekte 502 in dem Browser und durch den OM verwaltete Objekte 504 in einer Computervorrichtung 652 befinden und dort arbeiten.
Die Abbildung aus 44 zeigt allgemein ein teilweises Blockdiagramm eines Rahmens oder einer Infrastruktur, die in einer Konfiguration 4400 mit mehreren Vorrichtungen ähnlich der Konfiguration 600 aus 6A und gemäß der vorstehenden Beschreibung in dem Begleittext zu 6A arbeitet. Die Abbildung aus 44 zeigt einen Browser 4402, der auf dem Client 4404 ausgeführt wird. Der Browser 4402 kommuniziert mit dem Server 4406 unter Verwendung des RPC-Mechanismus 4408 und des Benachrichtigungsmechanismus 4410, die beide vorstehend bereits näher beschrieben worden sind.
Eine Ansicht des Objekts JSSView 4412 und eine Mehrzahl von Applets oder JSSApplet Objekten 4414₁ , 4414₂ , ..., 4414_N , wobei N eine positive ganze Zahl ist, sind in einer Ausführung in dem Browser 4402 dargestellt. Das Objekt JSSView 4412 stellt allgemein eine Ansicht dar. Wie dies bereits vorstehend im Text beschrieben worden ist, ist eine Ansicht allgemein ein Anzeigefeld, das aus einer bestimmten Anordnung von Applets besteht. Wie dies bereits vorstehend im Text beschrieben worden ist, ist ein Applet allgemein eine visuelle Anwendungseinheit, die auf dem Bildschirm als Teil einer Ansicht erscheint. Jedes Applet oder JSSApplet Objekt 4414₁ , 4414₂ , ..., 4414_N stellt ein Applet dar, das der durch die Ansicht oder das JSSView Objekt dargestellten Ansicht zugeordnet ist.
Der Client 4404 weist einen Cache 4416 auf, um allgemein Ansichten zu speichern, was der Leistungsverbesserung dienen soll. Zeitweise kann der Benutzer zu den neuen Ansichten navigieren bzw. umschalten, wobei bewirkt wird, dass der Client 4404 entsprechende Ansichten an den Server 4406 sendet, um zu neuen Ansichten zu navigieren. Wenn, wie dies bereits vorstehend im Text beschrieben worden ist, der Client 4404 eine Anforderung zum Navigieren zu einer Ansicht an den Server 4406 sendet, so sendet der Server 4406 eine Antwort oder Benachrichtigung, welche das Ansichtslayout aufweist, ohne Daten. Folglich wäre ein Umlauf zu dem Server 4406 (einschließlich einer Anforderung von dem Client 4404 an den Server 4406 und einer Antwort oder Benachrichtigung von dem Server 4406 an den Client 4404) für gewöhnlich erforderlich, um das Ansichtlayout abzurufen und um individuelle Optionen von dem Server 4406 anzuzeigen. Das Ansichtlayout und die individuellen Ansichtoptionen sind allgemein in der Abbildung aus 45 dargestellt und werden nachstehend im Text in Bezug auf die Abbildung aus 45 beschrieben. Hiermit wird festgestellt, dass jeder Umlauf (Round-Trip) wertvolle Rechenressourcen verbrauchen und zeitliche Verzögerungen erzeugen würde. Nach dem Senden des Ansicht des Ansichtlayouts der individuellen Ansichtoptionen zu dem Client 4404 würde der Server 4406 danach eine Antwort senden, die Daten aufweist, die dazu dienen, die Ansicht zu populieren.
Zur Verbesserung de Leistung können eine oder mehrere Ansichtlayouts und individuelle Ansichtoptionen in dem Cache gespeichert werden. Sobald das Layout und die Benutzeroptionen der Ansicht in dem Cache gespeichert sind, kann die Ansicht allgemein als eine im Cache gespeicherte Ansicht bezeichnet werden. Wenn der Benutzer zu der im Cache gespeicherten Ansicht navigiert, kann der Client 4404 das Ansichtlayout und die individuellen Ansichtoptionen aus dem Cache anstatt aus dem Server abrufen. Durch Abrufen des Ansichtlayouts und der individuellen Ansichtoptionen aus dem Cache kann ein Umlauf (Round-Trip) zu dem Server 4406 eliminiert werden, wodurch die Systemleistung verbessert werden kann.
Die Abbildung aus 45 zeigt allgemein die Struktur eines beispielhaften Cache 4416 gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Wie dies in der Abbildung dargestellt ist, kann der Cache 4416 eine Mehrzahl von Cache-Einträgen 4518₁ , 4518₂ , ..., 4518_M aufweisen, wobei M eine positive ganze Zahl ist. In einem Ausführungsbeispiel kann jeder Cache-Eintrag 4518₁ , 4518₂ , ..., 4518_M so gestaltet sein, dass er ein Layout 4520 der Ansicht speichert. Wie dies bereits vorstehend im Text beschrieben worden ist, stellt eine Ansicht allgemein ein Anzeigefeld dar, das aus einer bestimmten Anordnung von Applets besteht. Demgemäß kann das Layout der Ansicht allgemein die Layouts 4524₁ , 4524₂ , ..., 4524_N der Applets, die der Ansicht zugeordnet sind, aufweisen.
In einem Ausführungsbeispiel kann jeder Cache-Eintrag 4518₁ , 4518₂ , ..., 4518_M auch als individuelle Optionen 4522, die der Ansicht zugeordnet sind, gestaltet sein. In einem Ausführungsbeispiel kann die Ansicht individueller Optionen 4522 Tastenkombinationen 4526 und Präferenzen 4528 aufweisen. Eine Tastenkombination 4526 ist allgemein eine Folge von Tasten oder Tastenanschlägen, die auf ein Befehlsobjekt abgebildet wird. Ein beispielhaftes Befehlsobjekt ist dargestellt und wurde vorstehend allgemein beschrieben. Präferenzen 4528 sind allgemein entweder standardmäßige oder von einem Benutzer ausgewählte Anzeigeoptionen. Beispielhafte Präferenzen sind unter anderem die Schriftart, die Schriftgröße, Schriftfarben, Spalten- und Zeilenbreiten, etc.
Die Abbildung aus 46 zeigt allgemein einen Überblick über den beispielhaften Prozess 4600 des Cachings einer Ansicht. In dem Block 4605 empfängt der Client eine Anforderung von dem Benutzer zum Wechseln zu einer Ansicht. Der Client bestimmt, ob die Ansicht aktuell in dem Cache gespeichert wird (Block 4610). Wenn die Ansicht aktuell nicht in dem Cache gespeichert wird, ruft der Client das Ansichtlayout und die individuellen Ansichtoptionen von dem Server ab (Block 4615). Das Ansichtlayout und die individuellen Ansichtoptionen sind in der Abbildung aus 45 dargestellt und wurden vorstehend im Text bereits in Bezug auf diese Abbildung beschrieben. In dem Block 4620 bestimmt der Client, ob der Cache voll ist. Wenn der Cache weiter verfügbaren Speicherplatz aufweist, fährt der Client mit der Cache-Speicherung der Ansicht fort. Wenn der Cache voll ist, leert der Client den Cache, um Speicherplatz in dem Cache für die Ansicht frei zu machen (Block 4625), wobei er danach mit dem Caching der Ansicht fort fährt. Das Caching der Ansicht kann das Caching des Ansichtlayouts aufweisen (Block 4630). Das Caching der Ansicht kann ferner das Caching der individuellen Ansichtoptionen aufweisen (Block 4635).
Die Abbildung aus 47 bietet einen allgemeinen Überblick über einen exemplarischen Prozess 4700 des Wechselns zu einer Ansicht. In dem Block 4705 empfängt der Client eine Anforderung von einem Benutzer zum Wechseln zu einer Ansicht. Der Client bestimmt, ob die Ansicht aktuell in dem Cache gespeichert wird (Block 4710). Wenn die Ansicht aktuell nicht in dem Cache gespeichert wird, ruft der Client das Ansichtlayout und die individuellen Ansichtoptionen von dem Server ab (Block 4715). Hiermit wird festgestellt, dass das Ansichtlayout und die individuellen Ansichtoptionen in der Abbildung aus 45 dargestellt und vorstehend in Bezug auf den die Abbildung begleitenden Text allgemein beschrieben worden sind.
Wenn die Ansicht aktuell in dem Cache gespeichert wird, ruft der Client das Ansichtlayout und die individuellen Ansichtoptionen aus dem Cache ab (Block 4720). Hiermit wird festgestellt, dass der Client einen Umlauf (Round-Trip) zu dem Server speichern würde, indem das Ansichtlayout und die individuellen Ansichtoptionen aus dem Cache abgerufen werden, wodurch die Systemleistung verbessert wird. Nach dem Abruf des Ansichtlayouts und den individuellen Ansichtoptionen zeigt der Client die Ansicht unter Verwendung des Ansichtlayouts an (Block 4725) und wendet die individuellen Ansichtoptionen auf die Ansicht an (4730). Nach dem Anzeigen der Ansicht ruft der Client Daten für die Ansicht von dem Server ab (Block 4735). Nach dem Empfang der Daten von dem Server populiert bzw. belegt der Client Felder in der Ansicht mit den abgerufenen Daten (Block 4740).
Die Abbildung aus 48 veranschaulicht ein exemplarisches Flussdiagramm für ein Ausführungsbeispiel eines Verfahrens zum implizierten erzwungenen Wegschreiben einer Aktualisierung. In dem Block 4810 empfängt ein Datensatzfeld eine Aktualisierung. Die Aktualisierung kann eine Hinzufügung, eine Löschung oder eine Änderung in Bezug auf einen bestehenden Datensatzfeldwert darstellen. Die Aktualisierung wird in dem Client im Cache gespeichert. In dem Block 4820 empfängt das Anwendungsmodul eine Kontextänderungsanforderung. In dem Block 4830 fordert das Anwendungsmodul das Datensatzfeld zur Übermittlung der im Cache gespeicherten Aktualisierung an das Anwendungsmodul auf. In dem Block 4840 empfängt das Anwendungsmodul die Aktualisierung von dem Datensatzfeld. In dem Block 4850 übermittelt das Anwendungsmodul die von dem Datensatzfeld empfangene Aktualisierung zu dem Server, um die Aktualisierung in eine Datenbank wegzuschreiben. In dem Block 4860 übermittelt der Server eine Benachrichtigung an die Anwendung, um anzuzeigen, dass die Aktualisierung erfolgreich weggeschrieben worden ist. In dem Block 4870 übermittelt das Anwendungsmodul die Kontextänderungsanforderung an den Server. In dem Block 4880 verarbeitet der Server die Kontextänderungsanforderung und gibt einen neuen Kontext an das Anwendungsmodul zurück.
Die Abbildung aus 49 veranschaulicht ein exemplarisches Ausführungsbeispiel der Anzeige. Die Anzeige 4938 ist als eine Komponente des Web-Browsers 4900 dargestellt. Die Anzeige 4938 zeigt den Aktualisierungswert "neues Konto" (New Account) des Datensatzfelds 522. Der Aktualisierungswert wird als Reaktion auf eine Kontextänderung implizit erzwungen weggeschrieben. Die Abbildung aus 50 veranschaulicht die Kontextänderung, bei der die Anzeige 5030 für ein neues Datensatzfeld ausgewählt wird.
Diese und weitere Ausführungsbeispiele der vorliegenden Erfindung können gemäß den Lehren der vorliegenden Erfindung realisiert werden, und es sollte erkennbar sein, dass verschiedene Modifikationen und Änderungen in Bezug auf diese Lehren möglich sind, ohne dabei vom Umfang der Erfindung abzuweichen. Die Beschreibung und die Zeichnungen dienen somit Veranschaulichungszwecken und schränken nicht ein, und die Erfindung ist gemäß den Ausführungen in den Ansprüchen auszulegen.
Darüber hinaus können die vorstehend beschriebenen Anweisungen bzw. Befehle zur Ausführung der Verfahren auch in anderen Formen von computerlesbaren Medien gespeichert werden. Ein maschinenlesbares Medium weist jeden Mechanismus auf, der Informationen in einer Form bereitstellt (z.B. speichert und/oder übermittelt), die eine Maschine (z.B. ein Computer) lesen kann. Ein maschinenlesbares Medium umfasst beispielsweise Nur-Lesespeicher (ROM), Direktzugriffsspeicher (RAM), Magnetplattenspeichermedien, optische Speichermedien, Flash-Speicherbausteine, elektrische, optische, akustische oder in anderer Form ausgebreitete Signale (z.B. Trägerwellen, Infrarotsignale und digitale Signale).

Claims

Verfahren zum impliziten erzwungenen Wegschreiben ungespeicherter Daten für eine World Wide Web-Anwendung (524) an einen Server (504) als Reaktion auf eine Kontextänderungsanforderung, wobei das Verfahren folgendes umfasst: a) das Senden einer ungespeicherten Datumsanforderung an ein aktives Applet (522) als Reaktion auf eine andere Kontextänderungsanforderung als eine Aktivierung einer Speicher- oder erzwungenen Wegschreibeaktion; b) das Übermitteln einer Cache-Anforderung von dem aktiven Applet (522) an eine Geschäftskomponente (518) als Reaktion auf dem Empfang der ungespeicherten Datumsanforderung; c) das Bestimmen durch die Geschäftskomponente (518), ob der Cache (568) etwaige ungespeicherte Benutzereinträge aufweist, und wobei eine resultierende Cache-Benachrichtungsanforderung übermittelt wird; d) das Auslösen einer Post-Anforderung durch das aktive Applet (522), welche die ungespeicherten Daten aus dem Cache (568) aufweist, als Reaktion auf den Empfang der Cache-Benachrichtungsanforderung; und e) das Verarbeitender Post-Anforderung durch den Server (504) durch erzwungenes Wegschreiben der ungespeicherten Daten in eine Datenbank.
Verfahren nach Anspruch 1, wobei die Kontextänderungsanforderung eine Anzeigeänderung für einen World Wide Web-Browser aufweist.
Verfahren nach Anspruch 1, wobei die Kontextänderungsanforderung eine Änderung eines aktiven Applets aufweist.
Verfahren nach Anspruch 1, wobei die Kontextänderungsanforderung eine Änderung in einem zur Bearbeitung ausgewählten Datensatzfelds aufweist.
Verfahren nach einem der vorstehenden Ansprüche, wobei dieses ferner das Speichern eines Eintrags in einem Datensatzfeld unter Verwendung eines Client-Caches umfasst.
Verfahren nach Anspruch 5, wobei dieses ferner das Verwalten des Eintrags in dem Datensatzfeld in dem Cache durch die Anwendung (524) umfasst, bis der Eintrag in dem Datensatzfeld zu dem Server (504) übertragen wird.
Verfahren nach Anspruch 1, wobei dieses ferner das Steuern aller direkten Kommunikationen mit dem Server (504) durch die Anwendung (524) umfasst.
Verfahren nach einem der vorstehenden Ansprüche, wobei das aktive Applet (522) eine Anforderung für keine ungespeicherten Daten an die Anwendung (524) übermittelt.
Verfahren nach Anspruch 8, wobei die Anforderung für keine ungespeicherten Daten anzeigt, dass der Cache (588) keine ungespeicherten Daten aufweist.
Verfahren nach einem der vorstehenden Ansprüche, wobei die Geschäftskomponente (518) den Cache (568) löscht, nachdem die Cache-Benachrichtigungsanforderung übermittelt worden ist.
Verfahren nach einem der vorstehenden Ansprüche, wobei die Anwendung (524) automatisch die Kontextänderungsanforderung über ein entferntes Prozeduraufrufmodul (528) zu dem Server (504) übermittelt, als Reaktion auf dem Empfang entweder der Post-Anforderung oder der Anforderung für keine ungespeicherten Daten.
Verfahren nach einem der vorstehenden Ansprüche, wobei die Anwendung (524) die Post-Anforderung über das entfernte Prozeduraufrufmodul (528) zu dem Server (504) weiterleitet.
Verfahren nach einem der vorstehenden Ansprüche, wobei der Server (504) als Reaktion auf den Empfang der Post-Anforderung die Post-Anforderung automatisch verarbeitet.
Verfahren nach einem der vorstehenden Ansprüche, wobei der Server (504) eine Serverbenachrichtigung zu einem Client (502) übermittelt, wobei die Serverbenachrichtigung entweder eine Erfolgsnachricht aufweist, die anzeigt, dass die ungespeicherten Daten erfolgreich in der Datenbank gespeichert worden sind, oder eine Fehlernachricht, die anzeigt, dass die ungespeicherten Daten nicht in der Datenbank gespeichert werden können.
Verfahren nach einem der vorstehenden Ansprüche, wobei der Server (504) die Kontextänderungsanforderung automatisch verarbeitet, als Reaktion auf den Empfang der Kontextänderungsanforderung.
Verfahren nach einem der vorstehenden Ansprüche, wobei der Server (504) die Kontextänderungsanforderung verarbeitet, indem ein angeforderter neuer Kontext über das entfernte Prozeduraufrufmodul (528) zu einem Client (502) übermittelt wird.
Computerlesbares Medium, in dem eine Reihe von Anweisungen zur Umsetzung von Anweisungen gespeichert sind, die bei einer Ausführung durch einen Prozessor bewirken, dass der Prozessor alle Schritte eines Verfahrens ausführt, das in einem der Ansprüche 1 bis 16 beansprucht wird.
Computerprogramm, das einen Programmcode umfasst, der bei einer Ausführung auf einem Computer alle Schritte eines Verfahrens ausführt, das in einem der Ansprüche 1 bis 16 beansprucht wird.