DE19805891A1

DE19805891A1 - Telephonie-Schalter-Konfigurator

Info

Publication number: DE19805891A1
Application number: DE19805891A
Authority: DE
Inventors: Paul Erb; Brian Macisaac
Original assignee: Mitel Corp
Current assignee: Mitel Networks Corp
Priority date: 1997-02-13
Filing date: 1998-02-13
Publication date: 1998-08-27
Anticipated expiration: 2018-02-14
Also published as: IL123279A0; GB9802888D0; CA2197517C; IE980103A1; DE19805891B4; FR2760307A1; GB2323249A; GB2323249B; US6246678B1; CA2197517A1

Description

Die Erfindung betrifft einen Telephonie-Schalter-Konfigurator zum Managen und Steuern wenigstens eines Telephonie-Schalters.

Die Architektur der Wahl für heutige Computer-Umgebungen wird als Client/Server-Computing bezeichnet. In diesem Modell zieht der Nut zer Vorteil aus der Verwendung eines intelligenten Terminals und wird mit verschiedenen Anwendungen und Diensten durch ein Lokalbereichsnetz werk (LAN) verbunden. Das Lokalbereichsnetzwerk ermöglicht den Zugang zu teueren Ressourcen und Peripherie-Geräten. Das Client/Server-Modell er weitert den gemeinsamen Zugriff auf Dateien, Datenbasen und Anwendungen sowie Hardware-Ressourcen. Hierbei hat jeder Tischrechner Zugriff zu ei nem Server, um das zu erhalten, was er benötigt. Wenn der Benutzer einen Datensatz auf den neuestens Stand bringt, ist es gewöhnlich die Server- Datenbasis, die auf den neuesten Stand gebracht wird, so daß jeder in einer Arbeitsgruppe an der neuesten Dateninformation teilhat. Die Ausle gung Client/Server-Anwendungen erlaubt es dem Benutzer, ihre Bildschirme einzurichten, um spezifische Bedürfnisse und Präferenzen bei vorteilhaf ter gemeinsamer Information zu entsprechen.

Das Client/Server-Modell ist insbesondere in bezug auf seine Fähigkeit stark, Maschinen von verschiedenen Anbietern zu mischen und diesen zu entsprechen. Der Benutzer kann den für eine besondere Aufgabe besten Server auswählen, jedoch Klienten-Maschinen und Einrichtungen an derer Art von anderen Anbietern wählen, die auf einem bevorzugten grafi schen Nutzer-Interface oder anderen persönlichen Parametern wie Multime dia etc. basieren. Neue Server, die Bedeutung erlangen, sind Fax-Server, E-Mail-Server, Voice-Mail-Dienste. Telephonie-Schalter sind traditionell nicht ausgelegt, um in das Client/Server-Modell zu passen.

Hardware sowohl der Workstation als auch des Servers werden durch eine Software-Ebene gesteuert, die als Operationssystem (O/S) be zeichnet wird. Das Operationssystem isoliert die Anwendung davon, diese Details der Hardware kennen zu müssen, und liefert eine konsistente In frastruktur, auf der alle Anwendungen laufen.

Eines der Schlüsselelemente moderner Anwendungsentwicklung und Auslegung ist das Konzept einer Anwendungsprogrammierungsschnittstelle (APS). Die APS liefert eine definiertes Interface zwischen verschiedenen Einrichtungen oder Software-Ebenen in dem Computer-Modell, so daß Soft ware-Entwickler sich auf ihre Anwendung konzentrieren können. Um dies zu erreichen, werden sie mit den notwendigen Befehlen versehen, die die Einrichtung oder andere Anwendungen steuern, ohne daß bekannt ist, wie sie arbeiten. APSs sind relevant sowohl für Tischrechner-Anwendungen als auch für Server-Anwendungen. APSs sind ebenfalls ein wichtiges Konzept in bezug auf das Programmieren von Telephonie-Servern. Die meisten pri vaten Nebenstellenanlagen (PBXs) haben heutzutage irgendeine Form von Software-APS.

Im mittleren und großen Geschäft werden internationale Tele fonanrufe über einen privaten Telefonschalter oder PBX gehandhabt. Da die PBX im wesentlichen eine digitale elektronische Einrichtung ist, hat eine natürliche Evolution zur Computer-Telephonie-Integration (CTI) in der Notwendigkeit der Verbindung von PBXs mit Lokalbereichsnetzwerken geführt, um so als eine vom Netzwerk zugreifbare Einrichtung zu funktio nieren.

Das Modell, das zum Beschreiben von Telefonnetzwerk-Architek turen verwendet wird, ist ziemlich einfach. Benutzer mit einer Terminal einrichtung (d. h. einem Telefon) werden mit einem Telephonie-Schalter verbunden, der eine Reihe von Diensten offeriert.

Das Telefon ist die bekannteste Terminaleinrichtung. Es kann sich um ein Analog- oder Digitaltelefon handeln, das Drucktasten, Anzei gen haben und auch drahtlos sein kann. Terminaleinrichtungen umfassen auch Fax-Maschinen, Modems, Videophone, Alarmsysteme, LAN-Ausrüstung und Multimediakarten für PCs. Eine Terminaleinrichtung ist ein Hardware- Teil, das an das Netzwerk angeschlossen werden und Zugriff zum PBX er halten kann. Neue Terminaleinrichtungen können jederzeit dem Netzwerk zugefügt werden und haben unmittelbaren Zugriff zum Bereich der Dienste, die hiermit kompatibel sind. Neue Dienste werden gewöhnlich in Zusammen hang mit dem Terminal-Einrichtungsdesign eingeführt, um diese Einrich tungen leicht benutzbar zu machen.

Die Hardware des PBX wird auch durch eine Operationssystemebe ne der Software gesteuert. Die Telecom-Umgebung hat spezielle Anforde rungen, die Vielfachbenutzungs-, Realzeit-, Fehlertolerante Operations systeme erfordern. Selbst ein modernstes Businesstelefon ist eine stumme Einrichtung, die darauf reagiert, welcher Knopf zum Host-Rechner ge drückt wird.

Das Herz eines modernen Schaltsystems ist ein Satz von Softwa re-Anwendungen, die kollektiv als Processing bezeichnet werden. Diese Software liefert sämtliche Funktionalität, die vom Benutzer erwartet wird, vom einfachen Anruf bis zum Liefern der Anruferidentität (ID). Die Software liefert dem Benutzer auch Dinge wie Anrufweiterleitung, verbes serte Netzwerkdienste wie Anruflenkung und spezialisierte Anrufbehand lung wie ACD für Anrufzentren. Die Anrufverarbeitung ist ein kritisches Element bei der Auslegung von flexiblen, konfigurierbaren, beibehaltba ren Kommunikationsnetzwerken.

Es ist daher notwendig, Software zu besitzen, die innerhalb des PBX oder des Schalters läuft und die einer außenseitigen Anwendung eine Kontrolle darüber liefert, was vorgeht. Moderne PBX-Systeme liefern über zweihundert Eigenschaften, um die Anrufhandhabung zu verbessern, obwohl die Vielzahl der Benutzer niemals mehr als vier von diesen nutzt. Um dies zu offerieren, sind Befehle verfügbar, die in dem Schalter die Möglichkeiten aktivieren, suspendieren oder abschalten. Die Möglichkei ten umfassen eine integrierte Stimmantwort (IVR), Voice-Mail/automati sierte Bedienung und dergleichen.

Bewegungen und Änderungen des Profils eines Telephonie-Schal ters als Ergebnis der Bewegung von Leuten innerhalb einer Organisation bleiben schwierig zu managen. Das Adressieren wird mit jedem Netzwerk- Element komplex, das zu reprogrammieren ist, um seine Dienst- und Re striktionsklasse zu ändern. Es wäre daher wünschenswert, ein PBX-System zu haben, bei dem es nicht erforderlich ist, jeden Monat derartige Ände rungen durchzuführen.

Für die meisten Organisationen, die auf großen Geländen oder komplexen Bereichen angesiedelt sind, wird eine Architektur typischer weise ausgeführt, die multiple PBX-Komponenten aufweist, die über das Gelände oder den Bereich verteilt sind. Diese PBX-Komponenten können mit Netzwerk-Adapterkarten versehen und über eine LAN-Backbone-Infrastruktur miteinander verbunden sein.

Eines der bei großen Bereichen existierenden Probleme für mul tiple PBXs besteht im Management der Komponenten. Viele PBXs arbeiten mit gebräuchlichen Sprachen und Operationssystemen. Viele Telephonie- Schalter sind nicht mit dem Computer-Netzwerk verbunden und selbst die jenigen, die dies sind, sind nicht leicht zu managen. Sie sind nicht da zu ausgelegt, in das Client/Server-Modell zu passen. Dies erfordert, daß ein Administrator mit dem Schalter und dem Schalter-Management-Interface vertraut ist, um die Beibehaltung von Eigenschaften auf dem Schalter zu ermöglichen. Zusätzlich ist es bei PBXs üblich, daß sie in bezug auf ih re interne Operation konfiguriert sind, die Tabellen mit Information verwendet, die spezifische Merkmale und Operationen des Schalters be treffen (d. h. Nebenstellennummern, Merkmale zur Erweiterung, Routing usw.). Ein Administrator muß mit dem Layout der Merkmale vertraut sein, und zwar nicht nur für verschiedene Versionen des gleichen Schalters, sondern auch für verschiedene Ausführungen von Schaltern. Die Bewegung von Leuten und Merkmalen von einem Schalter zum anderen involviert ein Reprogrammieren und in vielen Fällen ein physisches Inspizieren und Log gen des Schalters. Ferner bestehen auch Schwierigkeiten, die mit dem Vorsehen einer Sicherung für den Schalter verbunden sind.

Aufgabe der Erfindung ist es daher, eine Architektur zu schaf fen, die es ermöglicht, einen oder mehrere Telephonie-Schalter zu mana gen und zu steuern, wobei Bewegungen und Änderungen von in den Telepho nie-Schaltern gespeicherter Information ermöglicht und getragen wird.

Diese Aufgabe wird entsprechend Anspruch 1 gelöst.

Hierdurch wird es außerdem möglich, nachfolgende Anwendungen und Verwendungen von Information durch den Telephonie-Schalter zu tra gen. Es wird ein allgemeiner Zugriff zu Telephonie-Schalter-Datenbasen und Views geliefert, die mit vorhergehenden Versionen von Telephonie- Schaltern kompatibel sind. Zugang zu einem Telephonie-Schalter wird in einer Protokoll-unabhängigen Weise geliefert. Der Zugriff wird geschaf fen in einer allgemeinen Weise zum Suchen, Lesen, Schreiben, Addieren, Löschen und weiteren Operationen. Der Telephonie-Schalter ist derart vorgesehen, daß er ein Transaktions-Management ermöglicht. Ferner ist ein Mechanismus für den Telephonie-Schalter vorgesehen, um mit anderen Netzwerk-Einrichtungen einschließlich anderen Telephonie-Schaltern zu kommunizieren. Eine Schalter-Datenbasis-Programmierverifikation ist vor gesehen, wobei Schalter-Datenbasis-Engineeringregeln befolgt werden.

Bevorzugt ist ein APS vorgesehen, das unabhängig von verschie denen Versionen von Operationssystemen und Schaltern ist, das es dem Schalter ermöglicht, mit einer Netzwerksteuerungsserver-Management-Sta tion zu kommunizieren. Auf letztere kann eine Datenbasis in dem Schalter zugreifen und Information löschen sowie derartige Information in einer anderen Datenbasis installieren. Diese Eigenschaft vereinfacht das Hinzufügen von neuen Merkmalen in dem Schalter.

Weitere Ausgestaltungen der Erfindung sind der nachfolgenden Beschreibung und den Unteransprüchen zu entnehmen.

Die Erfindung wird nachstehend anhand eines in den beigefügten Abbildungen dargestellten Ausführungsbeispiels näher erläutert:

Fig. 1 zeigt ein Blockdiagramm einer Netzwerkkonfiguration.

Fig. 2A und 2B zeigen ein Blockdiagramm einer Architektur des Telephonie-Schalter-Konfigurators.

Fig. 3A bis 3D zeigen ein Diagramm bezüglich des Nachrichten flusses zwischen einem Benutzer und einem Telephonie-Schalter.

Fig. 4 zeigt eine detailliertes Blockdiagramm eines OPS-Mana gers.

Fig. 5 zeigt eine detailliertes Blockdiagramm eines Netzwerk elementes in einem Telephonie-Schalter.

In Fig. 1 wird ein Überblick über eine Netzwerkkonfiguration gegeben, das es ermöglicht, Verbindungen direkt oder indirekt über ein Ethernet-Netzwerk vorzunehmen. Statt dessen können jedoch auch andere Netzwerkprotokolle, beispielsweise Tokenring, FDDI usw., verwendet wer den. Serielle Verbindungen können ebenfalls verwendet werden, obwohl Leistungsbetrachtungen in Betracht gezogen werden müssen. Bevorzugt er hält eine Management-Station 10 Zugang zu einem Telephonie-Schalter 20 über ein Lokalbereichsnetzwerk 30. Bevorzugt ist das Lokalbereichsnetz werk 30 ein Ethernet-Netzwerk, das mit TCP/IP läuft, jedoch können auch andere Netzwerktopologien und -protokolle verwendet werden. Alternativ kann die Management-Station 10 mit einem oder mehreren Telephonie-Schal tern 42, die in entfernten Netzwerken 44 vorhanden sind, über Schnitt stellen verbunden sein. Alternativ kann die Management-Station 10 mit einem Telephonie-Schalter 52 unter Verwendung von Routern 48 über Schnittstellen verbunden sein, die mit einem privaten oder öffentlichen Netzwerk 50 verbunden sind.

Eine Kombination von geschichteten Software-Komponenten kann verwendet werden, die mit existierender Software in der Management-Sta tion 10 und dem Telephonie-Schalter 20 zusammenarbeiten, um Zugang zu spezifischen Operationen des Telephonie-Schalters 20 zu erhalten. Um diesen Zugang zu liefern, wird sowohl in der Management-Station 10 als auch in dem Telephonie-Schalter 20 eine Datenbasis-Zugriffsebene ge schaffen. Die Datenbasis-Zugriffsebene wird durch einen DB-Zugriffsser ver 116, der in der Management-Station 10 resident ist, und einen Schal ter-Datenbasis-Server 118, der in dem Telephonie-Schalter 20 resident ist, erleichtert.

Folglich werden hierin sechs Hauptaspekte beschrieben:

(1) Interface zwischen der Anwendung und der Datenbasis-Zu griffsebene in der Management-Station;
(2) Datenbasis-Zugriffsebene in der Management-Station;
(3) Interface zwischen Datenbasis-Zugriffsebene und Daten transportebene in der Management-Station;
(4) Interface zwischen Datentransportebene und Datenbasis-Zu griffsebene in dem Telephonie-Schalter;
(5) Datenbasis-Zugriffsebene im Telephonie-Schalter;
(6) Interface zwischen Datenbasis-Zugriffsebene und Anwen dungsebene im Telephonie-Schalter.

In der Management-Station 10 besteht die Anwendungsebene aus einer Anwendung 114, die erforderlich ist, um Zugang zu im Telephonie- Schalter 20 gespeicherter Information zu erhalten. Die Anwendung 114 er zeugt Befehle, die zum Telephonie-Schalter 20 gesendet werden. Bevor zugt ist die Management-Station 10 mit dem Telephonie-Schalter 20 über ein Lokalbereichsnetzwerk 30 verbunden. Die Management-Station 10 ist bevorzugt eine Workstation auf der Basis von Unix oder Windows, jedoch können auch Computer-Workstations verwendet werden, die andere Betriebs systeme verwenden. Die Management-Station 10 ist bevorzugt über eine Ethernet-Karte 112 mit dem Lokalbereichsnetzwerk 30 verbunden. Obwohl die Anwendung 114 als eine Datenbasisanwendung beschrieben ist, kann ir gendeine Anwendung 114 verwendet werden, die in der Lage ist, eine Mana gement-Station 10 oder eine Computer-Workstation zu betreiben, die Zu gang zu Information eines Telephonie-Schalters 20 erfordert. Irgendeine Anwendung 114, die auf irgendeiner Einrichtung arbeitet, die mit dem Netzwerk verbunden ist, um Zugang zu in dem Telephonie-Schalter 20 ge speicherte Information zu liefern, kann verwendet werden. Die Anwendung 114 und die vorliegende Architektur kann vollständig in Hardware liegen oder ausgeführt werden.

Die Datenbasis 120 speichert Information von verschiedenen Ar ten, Modellen und Eigenschaften von Telephonie-Schaltern 20, die über ein Netzwerk 30 zugänglich sind. Durch die Anwendung 114 können ver schiedene Einstellungen in die Datenbasis 120 der Management-Station 10 heruntergeladen werden. In der Management-Station 10 können die Einstel lungen manipuliert, modifiziert oder geändert und zurück zum Telephonie- Schalter 20 zum Aktualisieren gesandt werden. Auf diese Weise kann der Netzverwalter von der Geheimsprache und Parametern, die erforderlich sind, um die Einstellung am Telephonie-Schalter 20 zu aktualisieren, isoliert werden. Zusätzlich können Bewegungen und Änderungen leicht durch Herabladen des Merkmalsatzes vom Telephonie-Schalter 20, der von diesem entnommen wird, und anschließendes Rückladen des gleichen Merk malsatzes in den Telephonie-Schalter 20, der zu diesem geführt wird, vorgenommen werden. Weiterhin kann die Übersetzung von Merkmalen, wo die Parameter für ein Merkmal von einem Telephonie-Schalter zum anderen va riieren können, automatisch durchgeführt werden, ohne daß vom Netzver walter gefordert wird, daß er die verschiedenen Parameter für ein Merk mal von einem Telephonie-Schalter zum anderen kennt. Eine Liste von ge eigneten Merkmalen kann auch in der Datenbasis 120 gespeichert und für den Benutzer übersetzt werden, so daß ein universales Benutzer-Interface präsentiert wird. Bevorzugt wird die Datenbasisverwendung 114 in der Programmiersprache "C" geschrieben und die Datenbasis 120 durch das Ora cle-Database-Management-System (DBMS) verwaltet. Jedoch kann auch ir gendein anderes Management-System verwendet werden. Die Datenbasisver wendung 114 kommuniziert mit dem DB-Zugriffsserver 116 über ein Interfa ce 115. Das Interface 115 wird nachstehend unter Bezugnahme auf Fig. 4 beschrieben.

Der DB-Zugriffsserver 116 in der Datenbasis-Zugriffsebene kom muniziert mit einem Kommunikationskanal 122 in der Datentransportebene über ein Interface 117, um Kommunikationen mit dem Telephonie-Schalter 20 zu erleichtern. Das Interface 117 liefert die Datenbasis-Zugriffsebe ne mit einem Mechanismus und Protokoll, um Befehle und Daten zum Tele phonie-Schalter 20 zu handhaben und zu transportieren. Das Interface 117 ist im einzelnen unter Bezugnahme auf Fig. 4 beschrieben. Der Kommuni kationskanal 122 kommuniziert über ein Interface 119 mit der Ethernet- Karte 110, um Information zum Telephonie-Schalter 20 zu übertragen. Be vorzugt sind der Kommunikationskanal 122 und das Interface 119 existie rende Prozesse, die Verbindungen mit individuellen Netzwerkeinrichtungen verwalten.

Der Telephonie-Schalter 20 ist zugreifbar, gesteuert und ar beitet entsprechend Einstellungen, die in der Datenbasis 124 gespei chert sind. Der Telephonie-Schalter 20 ist allgemein eine elektronische Einrichtung mit einer Speichereinrichtung, einem Betriebssystem und ei ner Befehlssprache. Die Information bezüglich der Konfiguration des Te lephonie-Schalters 20 ist in Datenbasis-Tabellen gespeichert, wobei jede Reihe einer Tabelle als ein Tupel entweder direkt oder indirekt über ein View zugänglich ist. Ein Tupel ist ein zusammengesetztes View eines Da tenbasis-Datensatzes oder besteht aus Teilen von verschiedenen Datensät zen, die die kleinste Granularität von Daten in einer Datenbasis dar stellen. Tupel bestehen aus einem oder mehreren Feldern, die über Feld namen zugänglich sind. Die Informationen (oder Tupel) in der Tabelle sind über eine Schalter-Datenbasis-Anwendung 126 zugänglich, und die zum Telephonie-Schalter 20 gesandten Befehle werden durch die Schalter-Da tenbasis-Anwendung 126 verarbeitet und ausgeführt.

In dem nachfolgenden Beispiel entspricht die Struktur der Da tenbasis 124 derjenigen des Mitel ® PBX Modell SX-2000 ® Telephonie- Schalters. Jedoch lassen sich auch Tabellen in anderen Formaten verwen den, wie in US 4 615 028 oder US 4 616 360 beschrieben ist. Die Schal ter-Datenbasis-Anwendung 126 ist ein Programm, das den Zugang zur Daten basis 124 regelt. Die Schalter-Datenbasis-Anwendung 126 und die Datenba sis 124 sind in der Anwendungsebene des Telephonie-Schalters 20 resi dent. Die Schalter-Datenbasis-Anwendung 126 in der Anwendungsebene kom muniziert mit dem Schalter-Datenbasis-Server 118 über ein Interface 123. Das Interface 123 ist im einzelnen unter Bezugnahme auf Fig. 5 be schrieben. Der Schalter-Datenbasis-Server 118 der Datenbasis-Zugriffs ebene kommuniziert mit dem Kommunikationskanal 128 des Telephonie-Schal ters 20 über das Interface 121. Das Interface 121 versorgt die Datenba sis-Zugriffsebene in dem Telephonie-Schalter 20 mit einem Mechanismus und Protokoll zum Transportieren von Befehlen und Daten zur Management- Station 10. Das Interface 121 ist im einzelnen unter Bezugnahme auf Fig. 5 beschrieben. Der Kommunikationskanal 128 kommuniziert mit der Et hernet-Karte 112, indem Information zum Lokalbereichsnetzwerk 30 über führt wird, die durch die Management-Station 10 zu empfangen ist. Der Kommunikationskanal 128 ist eine existierende Bibliothek von Funktionen, die die Übersetzung zwischen Datendarstellungen, die beim Datentransport verwendet werden, und denjenigen, die durch die Datenbasis-Zugriffsebene erforderlich sind, verwaltet. Der Kommunikationskanal 128 ist vorzugs weise mit einem existierenden Transportmechanismus wie dem Opsman MNMS, der durch Mitel ® geliefert wird, versehen. Jedoch können auch andere Transportmechanismen verwendet werden. Die Netzwerkeinrichtungen können in die Lage versetzt werden, mit dem Telephonie-Schalter 20 zu kommuni zieren, so daß der Telephonie-Schalter 20 in die Netzwerkanwendungen in tegriert werden kann. Benutzer können in die Lage versetzt werden, ihre eigenen Telephonie-Einstellungen von ihrem Tischrechner aus zu kontrol lieren. Zusätzlich können Merkmale auf dem Telephonie-Schalter 20 ange boten werden, um vorteilhaft den Telephonie-Schalter 20 als eine Netz werkeinrichtung zu nutzen, die Anwendungen 114 ermöglicht, um mit dem Telephonie-Schalter 20 in der Arbeitsplatzumgebung zu kommunizieren und diesen zu integrieren.

Nachrichtenfluß

Fig. 3 illustriert den Informationsfluß bei einer Transak tion, ein Tupel zu lesen und ein Tupel über eine Anwendung 114 zu schreiben. Die Anwendung 114 wird einem Benutzer auf einem Bildschirm präsentiert, wie er üblicherweise an einem Computer-Arbeitsplatz verwen det wird. Ein Benutzer kommuniziert mit einer Anwendung 114, die auf ei ner Management-Station 10 läuft, über ein Benutzer-Interface 131. Die Anwendung 114 kommuniziert mit dem DB-Zugriffsserver 116 über das Inter face 115. Der DB-Zugriffsserver 116 kommuniziert mit einem Transportme chanismus 130 über das Interface 117. Der Transportmechanismus 130 kom muniziert mit einem Schalter-Datenbasis-Server 118 über ein Interface 121. Der Schalter-Datenbasis-Server 118 kommuniziert mit der Schalter- Datenbasis-Zugriffsanwendung 126 über das Interface 123. Beginnend links oben in Fig. 3 öffnet oder startet ein Schritt 132a über das Benutzer- Interface 131, typischerweise ein Bildschirm, eine Tastatur oder eine andere Eingabe-/Ausgabeeinrichtung die Anwendung 114, die bewirkt, daß ein Benutzerprofil ausgeführt wird. Im Schritt 132b startet die Anwen dung 114 eine Session und kommuniziert die Nachricht durch das Interface 115 zum DB-Zugriffsserver 116. Im Schritt 132c stellt der DB-Zugriffs server 116 die Verbindung zum Transportmechanismus 130 her und sendet die Sessions-Start-Nachricht über das Interface 117 zum Transportmecha nismus 130. Im Schritt 132d transportiert der Transportmechanismus 130 die Nachricht zum Schalter-Datenbasis-Server 118 des Telephonie-Schal ters 20 über das Interface 121. Im Schritt 133a ordnet der Schalter-Da tenbasis-Server 118 nach Empfang der Nachricht aus Schritt 132d eine Sessions-ID oder -Kennzeichnung zu und schickt diese über das Interface 121 zurück zum Transportmechanismus 130. Im Schritt 133b schickt der Transportmechanismus 130 die Nachricht über das Interface 117 zum DB-Zu griffsserver 116. In Schritt 133c registriert der DB-Zugriffsserver 116 die Sessions-ID und schickt die Nachricht über das Interface 115 zur An wendung 114. Nach Empfang der Nachricht liefert die Anwendung 114 die Anfrage zum Lesen eines Tupels in Schritt 134a. Diese Anfrage wird zu rück durch das Interface 115 zum DB-Zugriffsserver 116 gesandt. In Schritt 134b packt der DB-Zugriffsserver 116 die Anfrage ein und sendet sie über das Interface 117 zum Transportmechanismus 130. Im Schritt 134c überführt der Transportmechanismus 130 die Nachricht zum Schalter-Daten basis-Server 118 des Telephonie-Schalters 20 über das Interface 121. In Schritt 134d verifiziert der Schalter-Datenbasis-Server 118 die Ses sions-ID und packt die Anfrage zurück und schickt die Nachricht durch das Interface 123 zur Schalter-Datenbasis-Anwendung 126. In Schritt 135 vollführt die Schalter-Datenbasis-Anwendung 126 nach Empfang der Anfrage das Lesen und schickt in Schritt 136a ein Tupel durch das Interface 123 zur Schalter-Datenbasis 118 zurück. In Schritt 136b packt der Schalter- Datenbasis-Server 118 die Anfrage zurück und schickt sie zum Transport mechanismus 130 durch das Interface 121. In Schritt 136c schickt der Transportmechanismus 130 die Antwort durch das Interface 117 zum DB-Zu griffsserver 116. In Schritt 136d konvertiert der DB-Zugriffsserver 116 die Textdaten in das geeignete Format und schickt die Daten zur Anwen dung 114 über das Interface 115. In Schritt 136e präsentiert die Anwen dung 114 die Information dem Benutzer über das Benutzer-Interface 131. In Schritt 137 bearbeitet der Benutzer die Information. Wenn die Bear beitung abgeschlossen ist, schickt der Benutzer in Schritt 138a den Ein satzbefehl durch das Benutzer-Interface 131 zur Anwendung 114. In Schritt 138b liefert die Anwendung 114 eine Transaktionsstartnachricht und schickt die Nachricht durch das Interface 115 zum DB-Zugriffsserver 116. In Schritt 138c schickt der DB-Zugriffsserver 116 die Transaktions startnachricht durch das Interface 117 zum Transportmechanismus 130. Im Schritt 138d schickt der Transportmechanismus 130 die Nachricht durch das Interface 121 zum Schalter-Datenbasis-Server 118. In Schritt 138e packt der Schalter-Datenbasis-Server 118 die Transaktionsstartnachricht zurück und schickt sie durch das Interface 123 zur Schalter-Datenbasis- Anwendung 126. In Schritt 139 startet die Schalter-Datenbasis-Anwendung 126 die Transaktion. Wenn die Transaktion zur Durchführung in Schritt 140a fertig ist, schickt die Schalter-Datenbasis-Anwendung 126 eine Be stätigung durch das Interface 123 zum Schalter-Datenbasis-Server 118 zu rück. In Schritt 140b packt der Schalter-Datenbasis-Server 118 die Be stätigung zurück und schickt sie durch das Interface 121 zum Transport mechanismus 130. Im Schritt 140c schickt der Transportmechanismus 130 die Bestätigung durch das Interface 117 zum DB-Zugriffsserver 116. In Schritt 140d schickt der DB-Zugriffsserver 116 die Bestätigungsnachricht durch das Interface 115 zur Anwendung 114. In Schritt 141a gibt die An wendung 114 nach Empfang der Bestätigung den Befehl, das Tupel durch das Interface 115 in den DB-Zugriffsserver 116 zu schreiben. In Schritt 141b packt der DB-Zugriffsserver 116 die Anfrage zurück und sendet sie durch das Interface 117 zum Transportmechanismus 130. In Schritt 141c schickt der Transportmechanismus 130 die Anfrage durch das Interface 121 zum Schalter-Datenbasis-Server 118. In Schritt 141d verifiziert der Schal ter-Datenbasis-Server 118 die Sessions-ID und packt die "Schreib"-Anfra ge zurück, um diese durch das Interface 123 zur Schalter-Datenbasis-An wendung 126 zu senden. In Schritt 142 führt die Schalter-Datenbasis-An wendung 126 den Schreibbefehl aus. Nach erfolgreichem Abschluß des Schreibens schickt die Schalter-Datenbasis-Anwendung 126 im Schritt 143a eine Bestätigung für das erfolgreiche Schreiben durch das Interface 123 zum Schalter-Datenbasis-Server 118. In Schritt 143b packt der Schalter- Datenbasis-Server 118 die Bestätigung zurück und schickt sie durch das Interface 121 zum Transportmechanismus 130. In Schritt 143c schickt der Transportmechanismus 130 die Anfrage durch das Interface 117 zum DB-Zu griffsserver 116. In Schritt 143d schickt der DB-Zugriffsserver 116 die Bestätigung durch das Interface 115 zur Anwendung 114. In Schritt 144a schickt die Anwendung 114 nach Empfang der Bestätigung den Befehl, die Transaktion zu beenden, durch das Interface 115 zurück zum DB-Zugriffs server 116. In Schritt 144b packt der DB-Zugriffsserver 116 die Anfrage zurück und sendet sie durch das Interface 117 zum Transportmechanismus 130. In Schritt 144c schickt der Transportmechanismus 130 die Anfrage durch das Interface 121 zum Schalter-Datenbasis-Server 118. In Schritt 144d packt der Schalter-Datenbasis-Server 118 die Anfrage zurück und schickt sie durch das Interface 123 zur Schalter-Datenbasis-Anwendung 126. In Schritt 145 übertragt die Schalter-Datenbasis-Anwendung 126 nach Empfang der Anfrage die Änderungen auf den Plattenspeicher und beendet die Session. In Stufe 146a schickt die Schalter-Datenbasis-Anwendung 126 nach erfolgreichem Abschluß der Session eine Bestätigung über das Inter face 123 zum Schalter-Datenbasis-Server 118. In Schritt 146b packt der Schalter-Datenbasis-Server 118 die Bestätigung der Beendigung der Ses sion zurück und schickt sie durch das Interface 121 zum Transportmecha nismus 130. In Schritt 146c schickt der Transportmechanismus 130 die Be stätigung durch das Interface 117 zum DB-Zugriffsserver 116. In Schritt 146d schickt der DB-Zugriffsserver 116 die Bestätigung durch das Inter face 115 zur Anwendung 114. In Schritt 146e informiert die Anwendung 114 den Benutzer vom Erfolg der Transaktion über das Interface 131. In Schritt 147a schließt der Benutzer nach Information über den Erfolg die Anwendung 114, wodurch bewirkt wird, daß eine Nachricht über das Benut zer-Interface 131 zur Anwendung 114 zurückgeschickt wird. In Schritt 147b gibt die Anwendung 114 die Nachricht der Beendigung der Session über das Interface 115 zum DB-Zugriffsserver 116 aus. In Schritt 147c schickt der DB-Zugriffsserver 116 diese Nachricht durch das Interface 117 zum Transportmechanismus 130, der in Schritt 147d die Nachricht durch das Interface 121 zum Schalter-Datenbasis-Server 118 schickt. In Schritt 148a gibt der Schalter-Datenbasis-Server 118 nach Empfang dieser Nachricht die Sessions-ID frei und schickt die Konfirmation über das In terface 121 zum Transportmechanismus 130. Der Transportmechanismus 130 schickt in Schritt 148b die Bestätigung über das Interface 117 zum DB- Zugriffsserver 116. In Schritt 148c schickt der DB-Zugriffsserver 116 die Nachricht zum Schließen der Verbindung über das Interface 115 zur Anwendung 114. In Schritt 148d schließt die Anwendung 114 nach Empfang der Bestätigungsnachricht bezüglich des Schließens der Verbindung ab.

1) Interface zwischen der Anwendung 114 und der Datenbasis-Zu griffsebene in der Management-Station 10

Die Anwendung 114 etabliert eine Datenbasis-Zugriffs-Session mit dem Telephonie-Schalter 20. Innerhalb der Session kann die Anwendung 114 Datenbasis-Tupel innerhalb der Schalter-Datenbasis 124 suchen, lesen und schreiben.

Auf multiple Telephonie-Schalter kann gleichzeitig durch die Anwendung 114 über unabhängige Datenbasis-Zugriffs-Sessionen zugegriffen werden.

Durch einen Satz von Operationen erlangt die Anwendung 114 über die Schalter-Datenbasis-Anwendung 126 Zugang zur Schalter-Datenba sis 124. Eine Fehlerbehebung und eine Rückwärtskompatibilität werden zu sätzlich beschrieben. Im folgenden werden Schalter- und Netzwerkelement austauschbar verwendet.

Die Struktur des Interface zwischen der Anwendungsebene und der Datenbasis-Zugriffsebene der Management-Station 10 wird durch Funk tionen (auch bekannt als "APS"-Funktionen) vorgesehen.

Alle obigen Funktionen auf der Seite der Management-Station 10 außer den Tupel-Management-Funktionen besitzen eine gespiegelte Funktion auf der Seite des Telephonie-Schalters 20. Wenn die Anwendung 114 auf eine der obigen Funktionen einwirkt, wird die Funktion eingepackt und zum Telephonie-Schalter 20 transportiert, wo sie empfangen, entpackt und in einem Format bereitgestellt wird, das durch die Schalter-Datenbasis- Anwendung zur Ausführung verstanden wird. Auf diese Weise wird die vom Benutzer ausgeführte Anwendung 114 an der Management-Station 10 von den Besonderheiten des Schalters isoliert, da die Anwendung 114 irgendwelche Übersetzungen oder Datenstrukturformate verwalten kann, die auf irgend eine besondere Ausführungsform, Modell oder Version des Schalters, an wendbar sind. Jede dieser Funktionen werden von der Anwendungsebene auf gerufen und durch die Datenbasis-Zugriffsebene zur weiteren Verarbeitung geschickt. Resultate werden von der Datenbasis-Zugriffsebene zurück durch die aufrufende Funktion in der Anwendungsebene geschickt.

Detaillierte Beschreibung von Funktionen (a) Fehleridentifikation

In dem Fall, in dem keine Erfolgs meldung zurückkehrt, wird ein Fehlercode zurückgeschickt und ggf. als eine Variable zur Anwendung 114 geschickt, um den angetroffenen Fehler zu kennzeichnen. Die Anwendung 114 kann ggf. Bezug auf eine Nachschlage tabelle für den Text des Fehlercodes nehmen und schickt den Fehlertext zum Benutzer.

(b) Anwendungsregistrierung

