Die Infrastruktur sucht zunächst unter HKEY_LOCAL_MACHINE\Software\TAA\Config, danach unter HKEY_CURRENT_USER\Software\TAA\Config nach einem Eintrag EnvSpec. Wird dieser gefunden, werden weitere Einträge in folgenden Bäumen gesucht:
Dabei entspricht [EnvSpec] dem zuvor unter dem Eintrag EnvSpec gefundenen Wert.
In den Beschreibungen der einzelnen Einträge werden die möglichen Registry-Bäume und Unter-Abschnitte bis hin zum Schlüssel „TAA „bzw. „TAA\Env\[EnvSpec]“ durch die Bezeichnung „HKEY…[]“ abgekürzt, z.B. „HKEY…[]\Config“.
Wenn eine EnvSpec-Angabe in einem Config-Abschnitt gefunden wird, dann ist es zwingend erforderlich, daß dazu ein Registry-Baum HKEY_LOCAL_MACHINE\Software\TAA\Env\[EnvSpec] existiert.
Falls kein EnvSpec gefunden wird, bleiben als Suchpfade übrig
Falls ein gefundener Registry-Eintrag aus einem schreibgeschützten Bereich stammt, wird dieser Eintrag anschließend auch als solcher behandelt. So kann es z.B. passieren, daß der Trackbar im Monitor-Fenster sich nicht mehr verschieben läßt, weil die entsprechende Einstellung für InfoLevel in der Registry im aktuellen Kontext aus einem Bereich stammt, auf der der aktuelle Benutzer keine Schreibberechtigung hat.
Die Suchreihenfolge bewirkt, daß Einstellungen, die unter HKEY_LOCAL_MACHINE schreibgeschützt vorgenommen wurden, von dem Benutzer unter HKEY_CURRENT_USER nicht verändert werden können. Auch wenn dort ein anderslautender Eintrag stehen würde, würde dieser nicht berücksichtigt werden.
Anders gesagt: Die Angabe in HKEY_CURRENT_USER ziehen nur dann, wenn nicht bereits unter HKEY_LOCAL_MACHINE entsprechende Einträge gefunden wurden.
In der Praxis wird dies so genutzt, daß bei einem Sachbearbeiter im schreibgeschützten Bereich die Produktionsumgebung eingetragen wird, in der er arbeitet, sodaß er nicht die Möglichkeit hat, in eine Entwicklungsumgebung zu wechseln. Umgekehrt wird bei einem Entwickler keine auf ein produktives System verweisende EnvSpec eingetragen sein, um versehentliches Verändern der Produktionsumgebung auszuschließen.
Aus den Abkürzungen für Company und Appl\<Anwendung> plus der Versions-Angabe der <Anwendung> setzt die TAA-Infrastruktur den Namen der DLL zusammen, in der die Resourcen für die betreffende Anwendung zu finden sind, z.B. für die Anwendung „Test“:
ergibt als Name der DLL TWST52A.DLX
DerSuffix ist immer “.dlx“.
Es brauchen nicht alle Resourcen einer Anwendung in einer einzigen DLL enthalten zu sein. Die angegebene DLL ist lediglich der Einstiegspunkt, um Resourcen für die betreffende Anwendung zu finden. Üblich ist, daß sie Verweise auf andere DLLs enthält, die wietere Resourcen derselben Anwendung enthalten. Im Extremfall braucht diese DLL sogar keine einzige Resource enthalten, sondern nur die Verweise auf andere DLLs.
Für die Namen dieser anderen DLLs gilt die Konvention, daß sie sich nur durch ein Zeichen von dem Namen der Einstiegs-DLL unterscheiden, und zwar wird für die Anwendungs-Abkürzung eine dritte Stelle eingefügt. Eine DLL, die die oben angeführte „TWST52A.DLX“ ergänzt, könnte also z.B. heißen: „TWSTX52A.DLX“, oder „TWST152A.DLX“.
Die Erstellung der Ressourcen-DLLs und die Verteilung der Ressourcen in verschiedene DLLs regeln Sie über den TAA Ressourcen-Generator.
Implementierungstypen
Nachfolgend eine Aufstellung der zur Zeit bekannten Implementierungstypen. Für jeden Typ ist angegeben, welche zusätzlichen Angaben als Ispc erforderlich sind, damit die TAA-Infrastruktur das Modul korrekt aufrufen kann.
Die Implementierungstypen können angegeben werden in der Registry unter Appl\<Anwendung>\Debug\<Modul>, sowie in der Config-Beschreibung der Module. Die Angabe in einer Implementierungsspezifikations-Datei ist veraltet und sollte nicht mehr benutzt werden.
| ITyp | Ispc-Angaben in Registry, Config oder Ispc-Datei | Beschreibung | Beispiel |
|---|---|---|---|
| Strg | keine | Steuerungsmodul, das mit ControlEdge erstellt wurde. Wird von der TAA-Infrastruktur immer aus einer Resourcen-DLL lt. ComponentPath geladen. | |
| Dllc32 *** | Dll-Name, Name des Entry-Points (getrennt durch Komma, Leezeichen und Tabs werden ignoriert) | C-Modul, das Bestandteil einer 32-bit-C-DLL ist. | d:\work\test\gen32\test_c\debug\test_c.dll, pg_nfun_dynsgut |
| DllCob32 *** | wie dllc32 | Cobol-Modul, das Bestandteil einer 32-bit-Cobol-DLL ist. | d:\work\test\gen32\debug\mycobnx2.dll, Z0TWPGP1 |
| Exe *** | Modulname, ggf. mit Pfad oder Suffix; Argumente | Ausführbares Modul (Executable). Wenn kein Pfad angegeben ist, wird ComponentPath verwendet. Wenn kein Suffix angegeben ist, wird „.exe“ angenommen. Zusätzlich können Argumente übergeben werden; dabei wird „%n“ ersetzt durch den Bausteinnamen in der EDB, „%e“ durch das auszulösende Ereignis. Name und Argumente sind durch Semikolon getrennt. | |
| Eci | Program=<programmname>;Transaction=<transid> - oder - Programmname, Transid (getrennt durch Komma, ohne Leerzeichen) | Modul, das sich auf dem CICS-Host befindet und über die ECI-Schnittstelle aufgerufen wird. Aufgrund der Namenskonventionen auf dem Host muss der in der EDB festgelegte Kurzname des Moduls angegeben werden, außerdem kann die Transaktions-ID angegeben werden. | |
| MQI | wie eci | Wird demnächst nicht mehr unterstützt. | |
| manual ** | keine | Wird verwendet für ein Modul, das noch nicht implementiert ist. Statt eines Moduls wird der TAA Template-Dialog gestartet. | |
| xl50 ** | Nicht mehr unterstützt. Zur Einbindung von Excel-Sheets bitte Ityp=Exe benutzen und in VBA programmieren. | ||
| Cobol *, NetExpress * 1) | Modulname, ggf. mit Pfad oder Suffix | Bis 9.06: Ausführung mit COBOL Animator (MicroFocus Workbench bzw. NetExpress). Wenn kein Pfad angegeben ist, wird ComponentPath verwendet. Wenn kein Suffix angegeben ist, versucht die TAA-Infrastruktur zuerst, das Modul mit dem Suffix „.int“, danach mit „.mpc“ oder „.cob“2) zu öffnen. | D:\WORK\test\gen32\bcprops.int |
| Ossy, OssyDebug * 3) | Modulname, ggf. mit Pfad oder Suffix | Bis 9.06: In beiden Fällen wird Ossy mit dem Modulnamen aufgerufen, bei OssyDebug über den MicroFocus COBOL Animator. Die zu startende Anwendung kann über die Config-Angaben Ossy bzw. OssyDebug konfiguriert werden. | |
| vb50 *, vb60 * | Modulname, ggf. mit Pfad oder Suffix | Ausführung mit Visual Basic IDE. Wenn kein Pfad angegeben ist, wird für die Suche nach der VB-Projektdatei ComponentPath verwendet. Wenn kein Suffix angegeben ist, versucht die TAA-Infrastruktur, das Modul mit dem Suffix „.vbp“ zu öffnen. | |
| DllCLR *** | Assembly-Name, Klasse, Methode, Flags (Getrennt durch Semikolon) | Ein Modul, implementiert mit einem von Microsoft .NET unterstutzte Sprache (VB.NET, C#). Das Assembly wird über ComponentPath gesucht. Die Infrastruktur erzeugt ein Instanz der angegebene Klasse und löst die angegebene public Methode aus. Diese Methode sollte keine Parameter erwarten, und keine Rückkehrwert liefern. Wenn der Flag G angegeben wird, wird die Assembly aus der GAC geladen. Als Assembly-Name muss dann der sog. Fullname (<Name>, Version=<…>, Culture=<…>, PublicKeyToken=<…>) eingetragen werden. Der Flag Y bewirkt, dass die Infrastruktur zusätzlichen Aufwand betreibt, um das Modul auf einem eigenen Thread auszuführen, damit der Yield-Befehl auch wie bekannt funktioniert. Da dieser Aufwand nicht unerheblich ist, sollte dieser Flag auch nur dann angegeben werden, wenn nötig. Wenn der Baustein auf einem eigenen Thread ausgeführt wird, und Windows Forms verwendet, muss dieser Thread zwingend in einem sog. single threaded apartment ausgeführt werden. Wenn das aber explizit nicht erwünscht ist, kann der Flag M angegeben werden. Dies sorgt dafür, dass der Thread in einem sog. multi threaded apartment ausgeführt wird. | d:\work\test\gen32\dotnetTest\Test\Test.dll;tclass;do_it; |
| ExeCLR *** | wie exe | Ein Modul, implementiert mit einem von Microsoft .NET unterstutzte Sprache (VB.NET, C#), welches als eigenständiges Prozess ausgeführt werden soll. Hier können die gleichen Argumente wie bei exe übergeben werden. | D:\WORK\test\ConsoleApplication1\bin\Debug\ConsoleApplication1.exe |
| AspCLR *** | Beschreibung | Wird verwendet für mit ASP.NET implementierte Webanwendungen. Die Implementierungsspezifikation wird genau so aufgebaut wie bei http, allerdings wird nur der 2 Teil (das zu adressierende Dokument) ausgewertet. | |
| http *** | Beschreibung | wie beschrieben, aber die Kommunikation zwischen Web-.Client und Server findet mittels komprimierten binären Datenströmen4) statt. | |
| empty | keine | Es werden lediglich die Parameterzuweisungen gemäß der Schnittstelle ausgeführt, also CRE oder DEL werden ggf. wirksam. Auf diese Weise können z.B. über einen Modulaufruf Objekte angelegt oder gelöscht werden, ohne dass weiterer Code ausgeführt und gepflegt werden muss. Dieser Ityp kann auch im Test angegeben werden, um die Ausführung eines Moduls zu überspringen. | |
| vsnet * | Beschreibung | Ausführung mit Visual Studio .NET. Wenn kein Pfad angegeben ist, wird für die Suche nach der Solution ComponentPath verwendet. Wenn kein Suffix angegeben ist, versucht die TAA-Infrastruktur, das Modul mit dem Suffix „.sln“ zu öffnen. | |
*) Die mit * gekennzeichneten Implementierungstypen sollten in einem produktiv eingesetzten System (zur Verwendung durch den Sachbearbeiter) nicht vorkommen!
**) Die mit ** gekennzeichneten Implementierungstypen können auch zur Verwendung durch den Sachbearbeiter angeboten werden, setzen aber entsprechende Kenntnisse des Sachbearbeiters voraus.
***) Bei den mit *** gekennzeichneten Implementierungstypen können in der Implementierungsspezifikation Platzhalter für zur Laufzeit zu ersetzende Angaben benutzt werden: