Posts Tagged: ‘Web Service’

Domino Gruppen Management mit Hilfe von Webservices und einer Vaadin Applikation

11. September 2016 Posted by Stephan Kopp

Letzte Woche habe ich geschrieben, dass ich mich mit dem Vaadin Framework ein wenig auseinandersetzen wollte. Mittlerweile bin ich schon so weit, dass ich meine erste Applikation für einen Kunden beinahe fertig habe. Das war nur eine kleine Applikation, die einige Daten aus einer Domino Applikation darstellt und einen Status per Webservice wieder zurück in die Applikation schreiben kann. Das war nichts großartiges, hat mir aber Gelegenheit gegeben, mich mit der Materie näher zu befassen. Das Ergebnis hat mich überzeugt, sodass wir auch gleich die nächste Anforderung über diesen Weg umsetzen werden.


Das Ziel

Wir arbeiten für einen Kunden, der momentan weg von Notes migriert (wie so viele). Da eine komplette Abschaltung jedoch vermutlich noch Jahre oder Jahrzehnte dauern wird, benötigt der Kunde eine Möglichkeit, die bislang vorhandene Lösung um Gruppen im Domino Adressbuch zu verwalten, durch eine Self Service Web Applikation zu ersetzen.

Die Idee

Um möglichst flexibel für zukünftige Szenarien zu sein, wollten wir die Applikation Zweigeteilt implementieren. Der erste Teil besteht aus einer Domino Applikation, die die eigentliche Verwaltung der Gruppen übernimmt. Also das eigentliche ändern der Gruppen im Adressbuch, Validierung, Rechte Verwaltung, etc. Diese Funktionalität soll per Webservice zur Verfügung gestellt werden um sie aus externen Systemen komfortabel bedienen zu können. Die Schnittstelle soll dabei aber einfach genug sein, um sie verwenden zu können, ohne zu viel Know-How über das Domino Backend haben zu müssen. Es sollen also z.B. automatisch verschachtelte Gruppen erzeugt werden, wenn wir an irgendwelche Grenzen laufen, ohne dass ich selbst an so etwas denken muss. Ebenso sollten die Gruppen Mitglieder anhand ihrer SMTP Adresse verwaltet werden können, ohne dass der Vollhierarchische Notes Name bekannt sein muss.

Für diese Schnittstelle entwickeln wir dann auch ein unabhängiges Web Frontend, um die Gruppen Verwaltung komplett in einem Browser vornehmen zu können. Hierfür verwenden wir eine Standalone Vaadin Applikation. Die Vaadin Applikation könnte man auch als OSGi Plugin auf den Domino Server installieren, aber die eigenständige Variante befreit uns von jeglicher Abhängigkeit von Server Versionen, Zugriffsrechten oder ähnlichem. Die Authentifizierung wird direkt gegen das Active Directory gemacht, da zukünftig nichtmehr jeder Mitarbeiter auch automatisch einen Notes Account erhalten wird. Die Funktionalität der Gruppenverwaltung (primär für Applikationen) muß aber jedem zur Verfügung stehen.

Ein ähnliches Konzept haben wir für unseren User Manager verwendet und der hat sich schon bei vielen Kunden bewährt.

Vorteile

Die MVC (Model View Controller) ähnliche Trennung von Funktion und Interface bietet einige Vorteile. Zukünftig könnte die Gruppenverwaltung auch über weitere Prozesse oder Workflow Systeme angesprochen werden, da wir über standardisierte Webservice Schnittstellen kommunizieren. Ebenso könnte das Web Frontend weitere Aufgaben übernehmen, in dem wir dort weitere Schnittstellen zur Verwaltung weiterer Systeme integrieren.

Die Umsetzung

Ich kann hier leider nicht die ganze Applikation veröffentlichen, werde aber versuchen im Verlauf der nächsten Tage/Wochen den Fortschritt, die Erfahrungen und einige Code Beispiele zu posten.


Filed under: Development, IBM Notes/Domino, Vaadin

