Remote Procedure Call (Teil 3)

Der letzte Teil unseres Beitrags zur Verbindung zweier CONZEPT 16-Applikationen stellt den Prozeduraufbau in der Zieldatenbank vor. Außerdem geht es um erweiterte Anforderungen an den RPC-Mechanismus, wie die Handhabung von Benutzerrechten, Laufzeitfehlern und Versionskompatibilität.

Prozedurstruktur

Analog zum Aufbau der Prozeduren in der Quelldatenbank und der Funktionen der DLL gibt es jeweils eine Initialisierungs- und Terminierungsfunktion, die entsprechend beim Öffnen und Schließen der Zieldatenbank aufgerufen werden. Die Funktionen sind recht einfach, da es im Kontext der Prozedurausführung immer nur eine einzige Instanz gibt.

global
{
  DllHdl		: handle;
  DllData		: int32;
}

sub ImplementInit
(
  aDllPath	: alpha;
  aDllData	: int32;		// 32-Bit
)
: int;
{
  VarAllocate(ImplementData);
  DllData # aDllData;

  // DLL laden
  DllHdl # DllLoad(aDllPath + sDllFileName,sDllCallBackName));
  if (tDllHdl < 0)
  {
    VarFree(ImplementData);
    return(tDllHdl);
  }
  return(_rOK);
}

sub ImplementTerm
{
  DllHdl->DllUnload();
  VarFree(ImplementData);
}

Die via RPC aufrufbaren Funktionen in der Zielanwendung werden ohne spezifische Argumente und Rückgabewerte deklariert. Alle Funktionen liefern lediglich einen Fehlercode als int-Resultat, die nötigen Argumente und Rückgaben holt sich die Funktion über eine Reihe von Supportfunktionen, die wiederum die Daten via Callback-Funktion mit der DLL austauschen:

sub ImplementStorePicture : int;
{
  // Argumente lesen
  SupportProcArgInit();
  SupportProcArgReadAlpha(VAR tPicName);
  SupportProcArgReadInt32(VAR tPicSize);
  // Memory-Objekt erzeugen und füllen
  SupportProcArgReadMemObj(VAR tMemObj,tPicSize);

  // Bild speichern – Alternativ:
  //   AppPicMgr:StorePicture(tPicName,tPicSize,VAR tPicSizeDba);

  tBinHdl # BinOpen(0,'/pic/' + tPicName,_BinCreate | _BinLock);
  if (tBinHdl < 0)
    tError # tBinHdl;
  else
  {
    tError # tBinHdl->BinWriteMem(tMemObj);
    SupportProcArgWrite(tBinHdl->spSizeDba);
    tBinHdl->BinClose();
  }

  tMemObj->MemFree();
  return(tError);
}

Hier noch ein Beispiel für die verwendeten Supportfunktionen:

sub SupportProcArgInit
{
  DllHdl->DllCall(sDllCbFuncProcArgInit,DllData);
}

sub SupportProcArgReadInt32
(
  VAR aDataVal  	: int32;
)
{
  DllHdl->DllCall(sDllCbFuncProcArgReadInt32,DllData,VAR aDataVal);
}

sub SupportProcArgReadMemObj
(
  VAR aMemObj	: handle;
  aMemObjSize	: int32;
)
{
  // Memory-Objekt anlegen
  aMemObj # MemAllocate(aMemObjSize);
  // DLL kopiert die Daten vom Memory-Objekt der Quelldatenbank
  // in das Memory-Objekt der Zieldatenbank
  if (aMemObj > 0)
    DllHdl->DllCall(sDllCbFuncProcArgReadMemObj,DllData,
                    aMemObj->spBaseAddress,aMemObjSize);
}

Benutzerrechte

Falls in der Zieldatenbank unterschiedliche Rechte zu berücksichtigen sind, gibt es mehrere Lösungswege. Zum einen können verschiedene Datenbankbenutzer in der Zieldatenbank verwendet werden. Alternativ kann es nur einen Benutzeraccount für RPC geben und die Rechte werden zur Laufzeit von der Quell- an die Zieldatenbank transferiert. In diesem Fall muss die Verarbeitung der Rechte dann in den Prozeduren der Zieldatenbank erfolgen.

Laufzeitfehler in der Zieldatenbank

Bei Laufzeitfehlern in einer Zielprozedur liefert die API-Funktion C16_ProcCall() einen entsprechenden Fehlercode zurück. Dabei ist der Code um -1000 verschoben, ein Resultat von -1180 entspricht -180 (_ErrStringOverflow) in der Prozedurumgebung.

Der Fehlerwert kann dann in der Quellprozedur entsprechend verarbeitet werden, falls notwendig kann die Prozedurverarbeitung auch mit dem exit-Befehl komplett abgebrochen werden.

Versionskontrolle

Erweiterungen des RPC-Funktionsumfangs – das bedeutet zusätzliche oder erweiterte Funktionen – ergeben meist Änderungen in Quell- und Zieldatenbank, die DLL als Vermittlungsschicht ist eher selten betroffen. Daher ist es äußerst wichtig, dass die Prozedurversionen in beiden Datenbanken auf ihre Kompatibilität hin kontrolliert werden.

Das kann durch eine Funktion realisiert werden, in der die Quellprozedur die eigene Versionsinformation (Quelle) an eine Zielprozedur übergibt. Die Zielprozedur liefert dann zum einen die Version der Zielprozeduren zurück, zum anderen überprüft sie die Kompatibilität mit der Quellversion und übermittelt das Resultat der Prüfung an die Quellprozedur, die ebenfalls eine eigene Kompatibilitätsprüfung vornimmt.

Durch diesen doppelten Versions-Check können gegebenenfalls auch ältere Quellprozeduren mit neueren Zielprozeduren arbeiten als auch umgekehrt. Bei älteren Zielprozeduren sind seitens der Quelldatenbank dann Funktionseinschränkungen zu berücksichtigen.