Es ist das konzeptionelle Credo von AMTANGEE, unseren Kunden eine solide Basis für ein optimiertes Kundenbeziehungsmanagement anzubieten. Wo immer sich interne Prozesse und Informationsflüsse eines Unternehmens standardisieren lassen, bietet AMTANGEE die notwendigen Tools zur Verbesserung an – „out of the box“. Allerdings: Kein Unternehmen gleicht dem anderen! Vordefinierte Schnittstellen gewährleisten daher, der Individualität unserer Kunden Rechnung tragen zu können, etwa durch die Modellierung hochspezialisierter interner Arbeitsprozesse unter Zuhilfenahme der Workflow Engine oder in Form einer Anbindung von Drittsoftware über ein eigenes Modul. Da AMTANGEE alle relevanten internen Funktionen über ein Software Development Kit (SDK) exponiert, lassen sich entsprechende Kundenanpassungen zügig realisieren. Der erste Beitrag unserer neuen Entwickler-Reihe „/dev/inside/“ stellt in zwei Teilen die beiden gebräuchlichsten Möglichkeiten zur Erweiterung – Workflows und Module – vor, beleuchtet ihre jeweiligen Anwendungsfälle und zeigt an einem beispielhaften Plugin, wie flexibel AMTANGEE sich an individuelle Anforderungen anpassen lässt.
Am Anfang steht das AMTANGEE SDK
Ein SDK ist – ganz allgemein ausgedrückt – eine Sammlung fertiger Programme oder auch Programmbibliotheken. Es gestattet Software-Entwicklern, eigene Programme auf der Grundlage von bereits bestehendem Code zu implementieren. So muss das Rad nicht ein zweites Mal erfunden werden. Es kann jedoch – bei deutlich reduziertem Aufwand – angepasst werden. AMTANGEE stellt Interessenten ein SDK zur Verfügung, mit dem sich der Funktionsumfang von AMTANGEE zügig um individuelle Anforderungen erweitern lässt – wie komplex sie auch immer sein mögen. Das AMTANGEE SDK fungiert als eine mächtige Universalfernbedienung, die tiefgreifende Veränderungen der internen Datenhaltung von AMTANGEE ermöglicht. Nicht zuletzt aus diesem Grund ist die Entwicklung eigener Workflows und Module an eine SDK-Vereinbarung geknüpft, über deren Rahmenbedingungen Sie unser Support-Team gerne informiert.
Los geht’s: AMTANGEE durch eigene Workflows erweitern
Kundenspezifische Workflows reagieren auf das interne Messaging von AMTANGEE, indem Sie bestimmte Funktionen implementieren, die das SDK Workflow-Erweiterungen anbietet, um Informationsflüsse optimal an die Arbeitsabläufe eines Unternehmens anzupassen, Events wie z.B. „EmailReceived“, „AppointmentNotificationReceived“, „CallNotificationReceived“, „FaxReceived“, „FaxSent“, “MessageChanged“ oder „NotificationReceived“. Als im Hintergrund laufender Dienst stellt die AMTANGEE Workflow Engine sicher, das beim Auftreten bestimmter Ereignisse auch komplexe Folgeaktionen auf verfügbare Inhaltselemente angewendet werden können, beispielsweise die regelbasierte Weiterleitung von E-Mails an bestimmte Mitarbeiter aufgrund von Informationen im Betreff eingehender Nachrichten. Das kann eine nach bestimmten Kriterien formatierte Ticket-ID sein. Oder auch die Versandmitteilung eines Onlineshops.
Das AMTANGEE SDK steht in Form von DLL-Dateien zur Verfügung, die nur als Verweise ins eigene Software-Projekt integriert werden müssen. Diese dynamischen Programmbibliotheken sind Teil der AMTANGEE Distribution, weil der AMTANGEE Client selbst – im Sinne einer strikten Trennung von Programmlogik und Darstellung – auf diesen Bibliotheken aufbaut. Das SDK hält somit für Entwickler sämtliche Funktionen bereit, die auch der AMTANGEE Client nutzt, um Inhaltsobjekte erzeugen, bearbeiten oder löschen zu können. Wichtig: Das Rechtesystem von AMTANGEE lässt sich durch diesen vermeintlich „freien“ Zugriff auf die Ebene der Datenhaltung nicht aushebeln! Eine unsachgemäße Behandlung, z.B. in Form von Datenlöschungen, ist ausgeschlossen, da Erweiterungen nur im festgesetzten Rahmen des AMTANGEE Rechtesystems operieren können. Und zwar ausnahmslos.
Mise en place: die Entwicklungsumgebung
Unser folgendes Testprojekt demonstriert die Vorgehensweise bei der Programmierung eines eigenen Workflows. Dieser Workflow soll eingehende E-Mails überwachen und den Betreff modifizieren. Zur Umsetzung benötigen wir natürlich eine Entwicklungsumgebung. Unsere Wahl: Microsoft Visual Studio. Mit der Community Edition existiert sogar eine kostenfreie Variante.
Zur Entwicklung unseres eigenen Workflows starten wir in Visual Studio mit einem neuen Projekt und wählen als Vorlage „Klassenbibliothek“ aus. Wir entwickeln unser Testprojekt in C# – mit dem Ziel, am Ende eine DLL kompilieren zu können, die sich ohne viel Aufhebens in AMTANGEE integrieren lässt. Unser Projekt erhält den verheißungsvollen Namen „MeinTestPlugin“:
Visual Studio greift uns bei der Erzeugung hilfreich unter die Arme und legt bereits ein rudimentäres Code-Gerüst an, das wir nun an unsere Bedürfnisse anpassen werden. Zunächst benennen wir die Default-Klasse „Class1“ um und wählen einen gleichermaßen verheißungsvollen Namen: „Plugin“! Unser vorläufiger Zwischenstand:
using System; using System.Collections.Generic; using System.Text; namespace MeinTestPlugin { public class Plugin { } }
Um Zugriff auf das AMTANGEE SDK zu erhalten, müssen wir anschließend die benötigten Programmbibliotheken in Form von Verweisen in unser Projekt integrieren. Für die Entwicklung eines eigenen Workflows benötigen wir als Minimum zwei Dateien, „AMTANGEE.SDK.dll“ (im Programmverzeichnis des Clients) sowie „AMTANGEE.Workflow.Interfaces.DLL“ (im Installationsverzeichnis des Workflow-Dienstes). Um unseren Workflow später auch nutzen zu können, ist es zwingend erforderlich, dass der AMTANGEE Workflow-Dienst installiert ist. Nur wenn dieser Dienst läuft, können wir später unsere Erweiterung in der AMTANGEE Verwaltung aktivieren. Wir fügen unserem Projekt zunächst die benötigten Verweise hinzu:
Beide SDK-Bibliotheken werden anschließend in unser Projekt integriert:
Visual Studio zeigt die Bibliotheken jetzt im Projektmappen-Explorer als „Verweise“ an – und kennt nun zudem die Klassen und Methoden, die von jeder Bibliothek angeboten werden.
Die Autocomplete-Funktion von Visual Studio bietet uns das für unser Projekt notwendige Interface „AMTANGEE.Workflow.IMessages“ daher schon nach dem Eintippen weniger Zeichen an. Wenn wir anschließend mit der Maus über dem Klassennamen „Plugin“ ins Kontextmenu gehen, erhalten wir die Möglichkeit, das entsprechende Interface zu implementieren. Alle vom Interface vorgeschriebenen Methoden erscheinen dann als Funktionsrümpfe in unserer Plugin-Klasse:
using System; using System.Collections.Generic; using System.Text; using AMTANGEE.SDK.Messages; namespace MeinTestPlugin { public class Plugin : AMTANGEE.Workflow.IMessages { public void EmailReceived(Email email, DateTime dateTime) { throw new NotImplementedException(); } public void EmailSent(Email email, DateTime dateTime) { throw new NotImplementedException(); } public void AppointmentNotificationReceived(AppointmentNotification notification, DateTime dateTime) { throw new NotImplementedException(); } public void CallNotificationReceived(Call call, DateTime dateTime) { throw new NotImplementedException(); } public void FaxReceived(Fax fax, DateTime dateTime) { throw new NotImplementedException(); } public void FaxSent(Fax fax, DateTime dateTime) { throw new NotImplementedException(); } public void MessageChanged(Message message, DateTime dateTime) { throw new NotImplementedException(); } public void MessageDeleted(Guid guid, DateTime dateTime) { throw new NotImplementedException(); } public void NotificationReceived(Notification notification, DateTime dateTime) { throw new NotImplementedException(); } public void ShortMessageReceived(ShortMessage shortMessage, DateTime dateTime) { throw new NotImplementedException(); } } }
Als erstes Argument erhält jede dieser Methoden die Instanz einer Klasse, die uns als Inhaltstyp bereits geläufig sein dürfte, z.B. „Email“, „Call“ oder „Fax“. Die Methoden dieser Objekte können wir nun aufrufen, um manipulierend auf ein übergebenes Inhaltselement einzuwirken. Hauchen wir unserem neuen Workflow daher etwas Leben ein, indem wir die Methode „EmailReceived“ nach unseren Vorstellungen ausformulieren. Eine simple Modifikation des E-Mail-Betreffs eingehender Nachrichten könnte in etwa so aussehen:
using System; using System.Collections.Generic; using System.Text; using AMTANGEE.SDK.Messages; namespace MeinTestPlugin { public class Plugin : AMTANGEE.Workflow.IMessages { public void EmailReceived(Email email, DateTime dateTime) { if (!email.Subject.Contains("Checked:")) { email.Subject = "Checked:" + email.Subject; email.Save(); } } } /* [...] */ }
Wir können unseren angepassten Workflow nun kompilieren. Standardmäßig liegt die erzeugte DLL anschließend im bin-Verzeichnis unterhalb des von uns angelegten Projektordners.
Allerdings: AMTANGEE würde diese Datei niemals als Erweiterung akzeptieren, da sie keine digitale Signatur besitzt und ihre Einbindung folglich höchst fragwürdig wäre! Da sowohl Workflows als auch Module zwingend signiert werden müssen, sparen wir uns diesen letzten Schritt für den zweiten Teil des Beitrags auf. Teil 2 erläutert die Anwendungsgebiete von Modulen, die Signierung von Workflows und Modulen sowie ihre Integration in AMTANGEE.
AMTANGEE CRM erweitern: So wird's gemacht! (Teil 2: Module)
Weiterführende Links
Über diese Blog-Reihe
Die Reihe „/dev/inside/“ stellt in loser Folge Entwickler- und Administratorthemen vor, die für einen performanten Betrieb, die optimale Pflege der IT-Infrastruktur und die Funktionserweiterung von AMTANGEE relevant sind. „/dev/inside/“ richtet sich dabei explizit an IT-Profis, die über die erforderlichen Grundkenntnisse zum tieferen Verständnis der Beiträge verfügen. Die Anwendbarkeit bestimmter Inhalte kann der SDK-Vereinbarung unterliegen. Unser Support-Team hilft Ihnen bei diesbezüglichen Fragen gerne weiter.