Domino Gruppen Management mit Hilfe von Webservices und einer Vaadin Applikation

11. September 2016 Posted by Stephan Kopp

Letzte Woche habe ich geschrieben, dass ich mich mit dem Vaadin Framework ein wenig auseinandersetzen wollte. Mittlerweile bin ich schon so weit, dass ich meine erste Applikation für einen Kunden beinahe fertig habe. Das war nur eine kleine Applikation, die einige Daten aus einer Domino Applikation darstellt und einen Status per Webservice wieder zurück in die Applikation schreiben kann. Das war nichts großartiges, hat mir aber Gelegenheit gegeben, mich mit der Materie näher zu befassen. Das Ergebnis hat mich überzeugt, sodass wir auch gleich die nächste Anforderung über diesen Weg umsetzen werden.

Das Ziel

Wir arbeiten für einen Kunden, der momentan weg von Notes migriert (wie so viele). Da eine komplette Abschaltung jedoch vermutlich noch Jahre oder Jahrzehnte dauern wird, benötigt der Kunde eine Möglichkeit, die bislang vorhandene Lösung um Gruppen im Domino Adressbuch zu verwalten, durch eine Self Service Web Applikation zu ersetzen.

Die Idee

Um möglichst flexibel für zukünftige Szenarien zu sein, wollten wir die Applikation Zweigeteilt implementieren. Der erste Teil besteht aus einer Domino Applikation, die die eigentliche Verwaltung der Gruppen übernimmt. Also das eigentliche ändern der Gruppen im Adressbuch, Validierung, Rechte Verwaltung, etc. Diese Funktionalität soll per Webservice zur Verfügung gestellt werden um sie aus externen Systemen komfortabel bedienen zu können. Die Schnittstelle soll dabei aber einfach genug sein, um sie verwenden zu können, ohne zu viel Know-How über das Domino Backend haben zu müssen. Es sollen also z.B. automatisch verschachtelte Gruppen erzeugt werden, wenn wir an irgendwelche Grenzen laufen, ohne dass ich selbst an so etwas denken muss. Ebenso sollten die Gruppen Mitglieder anhand ihrer SMTP Adresse verwaltet werden können, ohne dass der Vollhierarchische Notes Name bekannt sein muss.

Für diese Schnittstelle entwickeln wir dann auch ein unabhängiges Web Frontend, um die Gruppen Verwaltung komplett in einem Browser vornehmen zu können. Hierfür verwenden wir eine Standalone Vaadin Applikation. Die Vaadin Applikation könnte man auch als OSGi Plugin auf den Domino Server installieren, aber die eigenständige Variante befreit uns von jeglicher Abhängigkeit von Server Versionen, Zugriffsrechten oder ähnlichem. Die Authentifizierung wird direkt gegen das Active Directory gemacht, da zukünftig nichtmehr jeder Mitarbeiter auch automatisch einen Notes Account erhalten wird. Die Funktionalität der Gruppenverwaltung (primär für Applikationen) muß aber jedem zur Verfügung stehen.

Ein ähnliches Konzept haben wir für unseren User Manager verwendet und der hat sich schon bei vielen Kunden bewährt.

Vorteile

Die MVC (Model View Controller) ähnliche Trennung von Funktion und Interface bietet einige Vorteile. Zukünftig könnte die Gruppenverwaltung auch über weitere Prozesse oder Workflow Systeme angesprochen werden, da wir über standardisierte Webservice Schnittstellen kommunizieren. Ebenso könnte das Web Frontend weitere Aufgaben übernehmen, in dem wir dort weitere Schnittstellen zur Verwaltung weiterer Systeme integrieren.

Die Umsetzung

Ich kann hier leider nicht die ganze Applikation veröffentlichen, werde aber versuchen im Verlauf der nächsten Tage/Wochen den Fortschritt, die Erfahrungen und einige Code Beispiele zu posten.

Ein Plädoyer für Lotus Notes (Teil 2): Das Lego Prinzip