Dies erfordert, daß die Anwen dung 114 vor der Durchführung von Operationen mit dem DB-Zugriffsserver 116 registerhaltig gemacht wird. Diese Gruppe von Funktionen operiert innerhalb der Management-Station 10. Die Registrierung ist ein wichtiges Element in der Kommunikation zwischen der Anwendung 114 und dem DB-Zu griffsserver 116. Die Anwendung 114 ist ausgelegt, um bestimmte Versio nen und Revisionspegel des Telephonie-Schalters 20 zu verstehen. Wenn die Registrierung erscheint, liefert die Anwendung 114 dem DB-Zugriffs server 116 die Versions- und Revisionspegel-Information, für die die An wendung 114 ausgelegt ist. In dem Fall, in dem die Anwendung 114 mit ei nem Telephonie-Schalter 20 einer niedrigeren Version als derjenigen ver sucht zu kommunizieren, die fähig ist, die Anwendung 114 zu verstehen, konvertiert der DB-Zugriffsserver 116 die Daten von der durch die Anwen dung 114 verstandenen Version in die durch den Telephonie-Schalter 20 verstandene Version. Dieser Mechanismus kann auch verwendet werden, um in entgegengesetzter Richtung zu arbeiten. Wenn eine Anwendung 114 mit einem Telephonie-Schalter 20 einer höheren Version als die Anwendung 114 kommuniziert, kann der DB-Zugriffsserver 116 die notwendige Übersetzung der Daten zur Kommunikation mit dem Telephonie-Schalter 20 durchführen. Wenn eine Datenübersetzung notwendig ist, wird der DB-Zugriffsserver 116 Daten, soweit notwendig, addieren, übersetzen oder weglassen, um die Kommunikation mit dem Telephonie-Schalter 20 zu erleichtern. Die Anwen dung 114 ist erforderlich, um die Verwendung von Systemressourcen zu de registrieren oder abzugeben. Die Registrieroperationen sind:

(i) Registrieren
(ii) Deregistrieren

Eine Anwendung 114 braucht nur einmal zu registrieren. Nach folgende Registrierungen resultieren in Erfolg und verwenden die vorher etablierten Kommunikationskanäle des DB-Zugriffsservers 116.

(i) Registrieren

Um den DB-Zugriffsserver 116 zu verwenden, muß eine Anwendung 114 durch Aufrufen der Registerfunktion zunächst sich selbst registrieren.

Eine Anwendung 114 wird durch Aufrufen der Registerfunktion und Liefern des Namens der Anwendung als auch der Edition der Schalter- Datenbasis, die sie versteht, als Variablen registriert. Die Register funktion etabliert eine Verbindung zu dem DB-Zugriffsserver 116, der al le nachfolgenden DB-Zugriffsanfragen behandelt. Die Funktion wird einen Wert zurückliefern, der den Erfolg oder Mißerfolg der Operation anzeigt. In dem Fall, daß der Sessionsstart fehlschlägt, ist der Datenbasis-Zu griff nicht verfügbar. Wenn eine Datenbasis-Zugriffssession bereits exi stiert, wird eine Erfolgsmeldung zurückgegeben.

(ii) Deregistrieren

Wenn eine Anwendung 114 den Zugriff zu beenden wünscht, wird die Deregisterfunktion aufgerufen. Die Kommunika tion mit dem DB-Zugriffsserver 116 wird beendet. Die Funktion gibt ei nen Wert zurück, der den Erfolg oder Fehlschlag der Operation anzeigt. Wenn die Kommunikation mit dem DB-Zugriffsserver 116 vorher beendet war oder nicht existiert oder eine Session aktiv ist oder eine Transaktion aktiv ist, wird eine Fehlermeldung zurückgegeben. Irgendwelche Sessionen und Transaktionen müssen explizit durch die Anwendung 114 beendet wer den, bevor das Deregistrieren erfolgen kann.

(c) Sessionmanagement

Operationen zum Zugriff zu jeder Schalter-Datenbasis 124 werden innerhalb der Grenzen einer "Session" durchgeführt. Eine Anwendung 114 startet eine Session, führt eine Reihe von Datenbasis-Zugangsoperationen durch und beendet die Session. Das Ma nagement der Session wird durch die unterliegende Daten-Zugriffsebene und die Daten-Transportebene vorgenommen, die Vorgänge wie ein öffnen und Schließen des Kommunikationskanals 122 zum Telephonie-Schalter 20, Einpacken der Anwendungsanforderungen und Senden von diesen zum Telepho nie-Schalter 20 und Übergabe der Anforderungsergebnisse an die Anwen dung 114 durchgeführt. Die Sessionmanagement-Operationen sind einfach:

(i) Start der Session
(ii) Beendigung der Session

Eine Session wird durch eine einzige Sessions-ID katalogisiert und identifiziert. Der Telephonie-Schalter 20 ist für die Zuordnung und Präsentation der Sessions-ID gegenüber dem DB-Zugriffsserver 116 verant wortlich. Dies ist im einzelnen weiter unten beschrieben. Eine Anwendung 114 kann nur eine Session besitzen, die pro Telephonie-Schalter geöffnet ist. Ein Versuch, eine andere Session für den gleichen Telephonie-Schal ter zu starten, wird zurückgewiesen. Sessionen können nur auf der akti ven Ebene initiiert werden, wo sie anwendbar sind, und werden fallenge lassen, wenn ein Aktivitätsschalter auftritt.

(i) Start der Session

Um Zugang zur Schalter-Datenbasis ei nes Telephonie-Schalters 20 zu erhalten, muß eine Anwendung 114 eine Da tenbasis-Zugriffssession starten. Eine Session wird durch Aufrufen der Sessionsstartfunktion und Liefern des Kennzeichens des spezifischen Te lephonie-Schalters 20 als eine Variable, zu dem die Anwendung 114 Zu griff wünscht, und der Bestimmungsebene gestartet. Das Kennzeichen oder ID des Schalters wird durch die Anwendung 114 eingegeben. Die Sessions startfunktion stellt eine Verbindung zu dem spezifischen Telephonie- Schalter 20 über das Netzwerk oder einen Verbindungsmechanismus her und weist dieser Verbindung eine Sessions-ID oder weitere Kennzeichnung zu. Die Funktion wird einen Wert zurückgeben, der den Erfolg oder den Fehl schlag der Operation anzeigt. Die Sessions-ID wird zur aufrufenden An wendung 114 als ein Sessions-ID-Parameter zurückgegeben. Die Anwendung 114 muß diese Sessions-ID für nachfolgende Zugriffsanfragen für die Dau er der Session verwenden. In dem Fall, daß der Sessionsstart fehl schlägt, ist ein Zugang zu einer Schalter-Datenbasis 124 bei dem Tele phonie-Schalter 20 nicht verfügbar. Wenn eine Datenbasis-Zugriffssession bereits existiert, oder eine Kommunikation zu dem Telephonie-Schalter 20 nicht hergestellt werden kann, wird eine Fehlermeldung zurückgegeben. Bei Schaltern mit multiplen Ebenen (fehlertolerante Redundanz) muß die gewünschte Ebene für den Zugriff identifiziert werden.

(ii) Beendigung der Session

Wenn eine Anwendung 114 wünscht, die laufende Session zu beenden, wird die Sessionsbeendigungsfunktion aufgerufen. Die derzeitige Sessions-ID wird als Parameter an die Funk tion überführt. Der Kommunikationskanal 122 zum Telephonie-Schalter 20 wird geschlossen. Die Funktion gibt einen Wert zurück, der den Erfolg oder den Fehlschlag der Operation anzeigt. Wenn die Session vorher been det war oder nicht existiert oder eine Transaktion aktiv ist, wird eine Fehlermeldung zurückgegeben. Die Transaktion muß explizit durch die An wendung 114 beendet sein, bevor eine Session beendet werden kann.

(d) Transaktionsmanagement

Wie oben diskutiert, wird das Ausführungsbeispiel in bezug auf einen Mitel ® SX-2000 ® Telephonie- Schalter beschrieben. Bei einem derartigen Schalter wird Zugang zur Da tenbasis durch eine View-Ebene geliefert, wobei die Datenbasis-Tabellen 124 als ein View-Satz als Teil der Schalter-Datenbasis-Anwendung 126 ma nipuliert werden. Eventuelle notwendige Änderungen zur Adaption an ei nen Telephonie-Schalter eines anderen Designs oder anderer Herstellung, bei dem derartige View-Sätze nicht verwendet werden, können ohne weite res durchgeführt werden. Irgendwelche Datenbasis-Operationen, die die Schalter-Datenbasis 124 modifizieren, müssen innerhalb der Grenzen einer Transaktion durchgeführt werden. Drei Transaktionsfunktionen sind vorge sehen:

(i) Starten der Transaktion
(ii) Übermitteln der Transaktion
(iii) Löschen der Transaktion

Eine Anwendung 114 kann pro Telephonie-Schalter 20 nur eine aktive Transaktion aufweisen. Eine nachfolgende Anforderung zum Starten einer Transaktion für den gleichen Telephonie-Schalter 20 wird zurückge wiesen.

(i) Starten der Transaktion

Um für eine Anwendung 114 eine Datenbasis-Modifikationsanforderung zu machen, muß eine Transaktion in itiiert werden. Die Anwendung 114 startet eine Transaktion durch Aufruf der Transaktions-Startfunktion und Einspeisen der Sessions-ID, die zuge ordnet wurde, als die Sessions-Startfunktion aufgerufen wurde. Bei ei ner Kommunikation mit einem SX-2000 ®-Schalter muß die Anwendung 114 auch den View-Satz der Schalter-Datenbasis-Anwendung 126, wo anwendbar, spezifizieren, der während der Transaktion zu öffnen ist. Der geeignete View-Satz für jede Schalterversion ist entweder vorgeladen oder enthält die Datenbasis 120 der Management-Station 10 oder wird über das Anwen der-Interface eingegeben. Der View-Satz wird entsprechend der durch die Anwendung 114 ausgewählten Operation verwendet. Die Sessions-ID wird va lidiert und eine Anforderung zum Telephonie-Schalter 20 geschickt, um den spezifizierten View-Satz zu öffnen. Die Funktion wird einen Wert zu rückgeben, der den Erfolg oder den Fehlschlag der Operation anzeigt. Wenn das Starten der Transaktion fehlschlägt, wird der View-Satz der Schalter-Datenbasis 124 nicht für den Schreibzugang geöffnet. Wenn eine oder mehrere View-Sätze einer Schalter-Datenbasis 124 bereits durch eine andere Anwendung 114 geöffnet wurden, wird ein Fehlersignal zurückgege ben. Nur die spezifizierten Views sind zur Modifikation verfügbar. Der offene View-Satz kann nicht während einer Transaktion geändert werden. Ein Versuch, andere Views innerhalb der laufenden Transaktion zu modifi zieren, wird zurückgewiesen. Jedoch sind für andere Views in der laufen den Transaktion HOL- und AUFFIND-Operationen erlaubt.

(ii) Übermitteln der Transaktion

Wenn eine Anwendung 114 wünscht, die laufende Transaktion zu übermitteln, ruft sie die Transak tionsübermittlungsfunktion auf und spezifiziert die laufende Sessions- ID. Die Übermittlungsfunktion wird eine Übermittlungsanforderung an den Telephonie-Schalter 20 ausgeben und die Transaktion unabhängig vom Er folg schließen. Die Funktion meldet den Erfolg oder den Fehlschlag der Operation. Wenn eine Transaktion nicht im Gange ist, wird ein Fehlersi gnal zurückgegeben.

(iii) Löschen der Transaktion

Wenn eine Anwendung wünscht, Änderungen, die sie bezüglich der Schalterdatenbasis 124 vorgenommen hat, zu Löschen, ruft sie die Transaktionslöschfunktion mit der laufen den Sessions-ID auf. Die Löschfunktion sendet eine Transaktionslöschan forderung an den Telephonie-Schalter 20 und beendet die Transaktion. Die Funktion teilt den Erfolg oder Fehlschlag der Operation mit. Wenn eine Transaktion nicht im Gange ist, wird eine Fehlermeldung zurückgegeben.

(e) Lese-/Schreib-Funktionen

Ein Tupel ist ein zusammenge setzter View einer Datenbasis-Aufzeichnung oder von Teilen verschiedener Aufzeichnungen, die die kleinste Granularität von Daten in einer Daten basis darstellen. Tupel bestehen aus einem oder mehreren Feldern, auf die durch Feldnamen zugegriffen werden kann. Alle gleichen Tupel sind innerhalb einer Datenbasis-View enthalten. Vier grundlegende Tupel-Mani pulationsfunktionen sind vorgesehen:

(i) Hole Tupel
(ii) Addiere Tupel
(iii) Lösche Tupel
(iv) Modifiziere Tupel.

Mit der Ausnahme der HOL- und AUFFIND-Operationen müssen alle Operationen im Rahmen einer Transaktion durchgeführt werden, alle Opera tionen müssen im Kontext einer Session aufgerufen werden.

(i) Hole Tupel

Eine Anwendung 114 kann den Inhalt eines einzelnen Tupels von einem Telephonie-Schalter 20 für einen besonderen View und einen Tupel-Schlüssel durch Aufruf der Tupel-Hole-Funktion er halten. Die Anwendung 114 muß die laufende Sessions-ID, die View-ID oder die Tabellennamen für das angeforderte Tupel und eine Tupelstruktur mit darin ausgefülltem Schlüsselteil liefern. Die View-ID, die Tupel-Struk tur und die Tupel-Maske sind abhängig von der Herstellung, dem Modell und der Version des Telephonie-Schalters, auf den zugegriffen wird, wo bei die Struktur in der Datenbasis 120 zur Verwendung durch die Anwen dung 114 gespeichert ist. Optional kann Information zu den Tupeln durch Aufruf der nachstehend beschriebenen Hol-Tupel-Definitionsfunktion er halten werden. Die Tupel-Hol-Funktion liefert einen Wert zurück, der den Erfolg oder Fehlschlag der Operation anzeigt. Die Tupel-Inhalte werden in die Tupel-Parameter zurückgeführt. Wenn das Tupel nicht existiert oder nicht gelesen werden kann, wird eine Fehlermeldung zurückgegeben. Diese Funktion muß im Zusammenhang mit einer Session aufgerufen werden, bedarf jedoch keiner Transaktion.

(ii) Addiere Tupel

Eine Anwendung 114 kann ein Tupel zu ei nem Telephonie-Schalter 20 durch Aufrufen der Tupel-Addier-Funktion ad dieren. Die Anwendung 114 muß die laufende Sessions-ID, die View-ID und die Tupel-Inhalte liefern. Die View-ID, die Tupel-Struktur und Tupel- Maske sind abhängig von der Machart, der Modell und der Version des Te lephonie-Schalters, auf den zugegriffen wird, wobei die Struktur in der Datenbasis 120 zur Verwendung durch die Anwendung 114 gespeichert ist. Gegebenenfalls kann Information von Tupeln durch Aufruf der Hol-Tupel- Definitionsfunktion erhalten werden. Der Erfolg oder Fehlschlag der Ope ration wird rückgemeldet. Wenn eine Fehlermeldung zurückkommt, wird das Tupel nicht addiert. Wenn eine Transaktion, die den zu modifizierenden View enthält, nicht offen ist, wird eine Fehlermeldung zurückgegeben.

(iii) Lösche Tupel

Eine Anwendung 114 kann einen Tupel von einer Schalter-Datenbasis 124 durch Aufrufen der Tupel-Löschfunktion lö schen. Die Anwendung 114 muß die laufende Sessions-ID, die View-ID und das Tupel liefern. Die View-ID, die Tupel-Struktur und Tupel-Maske sind abhängig von der Machart, dem Modell und der Version des Telephonie- Schalters 20, auf den zugegriffen wird, wobei die Struktur in der Daten basis 120 zur Verwendung durch die Anwendung 114 gespeichert ist. Gege benenfalls kann Information bezüglich der Tupel durch Aufruf der Hol-Tu pel-Definitionsfunktion erhalten werden. Der Erfolg oder Fehlschlag der Operation wird zurückgeliefert. Wenn eine Fehlermeldung zurückgegeben wird, ist das Tupel nicht gelöscht. Wenn eine Transaktion, die den zu modifizierenden View enthält, nicht offen ist, wird eine Fehlermeldung zurückgegeben.

(iv) Modifiziere Tupel

Die Anwendung 114 muß die laufende Sessions-ID, die View-ID und die Inhalte des alten und den neuen Tupels liefern. Die View-ID, die Tupel-Struktur und Tupel-Maske sind abhängig von der Machart, dem Modell und der Version des Telephonie-Schalters 20, auf den zugegriffen wird, wobei die Struktur in der Datenbasis 120 zur Verwendung durch die Anwendung 114 gespeichert ist. Gegebenenfalls kann Information bezüglich der Tupel durch Aufruf der Hol-Tupel-Definitions funktion erhalten werden. Erfolg oder Fehlschlag der Operation wird rückgemeldet. Wenn eine Fehlermeldung erfolgt, wird das Tupel nicht mo difiziert. Wenn eine Transaktion, die den zu modifizierenden View ent hält, nicht offen ist, wird eine Fehlermeldung zurückgegeben.

(f) Hol erste/nächste Funktionen

Zwei Hol-Funktionen sind vorgesehen:

(i) Hol erstes Tupel
(ii) Hol nächstes Tupel

(i) Hol erstes Tupel

Die Anwendung 114 kann das erste Tupel für einen speziellen View auf einer Schalter-Datenbasis 124 durch Aufru fen der Hol-erstes-Tupel-Funktion finden. Die Anwendung 114 muß die lau fende Sessions-ID, die View-ID und eine Tupel-Datenstruktur spezifizie ren. Die View-ID, Tupel-Struktur und Tupel-Maske sind abhängig von der Machart, dem Modell und der Version des Telephonie-Schalters 20, auf den zugegriffen wird, wobei die Struktur in der Datenbasis 120 zur Verwen dung durch die Applikation 114 gespeichert ist. Gegebenenfalls können Informationen bezüglich der Tupel durch Aufrufen der Hol-Tupel-Defini tionsfunktion erhalten werden. Der Erfolg der Operation wird rückgemel det und das Tupel in den Tupel-Parameter geschafft. Diese Funktion muß im Kontext einer Session aufgerufen werden, bedarf jedoch keiner Trans aktion, die akzeptiert wird.

(ii) Hol nächstes Tupel

