So können On-Premises Kunden ihre COM Schnittstellen, die nur in der Vertec Desktop App laufen, umrüsten für die Zukunft
Das Arbeiten mit COM im Zusammenspiel mit Vertec war in der Vertec Desktop App schon immer möglich. In den letzten Jahren wurde COM mit Vertec so erweitert, dass dies auch mit der Vertec Cloud App möglich ist: Durch einen COM Proxy für die Vertec COM Schnittstelle (von aussen auf Vertec zugreifen) sowie dem COM Forwarding für den Zugriff aus Vertec auf Drittprogramme.
Die Varianten via COM Proxy und COM Forwarding funktionieren auch mit der Vertec Desktop App. Da die Desktop App auf Vertec 7.1 eingestellt wird, sollten herkömmliche COM Schnittstellen entsprechend umgebaut werden, um auch nach dieser Version noch lauffähig zu sein.
In diesem Artikel beschreiben wir die Unterschiede und wie Sie Ihre Schnittstellen umrüsten können.
Die in Vertec.Desktop.exe und Vertec.Cloud.exe enthaltene Vertec Type Library kann in der externen Applikation eingebunden werden, um Zugriff auf den Objektkatalog und damit auf code completion und compile-time type checking zu erhalten.
Der COM Proxy kennt die Type Library und damit Typen wie IVtcObject, App etc. jedoch nicht. Die Deklaration von Objekten, Objektlisten, Session muss deshalb immer auf Object lauten. Statt:
Dim Projektbearbeiter as IVtcObject
schreibt man also:
Dim Projektbearbeiter as Object
Die entsprechenden COM Interfaces sind im laufenden Betrieb dann vorhanden, sobald das Objekt geladen wird.
Da der COM Server bei der Desktop App direkt, bei der Cloud App via Proxy verfügbar ist, ergeben sich unterschiedliche Interface Namen. Die darauf verfügbaren Eigenschaften und Funktionen sind jedoch identisch, so dass sich bei der Verwendung selbst nichts ändert.
Sobald der Zugriff bzw. die Deklaration wie oben beschrieben umgestellt wird und nicht mehr via Type Library Typen erfolgt, ist das deshalb irrelevant. Damit Sie sich bei der Beschreibung der einzelnen COM Interfaces jedoch zurecht finden, hier die Unterschiede:
| Type Library | COM Proxy |
|---|---|
| App (IVtcSession) | ComCoClass |
| IVtcObject | VtcObjectProxy |
| IVtcObjectList | VtcObjectListProxy |
| ITimBearbeiter | TimBearbeiterProxy |
| ... | ... |
Die Übergabe von als Variant deklarierten Vertec Objekten in Funktionen war nicht möglich bei der Verwendung der Type Library und der Deklaration von Vertec Objekten als diese Typen. Es erschien eine Meldung Ungültiger Prozeduraufruf oder ungültiges Argument.
Via COM Proxy und der Deklaration von Vertec Objekten als Object (siehe oben) funktioniert das problemlos.
In der Desktop App wurde das COM Objekt direkt aus der App unter Verwendung des Python COM Systems (win32com.client) angelegt (win32com.Dispatch).
Mit COM Forwarding wird das COM Objekt auf dem Client-System angelegt (vtccom.createobject(identifier)). Die Interaktionen mit dem resultierenden Python Objekt werden dann zur Cloud App übertragen und dort auf das eigentliche COM Objekt angewendet. In der Desktop App wird das originale COM Objekt zurückgegeben.
Für die Umstellung auf COM Forwarding muss das Modul vtccom importiert und die Aufrufe wie folgt geändert werden:
| COM Forwarding | Bisher |
|---|---|
import vtccom self.invoice = vtccom.createobject('ThirdPartyAPI.Invoice') |
from win32com.client import Dispatch self.invoice = Dispatch('ThirdPartyAPI.Invoice') |
import vtccom word = vtccom.createobject("Word.Application") word.Visible = True doc = word.Documents.Add() doc.SaveAs(r"C:\temp\Test Document.docx") |
from win32com.client import Dispatch Word = Dispatch('Word.Application') Word.Visible = True doc = Word.Documents.Add() doc.SaveAs(r"C:\temp\Test Document.docx") |
Damit die Schnittstellen mit COM Forwarding auch mit Restrict Scripting funktionieren, müssen Aufrufe von Modulen wie sys oder pywintypes ausgebaut werden. Es dürfen nur Module verwendet werden, die auf der Whitelist stehen.