21. März 2016 Posted by Stephan Kopp

…oder wie ich Java und Web Services durch Lotus Notes zu lieben gelernt habe.

Einige meiner Kollegen arbeiten schon seit längerem mit Webservices und haben unter anderem schon ein komplettes User Management für Domino und eine Kalender Schnittstelle für SAP entwickelt. Ich selbst fand das schon immer sehr interessant und zukunftsweisend, habe selbst aber noch nicht damit gearbeitet.

In den letzten Tagen habe ich mich jetzt endlich mal etwas intensiver mit dem Thema beschäftigt. Es ist faszinierend was man mit diesem Lego Prinzip alles erreichen und vereinfachen kann, wenn man es konsequent einsetzt.

Konkretes Fall Beispiel

Es geht um einen relativ großen Kunden, den ich hier nicht nennen möchte. Dieser Kunde migriert seit längerem weg von Lotus Notes. Mail wurde relativ schnell migriert und jetzt fehlt noch der ganze Rest.

Anfang des Monats haben wir dort die bereits erwähnten User Management Webservices live genommen um die Userverwaltung zu vereinfachen. Es werden also jetzt im Self Service Prinzip alle Notes IDs von den Anwendern selbst beantragt, weitere Daten aus dem internen Identity Management System nachgeladen und voll automatisch angelegt. Ein ähnlicher Prozess existiert für die Anlage von Outlook Accounts und Mailboxen, das ganze läuft aber parallel und wurde nicht in einen Prozess integriert. Soweit so gut, alles läuft nahezu perfekt, wir haben bis heute schon fast 200 User accounts in knapp 2 1/2 Wochen über den Prozess angelegt.

Das Problem

Über ein Problem sind wir jedoch gestolpert: Wir erzeugen die Notes IDs, legen sie in den ID-Vault und vergeben dabei ein Initial Passwort. Dieses Passwort senden wir dem User per Mail zu. Das sollte eigentlich kein Problem sein, da das Mail System ja Outlook ist und die User damit an die Passwörter ran kommen (sollte). Jedoch hat sich herausgestellt, dass das Anlegen der Outlook Postfächer in einzelnen Fällen durchaus etwas länger dauern kann und wir deshalb die Passwörter nicht einfach verschicken können sobald wir fertig sind. Ein einfacher Zeitversatz von x Stunden war auch wenig hilfreich, da es nicht nachvollziehbar war, wie lange das Anlegen auf Exchange Seite dauert.

Der Lösungsansatz

Im Laufe des Migrationsprojektes habe ich schon für verschiedene Applikationen per Java Code Verbindungen in Richtung Active Directory und Exchange programmiert. Deshalb wollte ich in unseren User Anlage Prozess einen Workflow Schritt einbauen, der überprüft ob das Outlook Postfach erfolgreich angelegt wurde und wir das Passwort verschicken können. Ich hätte das jetzt natürlich wieder per Java direkt in die Notes Applikation bauen können, es ist aber abzusehen dass wir diese und ähnliche Funktionen in Zukunft noch an vielen Stellen benötigen werden. Deshalb war es eine gute Gelegenheit das Ganze über einen Webservice zu implementieren um es auch für zukünftige Anwendungsfälle ohne große Programmierarbeit zur Verfügung zu stellen.

Was macht den Webservice Ansatz in diesem Beispiel besser?

Natürlich kann ich meinen Code soweit wiederverwendbar machen, dass ich ihn recht einfach in unterschiedliche Applikationen integrieren kann. Es ist aber immer nur Code, den ich wieder verwende. Webservices gehen hier einen Schritt weiter, ich verwende wirklich einen Service, der sehr viel mehr als nur Code zur Verfügung stellt. In unserem konkreten Beispiel greifen wir nicht auf das interne AD, sondern auf das des externen Betreibers der Exchange Umgebung zu. Hierfür benötigen wir Zugangsdaten, Firewall Freischaltungen und weitere Details wie die richtige Searchbase um die User Accounts zu finden. Für jede Applikation muss ich also die Firewall ändern lassen und die Möglichkeit schaffen Zugangsdaten und Optionen sicher zu hinterlegen. Das ist nicht wirklich praktikabel.

Der Webservice Ansatz bietet eine Möglichkeit diesen Zugriff komplett als Service anzubieten. Ich muss also nichts wissen über die weiteren Abhängigkeiten wie Firewall, Zugangsdaten, welche Searchbase ich benötige, etc. Ich greife von meiner Applikation nur auf einen Webservice zu, übergebe als Parameter eine E-Mail Adresse und bekomme ein Ja oder Nein zurück, ob das Outlook Postfach angelegt ist oder eben nicht. Diesen Webservice kann ich dann wirklich sehr einfach in alle Applikationen integrieren, sei es nun eine Notes Applikation oder auch externe Applikationen. Den Zugriff auf meinen Webservice und damit auf die dahinter liegenden Daten kann ich schnell und einfach anhand der Domino ACL steuern und muss nicht die Zugangsdaten an x Stellen hinterlegen.

Ganz konkret sieht eine Integration des Webservices in meinen LotusScript Code genau so aus:

Dim webservice As New ActiveDirectoryWebservice
Dim isExchangeEnabled As Boolean
isExchangeEnabled = webservice.isExchangeEnabled("email@company.com")

Das ist sehr einfach in jeder beliebigen Applikation einzusetzen. Falls es Bug fixes oder Änderungen gibt, muss ich das nur im Webservice machen und nicht in jeder einzelnen Applikation die diesen nutzt.

Java und Webservices in Lotus Notes Applikationen

Ich arbeite schon länger mit Java in Notes Applikationen. Mir gefällt hier vor allem die optimale Nutzung der jeweiligen Vorteile. Java bietet eine Unmenge von Möglichkeiten um in Notes Applikationen sinnvoll zu arbeiten, aber vor allem auch recht einfach auf externe Systeme und Daten zuzugreifen. An Notes Applikationen gefällt mir die Verkapselung in eine NSF und die einfache Datenstruktur und das vorhandene Security Modell. Beides Zusammen bietet viele Vorteile. Ich entwickle komplexe Notes Applikationen und Java Code, aber trotzdem genügt es die NSF zu sichern oder auf einen anderen Server zu kopieren.

Das Manko das ich allerdings habe, ist die schlechte Verbindung von Java und LotusScript. Ja, ich kann Code der jeweils anderen Welt ausführen und integrieren, aber das ist immer sehr speziell und auch Fehler anfällig. Viel besser gefällt mir der Gedanke der Micro Services, also einzelne Teile der eigenen Applikation als Service anzubieten und diesen dann entweder innerhalb der Applikation oder auch von Außen zu verwenden. So kann ich z.B. einzelne Funktionen in Java oder LotusScript entwickeln und als Webservice miteinander verbinden.

Dadurch entsteht das eingangs erwähnte Lego Prinzip. Ich habe viele kleine Teile, die ich schnell und einfach zusammen fügen kann. Zunächst macht es natürlich etwas mehr Arbeit diesen Service Gedanken konsequent umzusetzen, aber langfristig bietet es enorme Vorteile. Die einzelnen Applikationen werden unabhängiger und einfacher zu pflegen und anpassbarer. Kommt man z.B. irgendwann an einen Punkt, an dem man für einzelne Applikationen die Plattform wechseln möchte (oder muss), bietet das enorme Vorteile. Einzelne Legosteine werden auf neue Systeme portiert und für die restlichen ist das nichts anderes als ein Wechsel der URL des Webservices, oder nichtmal das wenn man mit redirect URLs oder ähnlichem arbeitet.


Filed under: IBM Notes/Domino

Freies E-book: Development Tips and Best Practices for XPages

25. September 2015 Posted by Bernd Hort

socialbizUG_logo.jpg

Die SocialBiz User Group hat mehrere Texte zum Thema XPages in einem Free E-book: Development Tips and Best Practices for XPages zusammengestellt.

Nun ratet einmal, wessen Präsentation von der IBM ConnectED 2015 Teil dieser Zusammenstellung ist?

IBM ConnectED 2015: BP 108 - Be Open - Use Web Services and REST in XPages Applications


LotusScript Web Services and NullPointerException

7. August 2015 Posted by Bernd Hort

DominoDesigner_90x90.png

Recently I worked on a demo application for a customer to show how to use Web Service Consumer in LotusScript. At one point I got a java.lang.NullPointerException error. It took me quite some time to figure out the reason for this error. So this blog post should help anyone how might run in the same problem. Because frankly the solution was really simple once I had found it.

I give you the summary first and the full technical explanation later in this blog post. So even if you are not interested in the details the main point to take away is:

LotusScript Web Services Consumer and Provider use internally Java and Java is case sensitive. If you do not obey this you might loose some hours of your life time chasing an error where no error is.

Here are the technical details.


One part of the demo were the different styles to use to generate the WSDL file from a Web Service Provider. There is a great article from IBM developerWorks Which style of WSDL should I use? on this topic. Highly recommended!

To be able to show the differences between RPC/encoded and Document/literal style I implemented two different Web Service Providers. Both providers had the same identical LotusScript code.

Then I implemented two Web Service Consumers just by importing the WSDL file from the previous generated Web Service Providers. Here are the two methods from the Web Service Consumers.

Web Service Consumer calling a RPC/encoded Web Service Provider
Web-Service-Provider-RPC-encoded-Settings.png

Function checkout_status(auftragnr As String) As String
  If Not IsDebugMode Then On Error Goto errorHandler
  On Error lsERR_NOTES_WSENGINE_UNINIT_METHOD_ARG Goto wsErrorHandler
  On Error lsERR_NOTES_WSENGINE_NOTINIT Goto wsErrorHandler
  On Error lsERR_NOTES_WSENGINE_ERROR Goto wsErrorHandler
  On Error lsERR_NOTES_WSENGINE_METHOD_ERROR Goto wsErrorHandler
  On Error lsERR_NOTES_WSENGINE_METHOD_FAULT Goto wsErrorHandler
  
  Let checkout_status = Service.Invoke("checkout_status", auftragnr)
  
  Exit Function
  
errorHandler:
  If HandleErrorWithContext(CreateErrorContext(Nothing,|auftragnr: "| & auftragnr & |"| )) = RESUME_NEXT_LINE Then Resume Next
  Call RethrowError()
  Exit Function
  
wsErrorHandler:
  If HandleErrorWithContext(CreateErrorContext(Nothing,|auftragnr: "| & auftragnr & |"| )) = RESUME_NEXT_LINE Then Resume Next
  Call CreateWebServiceLogEntry(Me, |auftragnr: "| & auftragnr & |"|, Nothing)
  Call RethrowError()
End Function

Web Service Consumer calling a Document/literal Web Service Provider
Web-Service-Provider-RPC-encoded-Settings.png

Function checkout_status(auftragnr As String) As String
  If Not IsDebugMode Then On Error Goto errorHandler
  On Error lsERR_NOTES_WSENGINE_UNINIT_METHOD_ARG Goto wsErrorHandler
  On Error lsERR_NOTES_WSENGINE_NOTINIT Goto wsErrorHandler
  On Error lsERR_NOTES_WSENGINE_ERROR Goto wsErrorHandler
  On Error lsERR_NOTES_WSENGINE_METHOD_ERROR Goto wsErrorHandler
  On Error lsERR_NOTES_WSENGINE_METHOD_FAULT Goto wsErrorHandler
  
  Let checkout_status = Service.Invoke("CHECKOUT_STATUS", auftragnr)
  
  Exit Function
  