Diese Funktion ist ähnlich zu der Funktion Hol-erstes-Tupel, außer daß die Anwendung 114 ein Start-Tupel liefern muß, von dem ausgegangen wird. Die Funktion wird das nächste Tu pel, das dem Ausgangstupel für den spezifizierten View folgt, rückmel den. Der Erfolg der Operation wird rückgemeldet, und der Tupel-Inhalt des passenden Tupels wird in den Tupel-Parameter geschafft. Diese Funk tion muß innerhalb des Kontextes einer Session aufgerufen werden, erfor dert jedoch nicht eine Transaktion, die akzeptiert wird.

(g) Tupel-Management-Funktionen

Eine Anzahl von Tupel-Mana gement-Funktionen ist vorgesehen. Die Anwendung 114 kann die Definition eines Tupels für einen bestimmten View, basierend auf der Version der in dem Telephonie-Schalter 20 geladenen Software, durch Aufrufen der Hol- Tupel-Definitionsfunktion erhalten. Die Anwendung 114 muß die View-ID und die Schalter-Ladeversion spezifizieren, die entweder in der Datenba sis 120 gespeichert oder durch die Anwendung 114 erhalten ist. Der Er folg der Operation wird rückgemeldet, und die Tupel-Definition in den Tupel-Größen-Parameter geschafft. Die Schalter-Ladeversion muß zur Rück wärtskompatibilität vorgesehen werden. Diese stellt nicht notwendiger weise die Ladeversion irgendeines Telephonie-Schalters 20 dar, mit dem die Anwendung 114 zu kommunizieren wünscht. Die Tupel-Definition umfaßt Informationen, enthaltend folgende Größen (ist jedoch hierauf nicht be grenzt):
Tupel-Größe
Schlüsselidentifikation
Versatz von individuellen Feldern innerhalb des Tupels
Größe von individuellen Felder
Feld-Datentypen
Feld-Datenbereiche
Diese Funktion kann außerhalb des Kontextes einer Session auf gerufen werden, da die Kommunikation mit einem Telephonie-Schalter 20 nicht notwendig ist.

(a) Malloctuple
(b) Inituple
(c) Freetuple
(d) Getupletype
(e) Getuplename
(f) Getuplesize
(g) Getuplenumfields
(h) Getfieldnameptr
(i) Getfieldkind
(j) Getfieldtype
(k) Getfieldsize
(l) Getfieldxlationtbl
(m) Setfield
(n) Getfield
(o) Copytuple

Alle die obigen Funktionen sind spezifisch für die Management- Station 10 und ausgelegt, um der Anwendung 114 zu ermöglichen, Informa tion über die Struktur der Datenbasis-Tabelle des Telephonie-Schalters 20 zu erhalten. Auch die folgende Diskussion bezieht sich speziell auf den Mitel ® SX-2000 ® Telephonie-Schalter. Alle obigen Funktionen ope rieren innerhalb der Anwendungszugriffsebene und der Datenbasis-Zu griffsebene der Management-Station 10. Die Funktionen ermöglichen der Anwendung, Information über die spezielle Datenbasis und Tabellenstruk turen, die für den Telephonie-Schalter 20 verwendet wurden, zu erhalten. Diese Funktionen brauchen nur aufgerufen zu werden, wenn die Anwendung eine derartige Information erfordert. Es ist für die zu schreibende An wendung 114 möglich, die anderen Aspekte der vorliegenden Erfindung ohne Rückgriff auf diese Funktionen zu verwenden, wenn die Anwendung bereits die Datenbasis-Tabellenstruktur und die Definition des ausgewählten Te lephonie-Schalters 20 kennt. Durch Hinzufügen dieser Funktionalität kann jedoch die Kompatibilität zwischen verschiedenen Versionen von Anwendun gen 114, DB-Zugriffsservern 116 und Telephonie-Schaltern 20 verbessert werden, da die Anwendung nach der Datenbasis-Struktur auf dem Telepho nie-Schalter 20 forschen kann, mit dem sie zu kommunizieren wünscht. Die Intelligenz bezüglich der Struktur der verschiedenen Datenbasis-Tabel len, Views usw. für verschiedene Macharten, Modelle, Versionen und Über arbeitungen des Telephonie-Schalters 20 sind sämtlich in dem DB-Zu griffsserver 116 enthalten, der das Abkoppeln der Datenbasis-Anwendung 116 von spezifischen Versionen des Telephonie-Schalters 20 ermöglicht.

Jede der obigen Funktionen wird nachstehen im einzelnen be schrieben:

(a Malloctuple

Diese Funktion nimmt die Datenbasis-View- Ideen der Parameter und ordnet einen Tupel-Puffer (Speicherbereich) zu, der wirksam ist, um irgendein Tupel zu halten, das durch die Anwendung 114 und den DB-Zugriffsserver 116 verwaltet und manipuliert wird.

b) Inituple

Diese Funktion nimmt die Datenbasis-View-ID und eine Hinweismarke auf das Tupel als Parameter und initialisiert den Tu pel-Puffer, um seinen laufenden Inhalt zu entfernen.

c) Freetuple

Diese Funktion nimmt den durch die Malloctuple- Funktion zugeordneten Puffer und stellt diesen zurück, wenn er nicht länger zum Wiederherstellen von Systemressourcen verwendet wird.

d) Gettupletype

Diese Funktion nimmt die View-ID und meldet die Art des Tupels zurück, d. h. die Operationen, die auf diesem be stimmten Datenbasis-View abgearbeitet werden. Die verschiedenen View-Ty pen können ein Addieren, Löschen, Modifizieren oder Lesen der Daten ab arbeiten.

e) Gettuplename

Diese Funktion nimmt die gewünschte View-ID und meldet den Namen des Tupels zurück.

f) Gettuplesize

Diese Funktion nimmt die View-ID und meldet die Größe des Tupels zurück.

g) Gettuplnumfields

Diese Funktion erhält die Additions freigabe und View-ID und meldet die Anzahl von Feldern in dem Tupel zu rück.

h) Getfieldnameptr

Diese Funktion nimmt die View-ID und Feld-ID und meldet den Namen eines gegebenen Feldes in dem Tupel zurück.

i) Getfieldkind

Diese Funktion nimmt die Feld-ID und View-ID und meldet die Art eines gegebenen Feldes in dem Tupel zurück (bei spielsweise ganzzahlig, Aufzählung oder String).

j) Getfieldtype

Diese Funktion nimmt View-ID und Feld-ID und meldet die Art eines gegebenen Feldes in dem Tupel zurück (beispielswei se ganzzahlig, Aufzählung oder String).

k) Getfieldsize

Diese Funktion nimmt View-ID und Feld-ID und meldet die Größe eines gegebenen Feldes in dem Tupel zurück.

l) Getfieldxlationtbl

Diese Funktion nimmt View-ID und Feld- ID und meldet eine Tabelle, die zum Übersetzen einer Aufzählung in ihren korrespondierenden String in einem gegebenen Feld in dem Tupel verwendet wird, zurück.

m) Setfield

Diese Funktion nimmt die Additionsfreigabe, View-ID, Feld-ID, Feldwert und Tupel und setzt den Wert eines gegebenen Feldes in dem Tupel.

n) Getfield

Diese Funktion nimmt die Additionsfreigabe, die View-ID, Feld-ID, Feldwertmarke und ein Tupel und erhält den Wert eines gegebenen Feldes in dem Tupel.

o) Copytuple

Diese Funktion nimmt die View-ID, das Bestim mungs-Tupel und das Quellen-Tupel und kopiert den Inhalt des Quellen-Tu pels auf den Bestimmungs-Tupel-Puffer.

2) Datenbasis-Zugriffsebene in der Management-Station

Wie oben erwähnt, kommuniziert die Anwendung 114 der Manage ment-Station 10 mit dem DB-Zugriffsserver 116 über die APS-Redirektions ebene 150. Gemäß einer alternativen Ausführungsform können andere DBA- Klienten oder andere Leitweg-Anwendungen die APS-Redirektionsebene 150 verwenden, um mit dem DB-Zugriffsserver 116 zu kommunizieren. Der DB-Zu griffsserver 116 kommuniziert über einen DB-Kommunikationsserver 152, der seinerseits mit einer Kommunikations-Redirektionsebene 154 kommuni ziert. Die Kommunikations-Redirektionsebene 154 kommuniziert dann mit der Daten-Transportebene über den Kommunikationskanal 122. Der Kommuni kationskanal 122 ruft den Präsentationsebenen-Service 156, um die Daten in einem Format zu plazieren, so daß sie mit der Ethernet-Karte 110 kom munizieren und auf dem Lokalbereichsnetzwerk 30 plaziert werden können. Diese Architektur ermöglicht den Support von multiplen unabhängigen An wendungen.

Die individuellen Software-Komponenten, die erforderlich sind, um DB-Zugriffsanforderungen in der Management-Station 10 zu tragen, sind folgende:

(a) APS-Redirektionsebene
(b) APS-Parameter-Datenformat
(c) Gemeinsames Datenformat
(d) DB-Zugriffsserver
(e) DB-Kommunikationsserver

Nachstehend wird eine kurze Übersicht über diese Software-Kom ponenten gegeben:

(a) APS-Redirektionsebene

Die APS-Redirektionsebene 154 re sidiert in der Management-Station 10 als eine Bibliothek und Funktionen, mit denen Anwendungen wie Anwendung 114 kompiliert und verknüpft werden. Die APS-Redirektionsebene 154 übersetzt Funktionen der Anwendung 114, die oben beschrieben sind, in eine Form, so daß sie durch den DB-Zu griffsserver 116 verarbeitbar sind. Diese Funktionen erlauben der Anwen dung 114, eine Anschlußverbindung zum DB-Zugriffsserver 116 zu etablie ren und Datenbasis-Zugriffsanforderungen zum Einwirken auf dem Telepho nie-Schalter 20 abzugeben. Die APS-Redirektionsebene 154 isoliert Anwen dungen wie die Anwendung 114 von der aktuellen Implementierung des DB- Zugriffsservers 116. Diese Isolierung ermöglicht es dem DB-Zugriffsser ver 116, ohne Störung von individuellen Anwendungen (beispielsweise alte Anwendungen erfordern kein Rekompilieren und Rückverbinden, um die Ar beit mit einem neuen DB-Zugriffsserver durchzuführen) geändert zu wer den. APS-Funktionsaufrufe durch die Anwendung 114, wie in dem Abschnitt "Interface zwischen der Anwendung und der Datenbasis-Zugriffsebene in der Management-Station" beschrieben, werden in entsprechende Nachrichten durch Verwendung einer einfachen Anschlußverbindung und eines gemeinsa men Datenformats konvertiert. Nachrichten werden synchron gesendet und empfangen (Blockierung für eine Antwort).

Wie oben beschrieben, vollführt die Anwendung 114 eine APS- Funktionsanforderung an die APS-Redirektionsebene 150. Die APS-Redirek tionsebene 150 empfängt die APS-Anforderung von der Anwendung 114, kon vertiert die APS-Anforderung in eine Anforderung im gemeinsamen Daten format, sendet die Anforderung im gemeinsamen Datenformat an den DB-Zu griffsserver 116. Dieser verarbeitet die Anforderung und sendet eine Antwort im gemeinsamen Datenformat an die APS-Redirektionsebene 150 nach der Verarbeitung zurück. Die Antwort im gemeinsamen Datenformat wird dann durch die APS-Redirektionsebene 150 in ein Format formatiert, das durch die rufende APS-Funktion empfangbar ist, und wird zur Anwendung 114 zurückgesandt.

Jede Anwendung 114 kommuniziert mit einem unabhängigen APS-Re direktionsebenenprozeß, um den Zugriff zum DB-Zugriffsserver 116 zu be werkstelligen.

Die APS-Redirektionsebene 150 sendet eine Anfragennachricht im gemeinsamen Datenformat an den DB-Zugriffsserver 116 und blockiert eine Antwort. Die folgenden APS-Aufrufe werden durch diese Ebenen bewirkt.

- View-Satz-Management
Ordne View-Satz
- Fehleridentifikation
Hole Fehlertext
- Anwendungsregistrierung
Registrieren
Deregistrieren
- Sessions-Management
Starten der Session
Beenden der Session
- Transaktions-Management
Starten der Transaktion
Übermitteln der Transaktion
Löschen der Transaktion
- Lese-/Schreib-Funktionen
Hole Tupel
Addiere Tupel
Lösche Tupel
Modifiziere Tupel
- Hole erste/nächste Funktionen
Finde Tupel
Hole nächstes Tupel

(b) APS-Parameter-Datenformat

Das APS-Parameter-Datenformat ist das Format der Daten und Variablen, die durch die oben unter Bezug nahme auf Fig. 4 beschriebenen Funktionen übermittelt und von der An wendung 114 und der APS-Redirektionsebene 150 verwendet werden. Die APS- Redirektionsebene 150 übersetzt von der Anwendung 114 empfangene Daten im APS-Parameter-Datenformat in ein gemeinsames Datenformat und schickt die Information zum DB-Zugriffsserver 116. Diese Formate können einzig für die Anwendung sein, enthalten jedoch die Information, die notwendig ist, um die Information in das gemeinsame Datenformat zu konvertieren. Das gemeinsame Datenformat ist im einzelnen weiter unten beschrieben. Wiederum wird beispielhaft auf den Mitel ® SX-2000 ® Telephonie-Schalter Bezug genommen.

(c) Gemeinsames Datenformat

Das gemeinsame Datenformat wird nur von der APS-Redirektionsebene 150, dem DB-Zugriffsserver 116, dem DBA-Kommunikationsserver 152 und der Kommunikations-Redirektionsebene 154 verwendet. Datenstrukturen werden von jeder Komponente verwendet, um Nachrichten, die zwischen diesen als ungetippte Daten verschickt werden, zusammenzusetzen oder zu interpretieren. Die APS-Redirektionsebene 150 nimmt die Daten, die von der Anwendung 114 im APS-Parameter-Datenformat empfangen wurden, und konvertiert sie in das gemeinsame Datenformat. Die spezifische Übersetzung hängt von der Machart, dem Modell und der Ver sion des Telephonie-Schalters 20 ab, der zu manipulieren ist. Hierbei handelt es sich insbesondere um den oben erwähnten SX-2000-Telephonie- Schalter. Das gemeinsame Datenformat umfaßt eine Versionsidentifikation, um sicherzustellen, daß Rückwärtskompatibilität in der Zukunft in dem Fall erhalten werden kann, daß Verbesserungen an dem gemeinsamen Daten format selbst vorgenommen werden. Dieses Format wird vor der Anwendung 114 versteckt. Änderungen des gemeinsamen Datenformats können unabhängig eingeführt werden, so daß die Versionen jeder Komponente ohne Kommunika tionsverlust differieren können.

Der DB-Zugriffsserver 116 hält für jeden Klienten einen Klien tendatensatz bereit (der Anschlußverbindung zugeordnet). Dieser Klien tendatensatz enthält den Kliententyp, -status, -namen, -freigabe, Ses sionszählung und Anschlußverbindungsaufzeichnung. Die Klienten der APS- Redirektionsebene 154 und des DB-Kommunikationsservers 152 sind unter schieden durch einen Kliententyp, nämlich CLIENT_APPLIC bzw. CLIENT_NE.

Datentypen des gemeinsamen Datenformats

Datentypen des gemeinsamen Datenformats werden zwischen der APS-Redirektionsebene 154, des DB-Zugriffsservers 116 und des DB-Kommu nikationsservers 152 verschickt.

Das folgende ist ein Beispiel der Definition des Typs von Anforderungen, die durch den DB-Zugriffsserver 116 und den Schalter-Da tenbasis-Server 118 getragen werden. Diese entsprechen den Aktionscodes, die von dem Telephonie-Schalter 20 getragen werden.

Das folgende ist ein Beispiel der Definition der Datenstruk tur für den Datenabschnitt einer Nachricht zum Senden an den Telephonie- Schalter 20 zur Durchführung einer der oben beschriebenen Transaktionen.

Das folgende ist ein Beispiel von Definitionen der Daten struktur für den Klientennamen und die Freigabe-Edition oder Version des Schalters als auch eine Struktur, um den Datenabschnitt einer Nachricht, die zum Telephonie-Schalter 20 zu senden ist, zu halten.

Diese Struktur kann in ihrer Größe anwachsen, um Rückwärtskompatibi lität zu handhaben.

Das folgende ist ein Beispiel von Definitionen der Daten struktur zur Verwendung in einem Telephonie-Schalter 20, der Vielfach ebenen besitzt (Fehler-tolerante Redundanz).

Das folgende ist ein Beispiel der Definition der Art des Feldes, das in einem Tupel erscheinen kann.

Das folgende ist ein Beispiel der Definition des Typs von Feldern, der in einem Tupel erscheinen kann.

Das folgende ist ein Beispiel der Definition des Typs von Views, die in einem Telephonie-Schalter erscheinen können.

Das folgende ist ein Beispiel der Definition, wie ein Feld aussehen mag, das in einem Tupel erscheinen kann.

Das folgende ist ein Beispiel der Definitionen für die Art von Feldern, die in einem Tupel für verschiedene Versionen von Telepho nie-Schaltern 20 erscheinen können.

Das folgende ist ein Beispiel von Definitionen der Daten struktur für die verschiedenen Typen von Views oder Tabellen, die von einem Telephonie-Schalter 20 getragen werden können.

Schalter-Datenbasis-Datentypen - Auch bei dem oben erwähnten SX-2000-Telephonie-Schalter werden Schalter-Datenbasis-Datentypen zur APS-Redirektionsebene überführt, die die Schalter-Datenbasis 124 direkt reflektiert. Diese sind:

Sessions-ID-Datentypen - Die Sessions-ID-Datentypen werden ebenfalls in allen Nachrichten übertragen und können geändert werden, sie sind:

Diese gemeinsamen Datenformattypen werden intern zur Datenba sis-Zugriffsebene zum internen Management verwendet und werden sich von Implementierung zu Implementierung ändern. Beispielsweise können diese umfassen:

(d) DB-Zugriffsserver

Der DB-Zugriffsserver 116 ist als ein separater Dämon-Prozeß-Betrieb in der Management-Station 10 vorgesehen, die Dienste für Klientenanwendungen 114 liefert. Zwischen einer Vielzahl von Anwendungen und einer Vielzahl von Telephonie-Schaltern ist eine Multiplex-Ausstattung vorgesehen. Einfache Anschlußverbindungen werden verwendet, um mit den Anwendungen durch die APS-Redirektionsebene 154 und den DB-Kommunikationsserver 152, auf die kollektiv als Klienten Be zug genommen wird, zu kommunizieren. Ausstattung mit Rückwärtskompatibi lität wird durch Verwendung eines gemeinsamen Datenformats für die Nach richten geliefert, die durch die Anschlußverbindung geschickt werden, wie weiter unten im einzelnen beschrieben wird. Nachrichten werden asyn chron (nicht blockierend) gesendet und empfangen.

Anschlußoperationen und Nachrichten im gemeinsamen Datenformat werden von dem DB-Zugriffsserver 116 ausschließlich durch den DBA Servi ce-Anschluß gehandhabt. Wo erforderlich, wird eine Konversion zwischen Nachrichtenversionen im gemeinsamen Datenformat und ebenfalls zwischen verschiedenen Versionen von Schalten-Datenbasen 124 durchgeführt.

Um die Kommunikation von der Management-Station 10 zum Tele phonie-Schalter 20 zu erleichtern, muß die Version des DB-Zugriffsser vers 116 höher als oder gleich der Version des Telephonie-Schalters 20 sein. Der DB-Zugriffsserver 116 enthält in sich Kenntnis von verschiede nen Modellen, Versionen und Revisionen von Telephonie-Schaltern 20, um es ihm zu ermöglichen, Befehle und Daten, empfangen von der Anwendung 114 in ein Format zu übersetzen, das vom Telephonie-Schalter 20 verstan den werden kann. Dies erlaubt Rückwärtskompatibilität. Der DB-Zugriffs server 116 hat Kenntnis von verschiedenen Befehlen und Datenformaten, die notwendig sind, um den Telephonie-Schalter 20 zu steuern und zu ma nagen. Er ist in der Lage, Elemente, wie notwendig, zu übersetzen, zu liefern und wegzulassen, um in einem Format, das sowohl von dem Telepho nie-Schalter 20 als auch von der Anwendung 114 verstanden werden kann, Befehle auszusenden und Antworten zu präsentieren. Eines der Vorteile hiervon besteht darin, daß es für die Anwendung 114 nicht erforderlich ist, Kenntnis von Änderungen zu haben, die sich aus verschiedenen Model len, Versionen und Revisionen von Telephonie-Schaltern 20 ergeben. Über die oben beschriebene Registerfunktion bestimmt die Anwendung 114 Ver sion, Modell und Revision des Telephonie-Schalters gegenüber dem DB-Zu griffsserver 116, die er fähig ist zu verstehen, und der DB-Zugriffsser ver 116 kann die Übersetzung durchführen, die notwendig ist, um der An wendung 114 Antworten zu liefern, die die Anwendung erwarten kann.

Ausführungseigenschaften

Die Kommunikationsverbindung und zugehörige Ebenen zielen auf PBX (private Nebenstellenanlagen) Ausführung. Dies ist abhängig von den Eigenschaften der Kommunikationsverbindung. Der Transaktionsmechanismus ermöglicht eine Anwendung gleichzeitig auf offene multiple DB-Views. Je mehr DB-Views modifiziert werden, desto länger benötigt eine Übergabeak tion zur Vervollständigung. Wenn ein Aktivitätsschalter zu irgendeiner Zeit während der Transaktion auftritt, bevor eine Übergabe erfolgreich abgeschlossen ist, werden alle Änderungen zurückgerollt. Aus diesem Grund ist es empfehlenswert, das Ausmaß von Änderungen, die in einer einzelnen Transaktion durchgeführt werden, zu begrenzen. Der Datenbasis- Zugriffsserver 116 managt Klienten-Verbindungsanforderungen und bereitet einen zugehörigen Klientendatensatz vor. Nachfolgende Nachrichten auf der Anschlußverbindung werden im Kontext dem zugehörigen Klientendaten satz im gemeinsamen Datenformat gehandhabt.

Jede Nachricht wird unabhängig behandelt und entweder übertra gen oder, wie gefordert, darauf eingewirkt. Wenn gefordert, werden auch Konversionen zwischen Nachrichtenebenen im gemeinsamen Datenformat und Schalter-Auslöseebenen durchgeführt.

Initialisierung - Der Datenbasis-Zugriffsserver 116 wird beim Systemstart in Gang gesetzt, wenn die Datenbasis-Zugriffsfunktionalität freigegeben wird. Jeder Klientendatensatz wird auf Null gesetzt, und der DBA_Service-Anschlußdienst wird etabliert.

Jede Funktion, die von der APS-Redirektionsebene 154 geliefert wird, initiiert eine Funktionsanforderung und blockiert das Ergebnis der Anforderung. Ein dbaError wird zurückgegeben, der entweder DBA_SUCCESS oder ein Fehlercode ist.

Wo erforderlich, wird die Anfrage in eine Anfrage im gemeinsa men Datenformat konvertiert, zum DB-Zugriffsserver 116 übertragen und die zugehörige Antwort im gemeinsamen Datenformat zur Rücksendung zur Anwendung 114 konvertiert.

Die folgende Anfrage wird dem DB-Zugriffsserver 116 zugeführt und von diesem behandelt.

Klienten verbinden

Das Handle Klientenverbinden wird aufge rufen, wenn eine Verbindung durch den Klienten auf dem DBA_Service-An schluß etabliert werden soll. Ein Klientendatensatz wird erhalten und der Verbindungsdatensatz initialisiert. Die Anschlußverbindung wird ver neint, wenn ein Klientendatensatz nicht verfügbar ist, da die Maximal zahl von gleichzeitigen Anschlußverbindungen überschritten ist.

Klienten trennen

Das Handle Kliententrennen wird aufgeru fen, wenn ein Trennen des Klienten auf dem DBA_Service-Anschluß erkannt wird. Die Verbindung wird geschlossen und der zugehörigen Klientendaten satz, wie gefordert, auf Null gesetzt.

Klienten registrieren

Das Handle Klientenregistrieren wird durch den Klienten markiert und bestimmt die Art des Klientenverbindens mit dem DB-Zugriffsserver 116. Dieser initialisiert der zugehörige Klientendatensatz entsprechend.

Registrierung wird verneint, wenn die Anzahl von erlaubten Klienten des gegebenen Typs überschritten wird.

Klienten deregistrieren

Aufgrund des Empfangs einer Klien ten-Deregistrier-Anforderung vom DB-Kommunikationsserver 152 wird durch den DB-Zugriffsserver 116 ein Check bezüglich der Anzahl von in Gang be findlichen Sessionen durchgeführt. Wenn keine Session aktiv ist, wird die zugehörige Anschlußverbindung geschlossen, bezüglich der zugehörigen Klienten wird eine Notifikation geliefert.

Session starten

Aufgrund des Empfangs einer Sessionsstartan forderung von der APS-Redirektionsebene 150 werden die Klientendatensät ze bezüglich eines existierenden DB-Kommunikationsservers 152, der mit dem gewünschten Telephonie-Schalter 20 kommuniziert, abgetastet. Wenn ein solcher tatsächlich nicht bereits existiert, wird ein DB-Kommunika tionsserver 152 durch den Datenbasis-Zugriffsserver 116 erzeugt. Die dbaSessionId wird initialisiert und teilweise unter Verwendung der zuge hörigen Klientendatensatz-Identifizierer etabliert, und der zugehörige DB-Kommunikationsserver 152 erhält die Sessionsstartanforderung. Nach Empfang einer Sessionsstartanforderung vom DB-Kommunikationsserver 152 wird der zugehörige Klient von der DBA-Session-ID bestimmt. Eine Bestä tigung wird an die anfordernde APS-Redirektionsebene 154 gesendet. An dieser Stelle ist die dbaSessionId vollständig etabliert.

Session beendigen

Nach Empfang einer Sessionsbeendigungsan forderung von der APS-Redirektionsebene 150 wird die Anzahl von in Gang befindlichen Sessionen geprüft. Wenn keine Sessionen aktiv sind, wird die zugehörige Anschlußverbindung geschlossen.

Die Sessionsbeendigungsanforderung wird nicht durch den DB- Kommunikationsserver 152 verwendet.

Anfrage und Antwort

Das Handle Anfrage-und-Antwort managt Anfragen für Schalter-Datenbasis-Operationen und zugehörige Antworten (Transaktionen starten, Transaktion übermitteln, Transaktion löschen, Tupel holen, hol erstes, hol nächstes, finde erstes, finde nächstes usw.). Validierung der dbaSessionId wird durchgeführt und die Nachricht im gemeinsamen Datenformat zum zugehörigen Klienten geschickt. Wenn er forderlich, wird eine Kompatibilitätskonversion ebenfalls angewendet.

Beschränkungen

Begrenzungen der Anzahl gleichzeitiger Klien ten werden auferlegt, um Betriebsmittelbeschränkungen zu managen. Die maximale Anzahl aller Anschlußverbindungen wird mit Grenzen bezüglich der Anzahl von Klienten für jeden Kliententyp spezifiziert.

Fehlerbehandlung

Sollte irgendein Nachrichtenübertragungs fehler an einer Anschlußverbindung auftreten, wird der zugehörige Klient deregistriert und die Anschlußverbindung gelöst. Keine Beeinträchtigung irgendeiner anderen bestehenden Verbindung wird bewirkt. Empfangene Nachrichten, die für einen Klienten bestimmt sind, der nicht länger exi stiert, werden verworfen. Ein unerwarteter Nachrichtenfehler wird in dem Fall protokolliert, daß der Kliententyp nicht erlaubt ist.

Zusätzliche Support-Vorkehrungen

Die folgenden Support-Vorkehrungen werden in dem DB-Zugriffs server 116 vorgesehen:

(i) Schalter-DB-Programmierungsverifikation
(ii) Support von multiplen Management-Stations-Sessionen
(iii) Support von multiplen Telephonie-Schalter-Sessionen
(iv) Inaktivitätszeitsperre bei Transaktionen
(v) Aktive und inaktive Ebenenbehandlung
(vi) Aktivitätsschalterbehandlung
(vii) Datenbasisversionen
(viii) Fehlererkennung
(ix) Rückwärtskompatibilität

Diese werden nachstehend im einzelnen beschrieben.

(i) Schalter-DB-Programmierungsverifikation

Während einer Operation, die den DB-View-Inhalt des Telephonie-Schalters 20 ändert, wird eine Validisierungsprozedur vorgenommen und irgendein Fehler be richtet. Wenn ein Fehler auftritt, wird der validisierungsfehlschlag der Anwendung 114 über die Fehleridentifikationsfunktion mitgeteilt, um ent sprechende Aktionen vorzunehmen.

(ii) Support von multiplen Management-Stations-Sessionen

Die Architektur ist so aufgebaut, daß multiple Sessionen ermöglicht werden. Das heißt, multiple Management-Stationen 10 oder multiple Benutzer-Work stations können auf einen gegebenen Telephonie-Schalter 20 mit der vor liegenden Architektur zugreifen. Aus diesem Aspekt heraus kann der Tele phonie-Schalter 20 enger in eine vernetzte Umgebung integriert werden, wenn der Status von verschiedenen Merkmalen des Telephonie-Schalters 20 mehreren Benutzern bekanntgegeben werden kann, und kann auf Anfrage durch individuelle Benutzer geändert werden.

(iii) Support von multiplen Telephonie-Schalter-Sessionen

Die vorliegende Architektur ermöglicht Vielfach-Sessionen bezüglich ei nes einzelnen Telephonie-Schalters 20 von verschiedenen Anwendungen 114. Dies ermöglicht multiple Anwendungen, um verschiedene Merkmale des Tele phonie-Schalters gleichzeitig abzufragen oder einzustellen.

(iv) Inaktivitätszeitsperre bei Transaktionen

Eine program mierbare Inaktivitätszeitsperre mit einem Vorgabewert von beispielsweise 20 min ist vorgesehen. Dies ermöglicht es, daß hängende oder inaktive Sessionen geziemend beendet werden können.

(v) Aktive und inaktive Ebenenbehandlung

Die Architektur ist ausgelegt um sowohl aktive als auch inaktive Ebenen eines redundanten Telephonie-Schalters 20 zu tragen. In dem Fall, in dem der Telephonie- Schalter 20 nicht unterteilt ist, sind nur DB-Zugriffs-Sessionen auf der aktiven Ebene erlaubt, um Änderungen der Telephonie-Schalter-Datenbasis 124 zu schreiben.

(vi) Aktivitätsschalterbehandlung

Nach Auftreten eines Akti vitätsschalters wird eine aufgebaute Session ohne den in der Anwendung 114 vorgesehenen spezifischen Grund fallengelassen.

(vii) Datenbasisversionen

Gemäß dem Ausführungsbeispiel wird ein Mitel ® SX-2000 ® Telephonie-Schalter verwendet, jedoch können auch andere Modifikationen und andere Modelle von Telephonie-Schaltern, ggf. von anderen Herstellern, verwendet werden. Bei der vorliegenden Ausfüh rungsform wird der existierende Retrieval-Mechanismus der Hauptsteue rungsladeversion für MNMS für die SX-2000 ®-Schalter verwendet. Für an dere Schalter oder Modelle kann der geeignete Mechanismus verwendet wer den, um die Software-Ladeversion zu bestimmen. Eine Tabelle in der Da tenbasis 120 identifiziert Datenbasisformänderungen für die verschiede nen Versionen.

(viii) Fehlererkennung

In dem Fall, daß ein Fehler auftritt, wird irgendeine im Gang befindliche Transaktion abgebrochen und die An wendung 114 von der Art des Fehlers unterrichtet. Eine Problemsituation existiert, wenn die Transaktionsübermittlung durch die Anwendung 114 ge fordert wurde. Unter dieser Bedingung kann die Unterbreitung vor dem Fehler erfolgreich gewesen sein oder nicht. Eine weitere Aktion kann er forderlich sein, um den Erfolg der Unterbreitungsoperation zu verifizie ren. Die folgenden spezifischen Fehler werden gehandhabt: Inaktivitäts zeitsperre, Aktivitätsschalter, Verbindungsausfall, DB-Zugriffsserver- Falle, Nachrichtenverlust, Rückwärtskompatibilität, Versionsfehlanpas sung.

Inaktivitätszeitsperre - Wenn die Sessions-Inaktivitätszeit sperre ausläuft, wird irgendeine im Gang befindliche Transaktion abge brochen und die Anwendungssession geschlossen.

Aktivitätsschalter - Aufgrund Aktivitätsschaltankündigung von Aktiv auf Inaktiv wird eine im Gang befindliche Transaktion abgebrochen.

Verbindungssausfall - Nach einem Kommunikationsfehler des DB- Zugriffsservers 116 wird eine im Gang befindliche Transaktion abgebro chen und die etablierte Session geschlossen.

DB-Zugriffsserver-Falle - In dem unwahrscheinlichen Fall, daß der DB-Zugriffsserver 116 einer Laufzeitfalle begegnet, wird er neu ge schaffen und im Gang befindliche Transaktionen werden abgebrochen.

Nachrichtenverlust - Die existierende Verbindungsebene ermög licht multiple Rückübertragung und Nachrichtenintegrität, und zwar in beiden Richtungen.

(ix) Rückwärtskompatibilität

Die Datenbasiszugriffsversion ist immer äquivalent zu oder größer als die höchste Version der Software des Telephonie-Schalters 20, mit dem sie verbunden ist. Anfragen und Antworten, die mit einer älteren Version der Software des Telephonie- Schalters 20 verbunden sind, werden innerhalb des DB-Zugriffsservers 116 gehandhabt.

Um die Kommunikation von der Management-Station 10 zum Tele phonie-Schalter 20 zu erleichtern, muß die Version des DB-Zugriffsser vers 116 größer oder gleich der Version des Telephonie-Schalters 20 sein. Der DB-Zugriffsserver 116 enthält in sich Kenntnis der verschiede nen Modelle, Versionen und Revisionen des Telephonie-Schalters 20, um es ihm zu ermöglichen, Befehle und Daten, die von der Anwendung 114 empfan gen werden, in ein Format zu übersetzen, das von dem Telephonie-Schalter 20 verstanden werden kann. Dies ermöglicht Rückwärtskompatibilität. Da der DB-Zugriffsserver 116 Kenntnis von den verschiedenen Befehlen und Datenformaten, die zur Steuerung und zum Managen des Telephonie-Schal ters 20 notwendig sind, hat, ist er in der Lage, zu übersetzen, zu lie fern und Elemente wegzulassen, falls notwendig, um Befehle zu verpacken und Antworten in einem Format zu präsentieren, das sowohl von dem Tele phonie-Schalter 20 als auch von der Anwendung 114 verstanden werden kann. Einer der Vorteile dieser Auslegung besteht darin, daß es für die Anwendung 114 nicht erforderlich ist, von irgendwelchen Änderungen in folge unterschiedlicher Modelle, Versionen und Revisionen des Telepho nie-Schalters Kenntnis zu haben. Durch die oben beschriebene Registrie rungsfunktion bestimmt die Anwendung 114 vom DB-Zugriffsserver 116 die Version, das Modell oder Revision des Telephonie-Schalter 20, die fähig ist zu verstehen, und der DB-Zugriffsserver 116 kann die notwendige Übersetzung durchführen, um der Anwendung 114 Antworten zu übermitteln, die die Anwendung 114 erwarten kann.

Die Anwendung 114 sollte zur Kompatibilität gegenüber dem DB- Zugriffsserver 116 rekompiliert werden. Beispielsweise werden die fol genden Änderungen durch den DB-Zugriffsserver 116 getragen:

- Neue Tabelle oder View hinzugefügt
Eine Tabelle oder ein View ist nicht durch den Telephonie- Schalter 20 vorgesehen, bis eine Anwendung 114 ausgelegt ist, dies zu fordern.
- Alter View entfernt
Die Anforderung der Anwendung 114 wird zurückgewiesen, wenn eine Tabelle oder ein View nicht von dem Telephonie-Schalter 20 getragen wird.
- Neues Feld hinzugefügt (zum Ende)
Die derzeit vorhandene Kennung wird in den Träger der APS- Redirektionsebene für das neue Feld eingeschlossen. Wenn das Feld nicht von dem Telephonie-Schalter 20 vorgesehen ist, liefert die derzeit vor handene Kennung für das Feld eine Fehlermeldung. Das Feld wird nicht zu einem Telephonie-Schalter älterer Version übermittelt, wenn es durch die Anwendung geliefert wird.
- Neue Aufzeichnung hinzugefügt (zum Ende)
Der Aufzeichnungswert wird durch den Telephonie-Schalter zu rückgewiesen, wenn er durch die Anwendung geliefert und nicht getragen wird.

Versionsfehlanpassung

In dem Fall, daß die Software-Version des Telephonie-Schalters 20 nicht erkannt wird, ist der Telephonie-Schalter 20 nicht für DBA-Ses sionen verfügbar. Ein Fehler wird zur Anwendung 114 über die Sessions startanforderung rückgemeldet.

(e) DB-Kommunikationsserver

Der DB-Kommunikationsserver 152 isoliert den DB-Zugriffsserver 116 von dem Netzwerk-Kommunikationsmecha nismus. Dieser umfaßt den Präsentationsebenenservice 156 und den Kommu nikationskanal 122.

Diese Isolierung ermöglicht, daß der Präsentationsebenenser vice 156 und der Kommunikationskanal 122 geändert werden, ohne daß der DB-Zugriffsserver 116 oder die Anwendungen 114 geändert werden müssen. Der Prozeß des DB-Kommunikationsservers 152 etabliert eine Anschlußver bindung mit dem DB-Zugriffsserver 116 und wartet auch auf Nachrichten von der Kommunikations-Redirektionsebene 154. Jede Nachricht wird unab hängig abgearbeitet und entweder übermittelt oder hierauf eingewirkt, wie es gefordert ist. Nachrichten werden asynchron (nicht blockierend) sowohl vom Telephonie-Schalter 20 als auch vom DB-Zugriffsserver 116 ge sendet und empfangen. Der DB-Kommunikationsserver 152 ist als ein sepa rater Prozeß vorgesehen, der in der Management-Station 10 abläuft und als ein Klient des DB-Zugriffsservers 116 wirkt.

Ein DB-Kommunikationsserver 152 wird für jeden Telephonie- Schalter 20 durch den DB-Zugriffsserver 116 in Ansprache auf Anforderun gen der Anwendung 114 erzeugt. Eine Zerstörung der Prozesse des DB-Kom munikationsservers 152 wird ebenfalls durch den DB-Zugriffsserver 116 gemanagt.

Der DB-Kommunikationsserver 152 verarbeitet dann die Anforde rung und schickt eine gemeinsame Datenantwort an den DB-Zugriffsserver 116 zurück. Der DB-Zugriffsserver 116 nimmt dann die notwendige Überset zung vor, um die Rückwärtskompatibilität handzuhaben, und transferiert, die gemeinsamen Datenresultate zurück zu der APS-Redirektionsebene 150.

Initialisierung

Der DB-Kommunikationsserver 152 wird durch den Datenbasis-Zugriffsserver 116 mit Befehlszeilenparametern ein schließlich der Identität des Telephonie-Schalters 20, mit dem er ver bunden ist, erzeugt. Ein Kommunikationskanal mit dem Telephonie-Schalter 20 wird aufgebaut und die Freigabeinformation bezüglich dieses Schalters erhalten. Ein Nachrichtenhandler wird dann angeschlossen, die Verbindung des Kommunikationskanals 122 abzuhören. Nach erfolgreicher Vervollstän digung dieser Operation ist der DB-Kommun 43535 00070 552 001000280000000200012000285914342400040 0002019805891 00004 43416ikationsserver 152 mit dem DB- Zugriffsserver 116 in Übereinstimmung gebracht.

Interfaces

Der DB-Kommunikationsserver 152 empfängt eine ge meinsame Datenanforderung von dem DB-Zugriffsserver 116. Der DB-Kommuni kationsserver 152 etabliert dann eine ComsessionID. Der DB-Kommunika tionsserver 152 sendet die gemeinsame Datenanforderung zu der Kommunika tions-Redirektionsebene 154 und wartet auf eine Antwort. Wenn eine Ant wort ankommt, schickt die Kommunikations-Redirektionsebene 154 eine ge meinsame Datenantwort zurück zum DB-Kommunikationsserver 152. Der DB- Kommunikationsserver 152 bestimmt dann die ComsessionID aus der Antwort und sendet dann die gemeinsame Datenanforderung zurück zum DB-Zugriffs server 116.

Anschlußoperationen und gemeinsame Datenformatnachrichten wer den durch den DB-Kommunikationsserver 152 über den DBA_Service-Anschluß gehandhabt. Die Funktionen der Kommunikations-Redirektionsebene 154 wer den verwendet, um die Kommunikation mit dem Telephonie-Schalter 20 zu managen.

NACHRICHTEN, DIE DURCH DEN DB-KOMMUNIKATIONSSERVER GEHANDHABT WERDEN

Es gibt zwei Arten von Nachrichten, die durch den DB-Kommuni kationsserver empfangen werden: Nachrichten von dem DB-Zugriffsserver 116 und Nachrichten von dem Telephonie-Schalter 20. Der DB-Kommunika tionsserver empfängt Nachrichten vom DB-Zugriffsserver 116 in einem ge meinsamen Datenformat und schickt diese zu der Kommunikations-Redirek tionsebene 154 zum Senden zum zugehörigen Telephonie-Schalter 20. Die Nachricht wird in ein gemeinsames Datenformat konvertiert und zu dem DB- Zugriffsserver 116 zur nachfolgenden Redirektion, basierend auf der Ses sions-ID, gesandt.

Sessionsbeginn

Nach Empfang einer Sessionsstartanforderung vom DB-Zugriffsserver 116 wird die Sessionszählung inkrementiert und die Anforderung zur Kommunikations-Redirektionsebene 154 übermittelt. Nach Empfang einer Sessionsstartantwort von der Kommunikations-Redirektions ebene 154 wird der zugehörige Klient von der CommsessionID bestimmt. Die Nachricht wird zum DB-Zugriffsserver 116 übermittelt.

Sessionsbeendigung

Eine Sessionsbeendigunganforderung vom DB-Zugriffsserver 116 wird an den Telephonie-Schalter 20 über die Kommu nikations-Redirektionsebene 154 übermittelt und die Sessionszählung de krementiert. In dem Fall, daß keine weiteren Sessionen zum Telephonie- Schalter 20 etabliert sind, wird eine Zeitsperre festgesetzt, um die konfigurierte Haltezeit abzuwarten.

Zeitsperre

Zeitablauf zeigt an, daß die Haltezeit vergangen ist. Der DB-Kommunikationsserver 152 stellt sicher, daß keine neuen Ses sionen etabliert wurden, löst die Verbindung zum Telephonie-Schalter 20 und beendet. Wenn eine Session etabliert wurde, wird die Zeitsperre be seitigt.

Fehlerbehandlung

Im Falle, daß eine Verbindung nicht eta bliert werden kann oder verloren geht, wird die existierende Fehlerbe handlung verwendet. Schwere Fehler werden geloggt, wobei der existieren de Log-Mechanismus im geeigneten Falle verwendet wird. Die Anschlußver bindung zum DB-Zugriffsserver 116 wird ebenfalls geschlossen.

3. Interface zwischen Datenbasis-Zugriffsebene und Datentrans portebene in der Management-Station

Das Interface zwischen der Datenbasis-Zugriffsebene und der Datentransportebene wird durch folgende Merkmale ausgeführt:

(a) Kommunikations-Redirektionsebene 154
(b) Kommunikationskanal 122
(c) Präsentationsebenenservice 156

Diese werden nachstehend näher beschrieben.

(a) Kommunikations-Redirektionsebene

Die Kommunikations-Re direktionsebene 154 isoliert den DBA-Kommunikationsserver 152 von der aktuellen Implementierung des spezifischen Netzwerktransportmechanismus. Die Kommunikations-Redirektionsebene 154 residiert in der Management- Station 10 als eine Bibliothek von Funktionen, mit denen Programme kom piliert und verknüpft werden. Die Kommunikations-Redirektionsebene 154 liefert Funktionen, die Kommunikationskanaldienste verwenden. Diese Funktionen managen das Öffnen und Schließen der Verbindung zum Telepho nie-Schalter 20 und den Austausch von Nachrichten. Auch ist eine Funk tion vorgesehen, um die Software-Freigabe des Telephonie-Schalters 20 abzufragen. Die Kommunikations-Redirektionsebene 154 empfängt eine ge meinsame Datenanforderung von dem DB-Kommunikationsserver 152. Die Kom munikations-Redirektionsebene 154 konvertiert die gemeinsame Datenanfor derung in die Form, die durch den Datentransportmechanismus verwendet wird, und sendet die Anforderung zum Kommunikationskanal 122. Der Kommu nikationskanal 122 schickt die Anforderung zum Telephonie-Schalter 20. Wenn eine Antwort vom Telephonie-Schalter 20 in der Form einer Trans portmechanismusantwort empfangen wird, schickt der Kommunikationskanal 122 die Antwort zu der Kommunikations-Redirektionsebene 154. Letzterer konvertiert die Antwort zu einer gemeinsamen Datenanforderung und sendet die gemeinsame Datenanforderung zum DB-Kommunikationsserver 152.

Die Kommunikations-Redirektionsebene 154 übersetzt Nachrichten vom gemeinsamen Datenformat, empfangen von dem DB-Kommunikationsserver 152, in das gewünschte Nachrichtenformat, das von der Datentransportebe ne verwendet wird, um mit dem Telephonie-Schalter 20 zu kommunizieren. Hierbei kann irgendein Datentransportmechanismus oder Nachrichtenformat verwendet werden, beispielsweise das MNMS-Datenformat von Mitel R und das Z.300-Datenformat. Letzteres ist ein international bekannter Stan dard, beschrieben im CCITT-Dokument, Band X, Facicle I, Rec Z301-Z341. Bei einem entsprechend anderen Datentransportmechanismus muß ggf. die Kommunikations-Redirektionsebene 154 umprogrammiert werden, um Nachrich ten in diesem anderen Datenformat zu akzeptieren, um diese in das ge meinsame Datenformat zu übersetzen, das durch den DB-Kommunikationsser ver 152 benutzt wird. Der Telephonie-Schalter 20, wenn er die Daten emp fängt, entpackt die Daten bezüglich ihres Nachrichtentransportformats zur eventuellen Verarbeitung. Der Telephonie-Schalter 20 und die Manage ment-Station 10 müssen daher einen kompatiblen Nachrichtentransportme chanismus verwenden.

MNMS-Nachrichten-Datenformat - Das MNMS-Nachrichten-Datenfor mat ist ein Beispiel eines Nachrichten-Transportmechanismus-Protokolls, das von der Kommunikations-Redirektionsebene 154 und dem Kommunikations kanal 122 verwendet werden kann, um mit dem Telephonie-Schalter 20 über den Präsentationsebenendienst 156 zu kommunizieren. Nachrichten werden von diesem Format zu einem gemeinsamen Datenformat übersetzt, um durch den DB-Kommunikationsserver 152 gehandhabt zu werden.

Diese Daten werden als eine typische Datenstruktur zum Trans portprotokoll zwecks Transport übermittelt. Die MNMS-Datentypen werden nachstehend näher beschrieben.

Wo erforderlich, wird die Anforderung von einer gemeinsamen Datenformatanforderung zu einer Transportprotokollnachricht konvertiert und auf den Kommunikationskanal 122 gegeben. Die Übersetzung wird auch in umgekehrter Richtung geschickt. Die folgenden Nachrichten werden zu sammen mit den Daten, die von der Kommunikations-Redirektionsebene 154 geliefert werden, an den Kommunikationskanal 122 zur Kommunikation mit dem Telephonie-Schalter 20 gegeben.

(i) Senden der Anforderung im gemeinsamen Datenformat

Das Senden einer Anforderung im gemeinsamen Datenformat konvertiert eine Nachricht im gemeinsamen Datenformat zu einer Transportprotokollnach richt und gibt diese auf den Kommunikationskanal 122. Eine Folgezahl wird in der Nachricht, basierend auf einem einzigen Kennzeichen verwen det.

(ii) Empfangen einer Antwort im gemeinsamen Datenformat

Das Empfangen einer Antwort im gemeinsamen Datenformat bedeutet eine MNMS- Nachricht vom Kommunikationskanal 122, die in eine Nachricht im gemein samen Datenformat konvertiert wird. Die Folgezahl in der Nachricht wird verwendet, um das einzige Kennzeichen zu bestimmen.

(iii) Verbindung zum Telephony-Schalter

Eine Verbindung zum Telephony-Schalter etabliert einen Kommunikationskanal mit dem spezifi zierten Telephony-Schalter 20. Der Schaltername wird validiert, wobei die Datenbasis verwendet wird, und ein Versuch, eine Verbindung zu öff nen, wird unternommen. Sollte der anfängliche Versuch fehlschlagen, wird er nach einer Verzögerung, basierend auf dem Grund des Fehlschlags, wie derholt. Nach erfolgreicher Verbindung wird die applicID verwendet, um den Empfang von Nachrichten zu registrieren.

(iv) Trennung vom Telephony-Schalter

Trennung von Netzwerk elementen schließt einen existierenden MNMS-Kommunikationskanal mit dem spezifizierten Netzwerkelement.

(v) Erlange Schalter-Freigabeinformation

Hierdurch wird die Software-Freigabeinformation vom Telephonie-Schalter 20 erhalten.

b) Präsentationsebenenservice

Der Präsentationsebenenservice 156 ist eine existierende Bibliothek von Funktionen, die eine Überset zung und Transformation zwischen einer Nachricht oder einem Datentrans portformat und spezifischen Z.300-Datendarstellungen managen. Der Prä sentationsebenendienst 156 residiert in der Management-Station 10 als eine Bibliothek von Funktionen, mit denen der DB-Kommunikationsserver 152 kompiliert und vernetzt wird.

c) Kommunikationskanal

Der Kommunikationskanal 122 residiert in der Datentransportebene und ist ein existierender Dämonprozeß, der Verbindungen mit individuellen Telephonie-Schaltern 20 managt. Er exi stiert als eine Bibliothek von Funktionen, mit denen der DB-Kommunika tionsserver 152 kompiliert und vernetzt wird. Der Kommunikationskanal managt die Kommunikation mit dem verbundenen Telephonie-Schalter 20. Funktionen sind vorgesehen, um den Kommunikationskanal zu verbinden und zu lösen, und erleichtern die Nachrichtenübermittlung. Das Z.300-Daten format wird vom Kommunikationskanal 122 und der existierenden Transport ebene verwendet, um mit dem Telephonie-Schalter 20 über den Präsenta tionsebenendienst 156 zu kommunizieren. Andere Datenformate können eben falls verwendet werden.

Die Merkmale der vorliegenden Architektur im Telephonie-Schal ter 20 werden nachstehend anhand von Fig. 5 näher beschrieben. Die Ar chitektur im Telephonie-Schalter 20 ist in einem großen Ausmaß das Spie gelbild zur vorher beschriebenen Management-Station 10. Die Übersetzun gen, die durchgeführt werden, bestehen bloß in einem Auspacken der in der Management-Station 10 eingepackten Information. Als solches kann da her in bezug auf die vom Telephonie-Schalter 20 durchgeführten Operatio nen auf diejenigen verwiesen werden, die von der Management-Station 10 durchgeführt werden.

Die von der Management-Station 10 empfangene Nachricht wird vom Telephonie-Schalter 20 über die Ethernet-Karte 112 empfangen. Die Nachricht wird dann durch den Kommunikationskanal 128 zum Nachrichten handler 180 überführt. Der Nachrichtenhandler 180 übersetzt die Nach richt aus ihrem Format in das DBA-Anforderungs-Datensatzformat zur Schnittstellenbildung mit dem Schalter-Datenbasisserver 118. Die vom Kommunikationskanal 128 und Nachrichtenhandler 118 gebildete Übersetzung wird weiter unten im einzelnen beschrieben. Der Nachrichtenhandler 118 übersetzt die Nachricht aus ihrem Datentransportformat in das DBA-Anfor derungs-Datensatzformat, so daß es durch den Schalter-Datenbasisserver 118 gehandhabt werden kann. Der Schalter-Datenbasisserver 118 erzeugt dann einen DB-Task-Server 182 (einen für jede Session). Der Schalter-Da tenbasisserver 118 schickt dann den DBA-Anforderungs-Datensatz zum DB- Task-Server 182 zur weiteren Verarbeitung. Der DB-Task-Server 182 über setzt den DB-Anforderungs-Datensatz in das geeignete Format, das von der Schalter-Datenbasis-Zugriffsanwendung 126 akzeptierbar ist, und schickt die Anforderung zur Schalter-Datenbasis-Zugriffsanwendung 126 zwecks Verarbeitung. Die Schalter-Datenbasis-Zugriffsanwendung 126 verarbeitet die Anforderung durch Zugriff auf die Schalter-Datenbasis 124 und schickt das Ergebnis zurück zum DB-Task-Server 182. Die Antwort wird dann durch letzteren in das DBA-Anforderungs-Datensatzformat übersetzt und die Aufzeichnung dann zum Schalter-Datenbasisserver 118 zur weiteren Verarbeitung übermittelt. Die Antwort gelangt dann durch den Schalter- Datenbasisserver 118 durch die Datenbasis-Zugriffsebene zur Datentrans portebene zum Nachrichtenhandler 180. Der Nachrichtenhandler 180 voll führt die Übersetzung zum Kommunikationskanal 128 und schickt die über setzte Nachricht zu diesem, der sie zur Ethernet-Karte 112 schickt, die mit dem Lokalbereichsnetzwerk 30 eine Schnittstelle bildet, um die Ant wort zur entsprechenden Management-Station zurückzuschicken.

4. Interface zwischen der Datentransportebene und der Datenba sis-Zugriffsebene im Telephonie-Schalter

Die Daten kommen vom Netzwerk 30 und werden über die Ethernet- Karte 112 zum Kommunikationskanal 128 geschickt. Der Nachrichtenhandler 180 weist einen DBA-Anforderungs-Datensatz zu, konvertiert das Eingangs datenformat zum DBA-Anforderungs-Datensatzformat und schickt dann das DBA-Anforderungs-Datensatzformat zum Schalter-Datenbasisserver 118, der den Datenbasis-Anforderungs-Datensatz empfängt und Ressourcen zuweist, um die Daten zu bedienen und die Servicedaten zurück durch das Interface zum Nachrichtenhandler 180 zu schicken. Letzterer konvertiert die DB-An forderungs-Datensätze zurück in das geeignete Format für den Kommunika tionskanal 128, an den die formatierten Daten zwecks Transport gegeben werden. Der Nachrichtenhandler 180 hebt erforderlichenfalls auch die Zu weisung des Raums für den DBA-Anforderungs-Datensatz auf. Es gibt drei Aspekte bezüglich des Interface zwischen der Datentransportebene und der Datenbasis-Zugriffsebene des Telephonie-Schalters 20:

(a) Kommunikationskanal
(b) Nachrichtenhandler
(c) DB-Zugriffs-Anforderungs-Datensatz

Die folgenden Aspekte des Interface zwischen der Datentrans portebene und der Datenbasis-Zugriffsebene im Telephonie-Schalter 20 werden nachstehend im einzelnen beschrieben.

(a) Kommunikationskanal

Der Kommunikationskanal 128 ist für die Handhabung der Eingabe/Ausgabe von Daten für einen spezifischen Transportmechanismus verantwortlich. Der Kommunikationskanal 128 packt die durch den Kommunikationskanal und den Mechanismus in der Management- Station eingepackten Daten aus. Bevorzugt ist ein OPSMAN MNMS-Kommunika tionskanal, obwohl auch andere Transportmechanismen verwendet werden können. Der Kommunikationskanal 128 ist in diesem Falle zum Konvertieren von Transportebenendaten im Format Z.300 zu und aus einem MNMS-Datenfor mat verantwortlich und übergibt diese dem Nachrichtenhandler 180. Der Kommunikationskanal 128 übersetzt dann die Nachricht in einen DBA-Anfor derungs-Datensatz, die von dem Schalter-Datenbasis-Zugriffsserver 118 und den DB-Tasks-Servern 182 verwendet wird. Der analysiert auch die Textdaten in Pascal-Tupel-Strukturen.

(b) Nachrichtenhandler

Jeder Nachrichtenhandler 180 wird durch eine einzige ID identifiziert. Neue Handler-ID's werden erforder lichenfalls hinzugefügt. Wenn ein Nachrichtenhandler - gewöhnlich beim Systemeinschalten - initialisiert wird, muß er mit dem Schalter-Datenba sisserver 118 zur Deckung gebracht werden, bevor erlaubt wird, DB-Zu griffsnachrichten zu senden. Der Registrierprozeß umfaßt eine Identifi zierung einer Rückruffunktion mit dem Schalter-Datenbasisserver 118 zum Nachrichtenhandler 180. Der Schalter-Datenbasisserver 118 verwendet die Rückruffunktion, um DB-Zugriffsresultate zum Nachrichtenhandler 180 zu rückzuschicken.

Der Betrieb des Interface zwischen dem Nachrichtenhandler 180 und dem Schalter-Datenbasisserver 118 ist folgendermaßen: Der Nachrich tenhandler 180 schickt einen DBA-Anforderungs-Datensatz zum Schalter-Da tenbasisserver 118, der einen DB-Task-Server 182 erzeugt und Querverwei se in seiner Ressourcentabelle eingibt, um die Nachrichten zum neuen DB- Task-Server 182 zu schicken, wenn eine neue Session stattfinden soll. Wenn eine neue Session nicht erforderlich ist, schickt der Schalter-Da tenbasisserver 118 alternativ bloß die Nachricht zum existierenden DB- Task-Server 182. Der DB-Task-Server 182 empfängt den DB-Zugriffs-Anfor derungs-Datensatz, den die Anforderung bedient. Wenn die Anforderung be dient ist, sendet der DB-Task-Server 182 die Service-Daten zum Schalter- Datenbasisserver 118 zurück, der sie durch das Interface zum Nachrich tenhandler 180 entsprechend der Ressourcentabelle weitergibt.

Der Nachrichtenhandler 180 ist in einen Eingabeprozeß und ei nen Ausgabeprozeß unterteilt. Der Eingabeprozeß ist an den Kommunika tionskanal gebunden und wartet auf eine Nachricht von der Management- Station 10. Wenn eine Nachricht durch den Kommunikationskanal 128 emp fangen wird, erhält der Nachrichtenhandler 180 einen DBA-Anforderungs- Datensatz von dem DBA-Anforderungs-Datensatz-Pool, analysiert die Text daten, füllt sie in den DBA-Anforderungs-Datensatz und sendet eine dba request-Nachricht zum Schalter-Datenbasisserver 118.

Die Rückruf-Funktion für den Nachrichtenhandler 180 ist ein Programm, das eine Antwortnachricht zum Nachrichtenhandler 180 schickt. Der Ausgabeprozeß führt auf eine Antwortnachricht vom Schalter-Datenba sisserver 118. Die Nachrichtendaten enthalten den Index einer DBA-Anfor derungs-Datensatz-Ressource. Der Nachrichtenhandler 180 konvertiert die Daten in ein Format für den Kommunikationskanal 128 und sendet die Nach richt zur Management-Station 10.

Um Nachrichten in das DB-Anforderungs-Datensatzformat zu kon vertieren, erhält der Nachrichtenhandler 180 eine DBA-Anforderungs-Auf zeichnungs-Ressource vom DBA-Anforderungs-Datensatz-Pool. Die Tupel- Text-Anteile der Nachricht werden analysiert und durch den DBA-Anforde rungs-Datensatz kopiert. Eine Nachricht wird dann zu dem Schalter-Daten basisserver 118 mit dem Ressourcen-Index in der Nachricht eingeschlossen gesandt.

Gegebenenfalls kann der Nachrichtenhandler 180 Information von der eingehenden Nachricht in einen Transportdatensatz loggen. Der Trans portdatensatz wird aus einer freien Liste erhalten, die von dem Resour cen-Pool gemanagt wird. Der Datensatz enthält Information, die für den Ausgabevorgang des Nachrichtenhandlers 180 erforderlich ist, jedoch nicht in dem DBA-Anforderungs-Datensatz aufgeführt werden kann. Ein Feld in dem DBA-Anforderungs-Datensatz wird verwendet, um die Ressourcen-Zahl des Transportdatensatzes aufzuzeichnen. Die Folgezahl aus der Nachricht des Nachrichtenhandlers 180 wird in dem Transportdatensatz aufgezeichnet und die Transportdatensatz-Ressource wird in dem DBA-Anforderungs-Daten satz gespeichert.

Wenn eine Nachricht von dem Kommunikationskanal 128 empfangen wird, bestimmt der Nachrichtenhandler 180, welche Nachricht gesendet wird, und führt folgende Operationen bezüglich der Nachrichtendaten aus:

- Erhalten einer DBA-Anforderungs-Datensatz-Ressource
- Analysieren der Tupel- oder Schlüsseltextdaten zum Einsetzen in den DBA-Anforderungs-Datensatz
- Analysieren der View-Satz-Textdaten zum Einsetzen in den DBA-Anforderungs-Datensatz
- Analysieren der Tupel-Maskendaten zum Einsetzen in den DBA- Anforderungs-Datensatz
- Einfügen der analysierten Daten in den DBA-Anforderungs-Da tensatz
- Erhalten einer Transport-Datensatz-Ressource vom Transport- Datensatz-Pool
- Einsetzen der Ressourcen-Zahl in den Transport-Datensatz und Speicher der Ressourcen-Zahl in dem DBA-Anforderungs-Datensatz
- Senden einer Nachricht zum Schalter-Datenbasisserver 118 mit dem Ressourcen-Index der Nachrichtendaten.

Das Übertragen und Löschen von Transaktionswirkungen erfordert einen Parameter, der eine Sessions-ID enthält. Die Transaktionsstartak tion erfordert einen Parameter, der eine Sessions-ID und eine View-Sätz- Information enthält.

Der Nachrichtenhandler 180 empfängt Datenbasis-Zugriffsserver- Antwortnachrichten vom Schalter-Datenbasisserver 118 in Ansprache auf Datenbasis-Zugriffs-Anforderungs-Nachrichten. Diese Antwortnachrichten enthalten Ressourcen-Zahlen für DBA-Anforderungs-Datensatz-Ressourcen. Die gleiche Ressource, die zugewiesen wurde, als die Anforderung zu nächst von der Management-Station 10 kam, wird verwendet. Der Nachrich tenhandler 180 konvertiert dann die Tupel-Daten in den DBA-Anforderungs- Datensätzen in das Nachrichtenformat des Kommunikationskanals 128, an den die Nachricht übergeben wird. Die DBA-Anforderungs-Datensatz- Ressource wird dann zum Pool zurückgegeben.

Wenn der Schalter-Datenbasisserver 118 mit dem Senden einer Antwort zurück zum Nachrichtenhandler 180 fertig ist, übermittelt er den Index eines DBA-Anforderungs-Datensatzes, um die Nachrichtendaten zu er halten.

(c) DBA-Anforderungs-Datensatzformat

Das Auftreten des DBA- Anforderungs-Datensatzes dient zum Auslösen des Schalter-Datenbasisser vers 118 vom Verlaß auf eine bestimmte Datendarstellung des Kommunika tionskanals. Auf diese Weise kann ein neuer Kommunikationskanal und eine neue Methode zum Tragen von Verbindungen zu verschiedenen Arten von Schaltern hinzugefügt werden, ohne den Schalter-Datenbasisserver 118 zu modifizieren. Irgendein Kommunikationskanal 120 kann verwendet werden, der die Daten zum Message-Handler 180 überführt. Der Message-Handler 180 erfordert dann eine Modifikation in der Weise, wie sie an sich bekannt ist, um empfangene Daten aufzunehmen und in das DB-Zugriffs-Anforde rungs-Datensatzformat zu transformieren. Der DBA-Anforderungs-Datensatz enthält alle Tupel, Views, View-Sätze und andere Information, die erfor derlich ist, um Zugriff zur Schalter-Datenbasis 124 zu liefern. Während der größte Teil der Information aus der Anwendung 114 und der Datenba sis-Zugriffsebene der Management-Station 10 stammt, wird einiges der In formation durch den Nachrichtenhandler 180 eingefügt. Die Datenbasis-Zu griffs-Ergebnisse werden in dieser Struktur außerdem gespeichert.

Ein Datensatz dieses Typs wird jeder Datenbasis-Zugriffs-An forderung zugewiesen und dem Pool zurückgegeben, wenn die Anforderung abgeschlossen ist.

- dba_session_id - Die Session-ID wird durch den Prozeß des Schalter-Datenbasisservers 118 zugewiesen, wenn eine Sessions-Start-An forderung empfangen wird.
- dba_action_code - Dieses Feld wird in dem Nachrichtenhandler 180 ausgefüllt, um die Aktion zu indizieren, die durch die Anwendung 114 angefordert wird.
- dba_view_id - Dieses Feld wird durch den Nachrichtenhandler 180 aus Daten, die durch die Anwendung 114 geliefert werden, ausgefüllt. Es handelt sich um die View-ID des Views, dessen Aktion durchzuführen ist.
- dba_old_tuple - Dieses Feld wird durch den Nachrichtenhand ler 180 mit Daten, die von der Anwendung 114 geliefert werden, ausge füllt. Dieses Feld ist nur für die Aktion des Modifizierens eines Tupels notwendig.
- dba_view_tuple - Dieses Feld ist ein Eingabe- und Ausgabe feld. Es wird durch den Nachrichtenhandler 180 mit von der Anwendung 114 gelieferten Daten zum Schreiben auf die Datenbasis und durch den Schal ter-Datenbasisserver 118 mit Ergebnissen einer geforderten Aktion ge füllt.
- dba_view_set - Dieses Feld wird durch den Nachrichtenhandler 180 mit durch die Anwendung 114 gelieferten Daten gefüllt.
- dba_tuple_mask - Dieses Feld wird durch den Nachrichtenhand ler 180 mit von der Anwendung 114 gelieferten Daten gefüllt. Es wird nur für dba_find-Aktionen verwendet. Es handelt sich um die Maske, die die Suchkriterien zum Tupelsuchen beschreibt.
- dba_error_ref - Dieses Feld wird durch den Schalter-Datenba sisserver 118 gefüllt, um irgendeine Fehlerbedingung anzuzeigen, die von einer Datenbasis-Zugriffs-Anforderung resultiert.
- dba_transport_hdlr_id - Dieses Feld wird durch den Nachrich tenhandler 180 mit der Identifikation des Nachrichtenhandlers 180 ge füllt. Dieser Wert wird später verwendet, um die Rückruffunktion für den Nachrichtenhandler 180 zu erhalten.
- transport_hdlr_resource - Dieses Feld ist optional. Es kann durch den Nachrichtenhandler 180 verwendet werden, um eine Ressourcen-ID für eine Ressource aufzuzeichnen, die über den Daten, die in dem DBA-An forderungs-Datensatz gespeichert sind, erforderlich ist. Auf diese Weise kann der Nachrichtenhandler 180 Daten auf den DBA-Anforderungs-Datensatz Huckepack geben.

5. Datenbasis-Zugriffsebene im Telephonie-Schalter

Der Schalter-Datenbasisserver 118 ist der Brennpunkt für die Bewegung von Anforderungen durch den Telephonie-Schalter. Er empfängt DB-Zugriffsanforderungen von den verschiedenen Nachrichtenhandlern im DBA-Anforderungs-Datensatz-Format, weist Ressourcen zu, um die Anforde rung zu bedienen und schickt die bedienten Daten zu den Nachrichtenhand lern zurück.

Der Datenbasis-Zugriffsserver 118 erzeugt einen neuen Prozeß des DB-Task-Servers 182, jedesmal wenn eine Sessions-Start-Nachricht von einem Nachrichtenhandler 180 empfangen wird. Für alle anderen Nachrich tentypen prüft er die Sessions-ID, um einen existierenden DB-Task-Ser ver 182 zu identifizieren, um diesem die Nachricht zuzuführen. Der Schalter-Datenbasis-Server 118 hält eine Ressourcen-Tabelle aufrecht, die bezüglich dessen Spur hält, mit was Nachrichtenhandler mit welchen DB-Task-Servern 182 kommunizieren. Der Schalter-Datenbasisserver 118 va lidiert die Sessions-ID und sendet Nachrichten, zu dem Prozeß des DB- Task-Servers 182, der in der Sessions-ID identifiziert ist.

Der Schalter-Datenbasisserver 118 empfängt Datenbasis-Zu griffs-Anforderungs-Nachrichten, Inaktivitäts-Zeit-Nachrichten und kann eine Datenbasis-Zugriffsantwortnachricht senden.

Der Schalter-Datenbasisserver 118 besteht aus einem permanen ten Prozeß, der gewöhnlich beim Anfahren des Systems erzeugt wird.

Wenn ein Nachrichtenhandler 180 eine DB-Zugriffs-Anforderung empfangen hat, sendet der Schalter-Datenbasisserver 118 eine Datenbasis- Zugriffsnachricht nach Vorbereitung der geforderten Daten im DB-Zu griffs-Datenformat. Die Nachrichtendaten enthalten eine Ressourcennummer für eine Datenbasis-Zugriffs-Datenstruktur, die dem Nachrichtenhandler zugewiesen ist. Der Schalter-Datenbasisserver 118 prüft die Datenstruk tur, um einen Aktionskurs zu bestimmen. Er ist mit zwei Größen befaßt, der Sessions-ID und der DB-Aktion. Wenn die Sessions-ID leer und die DB- Aktion "Sessionsstart" ist, ordnet der Schalter-Datenbasisserver 118 ei nen DB-Task-Prozeß von einem Pool von Prozessen zu und übergibt die Da tenbasis-Zugriffs-Nachricht an den neuen Task-Prozeß. Wenn die Sessions- ID nicht leer ist, verifiziert der Schalter-Datenbasisserver 118, daß die Sessions-ID das System-ID für den Telephonie-Schalter enthält und daß die Prozeß-ID diejenige eines existierenden Prozesses eines DB-Task- Servers 182 ist. Wenn diese Prüfungen durchlaufen sind, wird die Daten basis-Zugriffsnachricht dem Prozeß des DB-Task-Servers 182 zugeführt. Schließlich wird eine Querverweis-Tabelle mit der Sessions-ID und der Handler-ID aus den letzten Stand gebracht. Wenn der Schalter-Datenbasis server 118 eine Datenbasis-Zugriffsnachricht von einem DB-Task-Server 182 erhält, sendet er die Nachricht zu dem zugehörigen Nachrichtenhand ler 180 unter Prüfen der Querverweis-Tabelle.

6. Interface zwischen Datenbasis-Zugriffsebene und Anwendungs ebene im Telephonie-Schalter

Der DB-Task-Server 182 empfängt die grundlegenden Befehle, die ursprünglich von der Anwendung 114 ausgegeben wurden, und übersetzt sie in ein Format, das zur Schalter-Datenbasis-Zugriffsanwendung 126 über führt und von dieser ausgeführt werden kann. Die exakte auszuführende Übersetzung hängt von den Merkmalen der Schalter-Datenbasis-Zugriffs anwendung und der genauen Bauart, dem Modell und der Version des Tele phonie-Schalters 20 ab. Die notwendige Übersetzung zur Implementierung kann in üblicher Weise durch Programmieren des Telephonie-Schalters 20 vorgenommen werden.

Der DB-Task-Server 182 ist zum Bedienen der DB-Zugriffs-Anfor derungen verantwortlich. Er wird erzeugt, wenn der Schalter-Datenbasis server 118 eine Sessions-Start-Nachricht empfängt und beendet, wenn die ser eine Sessions-Beendigungsnachricht empfängt.

Initialisierung

Der Task-Server-Prozeß wird durch den Schal ter-Datenbasisserver 118 auf der Basis pro Session erzeugt und ist ein permanenter Prozeß. Er ist für das Zuordnen einer Sessions-ID zur An laufzeit einer Session und zum nachfolgenden Verarbeiten von Anforderun gen bezüglich dieser Sessions-ID verantwortlich.