errorHandler:
  If HandleErrorWithContext(CreateErrorContext(Nothing,|auftragnr: "| & auftragnr & |"| )) = RESUME_NEXT_LINE Then Resume Next
  Call RethrowError()
  Exit Function
  
wsErrorHandler:
  If HandleErrorWithContext(CreateErrorContext(Nothing,|auftragnr: "| & auftragnr & |"| )) = RESUME_NEXT_LINE Then Resume Next
  Call CreateWebServiceLogEntry(Me, |auftragnr: "| & auftragnr & |"|, Nothing)
  Call RethrowError()
End Function

Can you spot the difference? I guess it is easier after giving you the solution.

In the Document/literal version the line for actually calling the Web Service must be
Let CHECKOUT_STATUS = Service.Invoke("CHECKOUT_STATUS", auftragnr)
with capital CHECKOUT_STATUS.

I found out because I took the original generated code and enhanced it with some error handling. Since there could be not code without properly error handling. This is specially true for calling Web Service.

Since I'm a lazy programmer I copied the code from the one Web Service Consumer to the next not looking at the case. I was very confusing that the first Web Service Consumer worked and the second one returned a java.lang.NullPointerException.

After checking for all kind of reasons I finally started again with a new Web Service Consumer and then found the difference in the case.

The reason behind is the internal use of Java. While calling Service.Invoke in the background the Java Reflection API is used to find the corresponding method to call. Those two different WSDL styles lead to two different method names: checkout_status and CHECKOUT_STATUS. In LotusScript the case of a method name makes no difference. In Java it can mean you can spend hours looking for an error.

By the way if I had used Java in the first place to program the Web Service Consumer (or Provider) I would not have had this problem.

IBM ConnectED 2015: BP 108 – Be Open – Use Web Services and REST in XPages Applications

28. Januar 2015 Posted by Bernd Hort

IBM ConnectED 2015

Before I head to the party I will keep my promise and post the presentation and the sample database.

BP 108 - Be Open - Use Web Services and REST in XPages Applications

Thank you to everyone who joined my session.


Managing Domino Users with PowerShell

5. Dezember 2014 Posted by Stephan Kopp

Some of my colleagues created a really nice Domino Application to manage users with browsers using XPages.

With their application, they provide many useful functions also as web services.

The nice “side effect” is that these web services can be used from any other applicable system.

For example you can use PowerShell to create Domino Users with a few lines of code:

$wsdl = "http://dominoserver/service.nsf/DominoUserManager?wsdl"
$username = "testuser"
$passwd = "passwort" | convertto-securestring -AsPlainText -Force    
#Password should be stored in the script only for testing!
$cred = new-object -typename System.Management.Automation.PSCredential -argumentlist $username, $passwd

$DUM = New-WebServiceProxy -Uri $wsdl -Credential $cred -Class 'Proxy' -Namespace "DominoUserManagerService"
$user = New-Object DominoUserManagerService.REGISTRATIONREQUESTDATA
$user.FIRSTNAME = "Stephan"
$user.LASTNAME = "Kopp"
$user.SHORTNAME = "skopp"
$user.MIDDLEINITIAL = ""
$user.CERTIFIER = "/ACME/COM"
$user.INTERNETADDRESS = "skopp@acme.com"
$user.PASSWORD = "myNewPassword"
$user.QUOTASIZE = '0'
$user.QUOTAWARNING = '0'
$user.MAILACCESS = '2'
$user.IDVALIDITY = '-1'
$reply = $DUM.PROCESSUSERREGISTRATION($user)

We can’t make all this open source, but if someone is interested and wants more information, please contact me!


Filed under: IBM Notes/Domino

IBM Connect 2014: BP 206 – Be Open – Use Web Services and REST in XPages Applications

30. Januar 2014 Posted by Bernd Hort

IBM Connect 2014

Sitting in the closing session of IBM Connect 2014. So there is only one more thing to do before enjoying the show. Keeping my promise to upload the presentation and the sample application from my session.

BP 206 - Be Open - Use Web Services and REST in XPages Applications