Der DB-Task-Server 182 weist einer Sessions-ID, wenn er eine Sessions-Start-Anforderung in einer Datenbasis-Zugriffs-Anforderungs- Nachricht empfängt, zu. Die Sessions-ID enthält die Prozeß-ID des Task- Servers 182, die System-ID des Telephonie-Schalters und die Ebenen-ID. Die Sessions-ID wird zurück zum Schalter-Datenbasisserver 118 in einer Datenbasis-Zugriffs-Antwortnachricht gegeben.

Der erste Task, den der DB-Task-Server 182 durchführt, besteht darin, eine Sessions-ID zuzuweisen und diese zurück an den DB-NE-Server zu geben. Alle nachfolgenden DB-Zugriffs-Anforderungen werden gegen die se Sessions-ID durch den Schalter-Datenbasisserver 118 verifiziert. Der DB-Task-Server 182 führt zusätzliche Prüfungen bezüglich des Prozeß-ID- Anteils der Sessions-ID durch.

Der DB-Task-Server 182 empfängt einen DBA-Anforderungs-Daten satz, der alle Daten enthält, die erforderlich sind, um die geforderte Aktion durchzuführen. Er ruft die entsprechenden Funktionen auf (bei spielsweise Mitel ®® DBVIEW-Funktionen), um die Aktion durchzuführen und plaziert die resultierenden Daten zurück in den DBA-Anforderungs-Da tensatz. Die resultierenden Daten und Antworten werden zurück zu dem Schalter-Datenbasisserver 118 geliefert, der sie an den entsprechenden Nachrichtenhandler 180 weitergibt. Ein Prozeß des DB-Task-Servers 182 wird jeder Session zugewiesen.

Der DB-Task-Server 182 trägt die folgenden Funktionen:

(i) Fehleridentifikation
- Hole Fehlertext
(ii) Service Session-Funktionen
- Starte Session
- Beende Session
(iii) Service Übersetzungsfunktionen (Übersetzungsmanagement)
- Starte Transaktion
- Übermittle Transaktion
- Lösche Transaktion
(iv) Hole erste/nächste Anforderung
- Hole erstes Tupel
- Hole nächstes Tupel
(v) Lese-/Schreib-Anforderungen
- Hole Tupel
- Addiere Tupel
- Lösche Tupel
- Modifiziere Tupel

Diese Funktionen bilden das APS und entsprechen den Funktions aufrufen, die durch die Anwendung 114 der Management-Station 10 erfol gen. Der Datenbasis-Task-Server 182 transformiert die Anforderung in die spezifische Form und schickt sie zu der Schalter-Datenbasis-Zugriffs anwendung 126.

(i) Fehleridentifikation (ii) Service Sessions-Funktionen

Der DB-Task-Server 182 be dient die beiden Sessions-Funktionen Starten und Beendigen.

Starte Session

Der Task-Server 182 weist eine Sessions- ID zu.

Beende Session

Der Task-Server 182 verifiziert, daß die Sessions-ID korrekt ist, und prüft, daß keine Transaktion aktiv ist. Wenn eine Transaktion aktiv ist, wird eine Fehlermeldung zurückge schickt, um anzuzeigen, daß die Transaktion übertragen oder gelöscht werden muß, bevor die Session enden kann. Wenn keine Transaktion aktiv ist, dann schickt der DB-Task-Server 182 einfach eine dba_reply-Nach richt zurück, die keinen Fehler anzeigt.

(iii) Service Transaktionsfunktion (Transaktionsmanagement)

Der DB-Task-Server 182 bedient die drei Transaktionsfunktionen Starten, Übermitteln und Löschen.

(a) Starte Transaktion

Wenn der Task-Server 182 eine Transaktion-Start-Anforderung empfängt, prüft er den DBA-Anforderungs- Datensatz bezüglich des textlichen View-Satz-Parameters. Der Text wird durch einen View-Satz-Textanalysator geschickt. Wenn dieser auf einem SX-2000 ®-Telephonie-Schalter ausgeführt ist, wird der resultierende View-Satz zum Schreibzugang durch den DB-Task-Server 182 durch Aufrufen DBVIEW open__view__set-Funktion geöffnet. Die Views werden geöffnet und verriegelt. Der Erfolg oder Fehlschlag des Öffnungsvorgangs wird in dem DBA-Anforderungs-Datensatz aufgezeichnet und der Task-Server 182 sendet eine Datenbasis-Zugriffs-Antwortnachricht zurück zu dem Schalter-Daten basisserver 118, der die DBA-Anforderungs-Datensatz-Ressource anzeigt.

(b) Übermittle Transaktion

Wenn der Task-Server 182 eine Transaktions-Übermittlungsanforderung empfängt, übersetzt er die Anforderung und überführt diese zur Schalter-Datenbasis-Zugriffs-Anwen dung 126. Bei einem SX-2000-Telephonie-Schalter ruft er die DBVIEW close_view_set-Funktion mit dem db_mode-Parameter gesetzt auf db_commit. Die Änderungen in den unterliegenden Datenbasis-Tabellen für den offenen View-Satz werden zur Festplatte gespült und der View-Satz geschlossen und entriegelt. Der Erfolg oder Fehlschlag der Übertragungsoperation wird in dem DBA-Anforderungs-Datensatz aufgezeichnet, und der DB-Task- Server 182 sendet eine Datenbasis-Zugriffs-Antwortnachricht zurück zum Schalter-Datenbasisserver 118, der die DBA-Anforderungs-Datensatz- Ressource anzeigt.

(c) Annuliere Transaktion

Wenn der DB-Task-Server 182 eine Transaktions-Annulierungs-Anforderung empfängt, übersetzt er die Anforderung und schickt sie zu der Schalter-Datenbasis-Zugriffs-Anwen dung 126. Beispielsweise bei einem SX-2000-Telephonie-Schalter ruft er die DBVIEW close_view_set-Funktion mit dem db_mode-Parameter gesetzt auf db_abort. Die Änderungen in den unterliegenden Datenbasistabellen für den offenen View-Satz werden von der Festplatte restauriert und der View-Satz geschlossen und entriegelt. Der Erfolg oder Fehlschlag dieser Annulierungsoperation wird in dem DBA-Anforderungs-Datensatz aufgezeich net, und der DB-Task-Server 182 sendet eine Datenbasis-Zugriffs-Antwort- Nachricht zurück zum Schalter-Datenbasisserver 118, der die DBA-Anforde rungs-Datensatz-Ressource anzeigt.

(iv) Hole erste/nächste Anforderung

Der DB-Task-Server 182 bedient die Daten-View-Funktionen.

(a) Hole erstes Tupel

Wenn der DB-Task-Server 182 eine Anforderung zum Holen des ersten Tupels empfängt, prüft er den DBA-An forderungs-Datensatz in bezug auf die View-ID. Die View-ID wird zu der Schalter-Datenbasis-Zugriffs-Anwendung 126 überführt. Beispielsweise bei einem SX-2000-Telephonie-Schalter wird die DBVIEW first_view key-Funk tion aufgerufen. Der erste Schlüssel für die spezifizierte View-ID wird zurückgesandt und der DB-Task-Server 182 schickt den Schlüssel zur DBVIEW read_view_tuple-Funktion. Der Tupel-Inhalt oder irgendein resul tierender Fehlercode werden in dem DBA-Anforderungs-Datensatz gespei chert. Der DB-Task-Server 182 sendet eine Datenbasis-Zugriffs-Antwort nachricht zurück zu dem Schalter-Datenbasisserver 118, der die DBA-An forderungs-Datensatz-Ressource anzeigt.

(b) Hole nächstes Tupel

Wenn der DB-Task-Server 182 ei ne Anforderung zum Holen des nächsten Tupels empfängt, prüft er den DBA- Anforderungs-Datensatz in bezug auf das View-ID und den textlichen Tu pel-View-Parameter. Der Text wird durch einen View-Tupel-Textanalysator geschickt. Die Schlüsseldaten werden von den Tupel-Daten extrahiert und die Anforderung übersetzt und zu der Schalter-Datenbasis-Zugriffs-Anwen dung 126 überführt. Beispielweise wird bei einem SX-2000-Telephonie- Schalter die DBVIEW next_view_key-Funktion mit den Schlüsseldaten aufge rufen. Der nächste Schlüssel für die spezifizierte View-ID wird zurück geschickt und der DB-Task-Server 182 schickt den neuen Schlüssel zu der DBVIEW read_view_tuple-Funktion. Der Tupel-Inhalt oder irgendein Fehler code werden in dem DBA-Anforderungs-Datensatz gespeichert. Der DB-Task- Server 182 schickt dann eine Datenbasis-Zugriffs-Antwortnachricht zurück zu dem Schalter-Datenbasisserver 118, der die DBA-Anforderungs-Daten satz-Ressource anzeigt.

(v) Lese-/Schreib-Anforderungen (a) Hole Tupel

Wenn der DB-Task-Server 182 eine Anforde rung zum Tupelholen empfängt, prüft er den DBA-Anforderungs-Datensatz für die View-ID und den textlichen View-Tupel-Parameter. Der Text wird durch einen View-Tupel-Textanalysator geschickt. Das Schlüsseldatum wird von den Tupel-Daten extrahiert und der DB-Task-Server 182 übersetzt die Anforderung und schickt diese zur Schalter-Datenbasis-Zugriffs-Anwendung 126. Beispielsweise wird im Falle eines SX-2000-Schalters die DBVIEW re ad_view_tupel-Funktion mit dem Schlüssel und den Tupel-Daten aufgeru fen. Der Tupel-Inhalt oder irgendein resultierender Fehlercode werden in dem DBA-Anforderungs-Datensatz gespeichert. Der DB-Task-Server 182 sen det eine Datenbasis-Zugriffs-Antwortnachricht zurück zu dem Schalter-Da tenbasisserver 118, der die DBA-Anforderungs-Datensatz-Ressource an zeigt.

(b) Addiere Tupel

Wenn der DB-Task-Server 182 eine An forderung zum Tupeladdieren empfängt, prüft er den DBA-Anforderungs-Da tensatz für die View-ID und den textlichen View-Tupel-Parameter. Das Schlüsseldatum wird von den Tupel-Daten extrahiert und die Anforderung übersetzt und an die Schalter-Datenbasis-Zugriffs-Anwendung 126 überge ben. Beispielsweise im Falle eines SX-2000-Telephonie-Schalters wird die DBVIEW write_view_tuple-Funktion mit dem Schlüssel, den Tupel-Daten und den Parametern aufgerufen. Eine resultierender Fehlercode wird in dem DBA-Anforderungs-Datensatz gespeichert. Der DB-Task-Server 182 sendet dann eine Datenbasis-Zugriffs-Antwortnachricht zurück zu dem Schalter- Datenbasisserver 118, der die DBA-Anforderungs-Datensatz-Ressource an zeigt.

(c) Lösche Tupel

Wenn der DB-Task-Server 182 eine Anfor derung zum Tupellöschen empfängt, prüft er den DBA-Anforderungs-Daten satz für die View-ID und den textlichen View-Tupel-Parameter. Das Schlüsseldatum wird von den Tupel-Daten extrahiert und die Anforderung übersetzt und an die Schalter-Datenbasis-Zugriffsanwendung 126 übertra gen. Beispielsweise wird im Falle eines SX-2000-Telephonie-Schalters die geeignete DB-View-Funktion aufgerufen. Ein resultierender Fehlercode wird in dem DBA-Anforderungs-Datensatz gespeichert. Der DB-Task-Server 182 sendet dann eine Datenbasis-Zugriffs-Antwortnachricht zurück zu dem Schalter-Datenbasisserver 118, der die DBA-Anforderungs-Datensatz- Ressource anzeigt.

(d) Modifiziere Tupel

Wenn der DB-Task-Server 182 eine Anforderung zum Tupelmodifizieren empfängt, prüft er den DBA-Anforde rungs-Datensatz in bezug auf die View-ID und die textlichen View-Tupel- Parameter. In diesem Fall werden alte und neue Tupel-Parameter vorhanden sein. Er vergleicht die Schlüssel und ruft die geeignete DBVIEW write view_tuple-Funktion, replace_view_tuple-Funktion oder delete_view_tuple- Funktion, wie es notwendig ist. Ein resultierender Fehlercode wird in dem DBA-Anforderungs-Datensatz gespeichert. Der DB-Task-Server 182 sen det dann eine Datenbasis-Zugriffs-Antwortnachricht zurück zum Schalter- Datenbasisserver 118, der die DBA-Anforderungs-Datensatz-Ressource an zeigt.

Claims

1. Telephonie-Schalter-Konfigurator zum Managen und Steuern wenigstens eines Telephonie-Schalters (20) von einer Netzwerk-Einrich tung (30), wobei der Telephonie-Schalter (20) ein les-/beschreibbares Speichermedium zum Speichern einer Konfiguration des Telephonie-Schal ters (20) enthält und von einem Computer-Netzwerk über einen ersten Da tentransportprotokollhandler zugänglich ist, wobei die Netzwerkeinrich tung mit dem Computer-Netzwerk über einen zweiten Datentransportproto kollhandler kommuniziert, mit

(a) einen Befehlsgenerator (114) innerhalb der Netzwerkein richtung (30), der von dem Telephonie-Schalter (20) auszuführende Befeh le erzeugt,
(b) einem ersten Zugriffsserver (116) in der Netzwerkeinrich tung zum Managen einer Verbindung zum Telephonie-Schalter (20),
(c) einem ersten Interface (115) zwischen dem Befehlsgenerator (114) und dem ersten Zugriffsserver (116) zum Übertragen von Befehlen zwischen dem Befehlsgenerator (114) und dem ersten Zugriffsserver (116),
(d) einem zweiten Interface zwischen dem ersten Zugriffserver (116) und dem ersten Datentransportprotokollhandler zum Übermitteln von Befehlen zwischen dem ersten Zugriffsserver (116) und dem ersten Daten transportprotokollhandler,
(e) einem zweiten Zugriffsserver (118) innerhalb des Telepho nie-Schalters (20) zum Managen einer Verbindung zu der Netzwerkeinrich tung (30),
(f) einem dritten Interface zwischen dem zweiten Zugriffsser ver (118) und dem zweiten Datentransportprotokollhandler zum Übermitteln von Befehlen zwischen dem zweiten Datentransportprotokollhandler und dem zweiten Zugriffsserver (118),
(g) einem Befehlsausführer innerhalb des Telephonie-Schalters (20), der die Befehle zum Ändern der Konfiguration des Telephonie-Schal ters (20) ausführt, und
(h) ein viertes Interface zwischen dem zweiten Zugriffsserver (118) und dem Befehlsausführer zum übersetzen der Befehle zwischen dem zweiten Zugriffsserver (118) und dem Befehlsausführer.

2. Telephonie-Schalter-Konfigurator nach Anspruch 1, dadurch gekennzeichnet, daß der erste Datentransportprotokollhandler ein Daten basis-Managementsystem umfaßt.

3. Telephonie-Schalter-Konfigurator nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß eine Datenbasis-Zugriffs-Anwendung (114) aus Datenbasis-Tabellen mit identischer Datenbasis-Struktur wie der Telepho nie-Schalter (20) vorgesehen ist.

4. Telephonie-Schalter-Konfigurator nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß der erste Zugriffsserver (116) derart ausgebildet ist, daß er gleichzeitig mit einer Vielzahl von Telephonie- Schaltern (20) Verbindungen aufrechterhalten kann.

5. Telephonie-Schalter-Konfigurator nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, daß der Telephonie-Schalter (20) von ei ner vom Konfigurator unterschiedlichen Version ist.

6. Verfahren zum Managen und Steuern eines Telephonie-Schal ters (20) von einer Netzwerkeinrichtung, wobei der Telephonie-Schalter (20) mit einem Computer-Netzwerk über eine Datentransportprotokoll und die Netzwerkeinrichtung mit dem Computer-Netzwerk über das Datentrans portprotokoll kommuniziert, wobei

(a) ein Befehl initiiert wird, um einen ausgewählten Telepho nie-Schalter (20) von der Netzwerkeinrichtung zu verbinden,
(b) der Befehl in ein Format übersetzt wird, das von einem er sten Zugriffsserver (116) verstanden wird,
(c) der Befehl zum ersten Zugriffsserver (116) übertragen wird,
(d) ein Kommunikationskanal zu dem ausgewählten Telephonie- Schalter (20) geöffnet wird,
(e) der Befehl zum Transport unter Verwendung des Datentrans portprotokolls gepackt wird,
(f) der Befehl zu einem Datentransportprotokollmechanismus überführt wird,
(g) der Befehl in dem Netzwerk zu dem spezifischen Telephonie- Schalter (20) unter Verwendung des Datentransportprotokolls transpor tiert wird,
(h) der von dem Telephonie-Schalter (20) empfangene Befehl un ter Verwendung des Datentransportprotokollmechanismus entpackt wird,
(i) der Befehl zu einem zweiten Zugriffsserver (118) überführt wird,
(j) der Befehl in eine Form übersetzt wird, die von dem Tele phonie-Schalter (20) ausgeführt werden kann, und
(k) der Befehl durch den Telephonie-Schalter (20) zum Ändern seiner Konfiguration ausgeführt wird.

7. Verfahren zum Konfigurieren eines Netzwerks von Telephonie- Schaltern (20) einer Netzwerkeinrichtung, wobei die Telephonie-Schalter (20) mit einem Computer-Netzwerk über ein Datentransportprotokoll und die Netzwerkeinrichtung mit dem Netzwerk über das Datentransportproto koll kommunizieren, wobei

(a) ein Befehl initiiert wird, um einen ersten ausgewählten Telephonie-Schalter (20) der Netzwerkeinrichtung zu verbinden,
(b) Konfigurationsinformation von dem ersten ausgewählten Te lephonie-Schalter (20) zur Netzwerkeinrichtung heruntergeladen wird,
(c) ein Befehl initiiert wird, um einen zweiten ausgewählten Telephonie-Schalter (20) mit der Netzwerkeinrichtung zu verbinden, und
(d) die Information von der Netzwerkeinrichtung zum zweiten ausgewählten Telephonie-Schalter (20) hochgeladen wird.