Im ersten Teil dieses Artikels wurde die Ansicht von laufenden Prozessinstanzen beschrieben. In diesem zweiten Teil gehe ich auf die Ansicht abgeschlossener Prozessinstanzen, den log-Viewer und Rollen ein, welche für die Prozessadministration notwendig sind.

Abgeschlossene Prozessinstanzen anzeigen

Manchmal ist es auch hilfreich, nicht nur fehlerhaften Vorgängen nachzuspüren, sondern auch erfolgreiche Prozesse anzuzeigen: wann wurde ein Prozess abgeschlossen, welchen Verlauf nahm der Prozess oder wann fand ein bestimmter Prozessschritt statt? Standardmässig zeigt die Ansicht ‚Prozesse verwalten‘ nur fehlerhafte oder aktuell laufende Prozesse an. Erweitert man die Suchoptionen jedoch mittels des unscheinbaren Links ‚Erweitert‘, so lassen sich auch Prozesse in allen anderen Stati anzeigen. Es stehen dann ebenfalls die im 1.Teil beschriebenen Darstellungsoptionen der Prozesshistorie zur Verfügung. So lässt sich minutiös der Ablauf eines Prozesses nachvollziehen.

Einträge im Log Viewer

Via ‚Problemmanagement‘ -> ‚Protokolle und Traces‘ gelangt man zum Log Viewer. Dieser zeigt sämtliche Logeinträge aller aktivierter Komponenten und vom SAP CE System selbst. Da die Darstellung chronologisch erfolgt, ist sie für die Nachvollziehbarkeit eines Prozessablaufes unübersichtlich. Jedoch kann sie gerade für die Fehlerursachensuche wertvolle Details und Zusammenhänge liefern. Hier werden die programmatischen Logeinträge des SAP-Loggers angezeigt. Der Log-Level einzelner Java-Klassen oder Packages wird in der Protokollkonfiguration gesetzt: ‚Problemmanagement‘ -> ‚Protokolle und Traces‘ -> im Feld ‚Anzeigen:‘ den Wert ‚Trace-Orte‘ auswählen. Anschliessend kann im Hierarchiebaum das gewünschte Package oder die Klasse ausgewählte werden und die Gewichtung (Log-Level) gesetzt werden. Mittels Button ‚Zum Teilbaum kopieren‘ wird die gewählte Gewichtung auf alle darunterliegenden Packages und Klassen kopiert.

Berechtigungen

Nicht nur der Zugang zu den Ansichten im NWA, welche eine Prozessüberwachung ermöglichen, sondern auch die Durchführbarkeit von Funktionalitäten der verschiedenen Ansichten werden über Rollen gesteuert. Hier ein Kurzüberblick über die Rollen und deren Berechtigungen:

• SAP_BPM_SuperDisplay: berechtigt zur Anzeige aller Administrationsseiten von Prozessen und Aufgaben im NWA
• SAP_BPM_SuperAdmin: berechtigt zur Anzeige aller Administrationsseiten von Prozessen und Aufgaben im NWA (wie SAP_BPM_SuperDisplay) und ermöglicht das Bearbeiten von Prozessen und Aufgaben und Starten von Prozessen
• NWA_READONLY: berechtigt zur Anzeige aller Seiten im NWA
• NWA_SUPERADMIN: berechtigt zur Anzeige (wie NWA_READONLY) und zum Management aller Seiten im NWA (aber nicht zum Starten von Prozessen)

Gerade während der Entwicklung von Applikationen mit SAP BPM als auch im Betrieb der produktiven Applikation ist es unerlässlich, die Business Prozesse beobachten zu können. Nur so lässt sich ein auftretender Fehler identifizieren, dessen Ursache herausfinden und überhaupt der korrekte Verlauf eines Prozesses feststellen. SAP bietet mit dem NetWeaver Administrator (NWA) ein weit entwickeltes Werkzeug, um die SAP Business Prozesse detailliert beobachten zu können. Dieser Beitrag bezieht sich auf die NWA Version 7.2.

Im hier vorliegenden ersten Teil gehe ich auf die Ansicht von laufenden Prozessinstanzen ein. Im nachfolgenden, zweiten Teil wird die Ansicht abgeschlossener Prozessinstanzen, der log-Viewer und Rollen, welche für die Prozessadministration notwendig sind, beschrieben.

Laufende Prozessinstanzen und Instanzen im Fehlerstatus anzeigen

Um alle Prozessinstanzen eines Prozesses aufzulisten: Entweder ‚Operationsmanagement‘ -> ‚Prozesse und Aufgaben‘ -> ‚Prozesse verwalten‘ oder ‚Konfigurationsmanagement‘ -> ‚Prozesse und Aufgaben‘ -> ‚Prozess-Repository‘: BPM-Komponente auswählen -> unter Fenster ‚Details von Komponente …‘ : ‚Prozesse und Aufgaben‘ den Prozess anklicken. Nun werden alle (aktuell laufende, abgeschlossene, abgebrochene und im Fehlerstatus) Prozessinstanzen aufgelistet. Im Tab ‚Historie‘ (am besten ‚Anzeigen: Mittel‘ selektieren) werden alle durchgeführten Anwendungsschritte gelistet, so dass sich nachvollziehen lässt, welche WebService-Aufrufe durch das BPM und in welcher Reihenfolge diese durchgeführt wurden.

Mittels ‚Anzeigen: Erweitert‘ wird auch angezeigt, ob und wann Veränderungen an welchen Datenobjekten stattgefunden hat. Im Tab ‚Kontextdaten‘ wird der Wert aller Datenobjekte angezeigt. Wurde ein Datenobjekt während des Prozessablaufes (mehrfach) aktualisiert, so wird dieses Datenobjekt entsprechend seiner Anzahl Aktualisierungen mehrfach aufgelistet und chronologisch absteigend sortiert. Wird im Prozess z.B. ein Datenobjekt (Tracer) implementiert, welches bei jedem Prozessschritt aktualisiert wird und lediglich den aktuellen Prozessschritt kennzeichnet, lässt sich hier sehr schnell und einfach feststellen, in welchem aktuellen Prozessschritt der Prozess sich befindet und so kann der durchgeführte Prozessverlauf sehr einfach nachvollzogen werden.

Natürlich lässt sich der Prozessverlauf auch im Tab ‚Historie‘ anhand der durchgeführten Anwendungsschritte erkennen. Ein solches Tracer-Datenobjekt erscheint mir aber einfacher und schneller erkennbar.

Bei Prozessinstanzen, bei denen im Prozessverlauf ein Fehler auftrat und sie sich somit im Fehlerstatus befinden, werden im Tab ‚Fehlerprotokoll‘ die Error-Log Einträge für diese Instanz chronologisch gelistet. Diese Ansicht entspricht zwar den Error-Log Einträgen in der Log-Viewer Ansicht (in ersterer Ansicht ist die Zeilenanzahl begrenzt, die dargestellten Informationen dürften aber in jedem Fall ausreichen), sie werden hier aber übersichtlich in Abhängigkeit ihres Contextes dargestellt. Wenn z.B. ein WebService-Aufruf durch eine Prozessaktivität wegen erfolglosen Verbindungsaufbaus drei Mal durchgeführt wird, so werden alle dazugehörigen Fehlerlogs in diese drei Versuche gegliedert. Es entfällt das mühsame Filtern und Zuordnen der einzelnen Logeinträge zu einem Vorgang wie es in der Log-Viewer-Ansicht notwendig ist. Zwar wird im Fehlerprotokoll kein Datum und Uhrzeit angegeben. Aber diese dürfte immer dem zuletzt erfolgten Ereignis in der Historie der Prozessinstanz entsprechen.

Kann die Ursache eines Prozessfehlers behoben werden, kann ein angehaltener Prozess mittels Button ‚Actions‘ -> ‚Wiederaufnehmen‘ fortgeführt werden. Dabei wird der vormals fehlerhafte Prozessschritt erneut ausgeführt. Ebenso kann hier mittels Aktion ‚Abbrechen‘ ein Prozess abgebrochen werden, dessen Fehlerursache nicht behoben werden kann und der Prozess somit niemals beendet werden kann.

Ist der Tab ‚Historie‘ aktiviert, so wird der Link ‚Protokolle des Geschäftslebenszyklus anzeigen‘ im Tab dargestellt. Dadurch gelangt man auf die Log-Anzeige ‚Geschäftsprotokolle‘, welche detailliertere Angaben zu den Einträgen im Tab ‚Historie‘ darstellt. So kann man hier z.B. die Werte der Aufrufparameter und Rückgabeparameter von WebService-Aufrufen durch das BPM sehen, Werte von eingehenden Nachrichten oder auch den neuen Wert bei Aktualisierung von Datenobjekten. Via der Auswahlliste des anzuzeigenden Zeitraumes sind nur Einträge bis maximal der letzten 7 Tage darstellbar. Allerdings kann mittels des einblendbaren Query-Bereiches ein beliebiger Zeitraum eingegeben werden, nach dem die Einträge nach dem Anlegezeitstempel gefiltert werden können.

Im nachfolgenden, zweiten Teil wird die Ansicht abgeschlossener Prozessinstanzen, der log-Viewer und Rollen, welche für die Prozessadministration notwendig sind, beschrieben.

Gibt es nicht einen einfacheren Weg, um all diese Fragen ohne grossen Aufwand zu beantworten? Wäre es nicht sinnvoll ein Werkzeug zu haben, das die meisten alltäglichen Entwickleraufgaben automatisiert und die allgemein verwendeten Java-Standards integriert? Es scheint, dass im Java-Bereich Spring (www.springsource.org) der erste Kandidat ist, welcher uns eine universelle Lösung anbieten kann. Sie heisst Spring Roo (www.springsource.org/spring-roo) und ich will es ihnen in diesem Blog ausführlich beschreiben.

Spring Roo’s Ziel ist es “grundlegend und nachhaltig die Produktivität der Java-Entwickler zu verbessern ohne die technische Integrität und Flexibilität zu beeinträchtigen” und ermöglicht eine schnelle Entwicklung für Java EE Anwendungen.

Spring Roo ist ein Software-Werkzeug zur Generierung von Java Web Anwedungen mit CRUD-Funktionalität. Dies bedeuet, der Anwender kann die Entitäten erstellen, lesen, finden, auflisten, aktualisieren und entfernen. Spring Roo bietet uns mehrere technologische Optionen, wie:

• verschiedene Anbieter für die JPA-basierte Persistenz (z.B. Hibernate oder OpenJPA)
• Spring MVC-Controller
• Frontend basierend auf JSPs, JSP 2.0, Google Web Toolkit (GWT) oder Flex

Wenn Sie z.B. Ihren Persistenz-Provider wechseln möchten, so können Sie dies ganz einfach machen. Oder wenn Sie z.B. einen JSON-Ausgang zu Ihren Controllern oder eine neue Service-Ebene hinzufügen möchten, so können Sie dies mit einem geringem Aufwand und ein paar wenigen Befehlen erledigen. Alles was von Roo generiert wird, hat eine vernünftige Standard-Konfiguration, so dass nur sehr wenig Konfigurationsaufwand nötig ist. Spring Roo ist stark abhängig von den Spring Kernkomponenten und AspectJ’s Inter-Deklaration Features (welche ich in den nächsten Blog-Beiträgen detaillierter beschreiben werde).

Das Werkzeugset von Spring Roo kann mit sehr wenig Konfiguration-Overhead sowohl den Java-Code generieren als auch eine Menge von Standard-Modulen in einem Java-EE-Projekt integrieren, so dass Sie immer die Wahl haben, alles was Sie brauchen, zu ändern. So können Sie mit ein paar einfachen Befehlen die Technologien wie Mailing, Batchjobs, JSON für REST oder Solr für die Volltextsuche integrieren.

Sie denken, Spring Roo klingt zu schön, um wahr zu sein? Ich möchte Ihnen an einem einfachen Bespiel zeigen, dass es wirklich funktioniert!

Roo selbst ist eine Java-Anwendung und kann ohne zusätzliche Hilfsmittel verwendet werden. Sobald Sie mit Ihrem Roo-Projekt bereit sind, können Sie mit einem Roo-Befehl ein Java-Projekt generieren. Ab diesem Zeitpunkt können Sie das Projekt normal in Ihrer Entwicklungsumgebung (z.B. Eclipse) verwenden. Der bequemere Weg ist jedoch, Roo als ein Eclipse-Plugin zu verwenden oder eine spezielle und konstenlose Eclipse-Version von Spring (STS), welche das Roo-Plugin perfekt integriert, herunterzuladen. Ich selbst würde STS empfehlen und das folgende Beispiel wurde auch mit STS erstellt. Roo benutzt eine Kommandozeile (Shell) Schnittstelle mit leicht zu verstehenden Befehlen. Lassen Sie uns also die Spring Roo Konsole starten. Mit dem Befehl “hint”, erhalten Sie jederzeit Tipps.

Wir haben bereits mit Hilfe von STS ein Projekt erstellt. Normalerweise kann man Roo von der Kommandozeile starten und folgende Befehle ausführen:

roo> project --topLevelPackage ch.emineo.showcase

roo> perform eclipse

An dieser Stelle haben wir ein Eclipse Projekt mit bereits konfiguriertem Maven, welches alle Bibliothek-Abhängigkeiten pflegt. Jetzt werden wir die Java Persistenz mit Hibernate als Provider und MySQL als Datenbank hinzufügen (vergessen Sie nicht, dass Sie TAB oder STRG-SPACE jederzeit drücken können, um die Auto-Vervollständigung zu bekommen):

roo> persistence setup --database MYSQL --provider HIBERNATE

Dieser Befehl erzeugt alle benötigten Konfigurationsdateien (und Abhängigkeiten) und füllt diese mit Standardwerten.

Lassen Sie uns jetzt zwei Entitäten (Unternehmen und Mitarbeiter) mit ein paar Feldern erstellen, die Beziehung zwischen diesen beiden (Unternehmen können mehrere Mitarbeiter haben) definieren, Beans-Validierung hinzufügen und JUnit-Tests generieren. Um dies zu erledigen brauchen wir wirklich ganz wenige Befehle:

roo> entity --class ~.domain.Company –testAutomatically

~.domain.Company roo> field string --fieldName name --notNull --sizeMin 2

~.domain.Company roo> entity --class ~.domain.Employee –testAutomatically

~.domain.Employee roo> field string --fieldName lastname --notNull --sizeMax 40

~.domain.Employee roo> field reference --fieldName company --type Company

~.domain.Employee roo> focus --class ch.emineo.showcase.domain.Company

~.domain.Company roo> field set --fieldName employees --type Employee

Das war’s. Nach der Erstellung des Datenmodells können wir jetzt die Integrations-Tests mit der MySQL-Datenbank durch den Befehl “perform tests” direkt von Roo ausführen lassen.

Die Entitäten, die gerade generiert wurden, bieten eine grundlegende Funktionalität (Erstellen, Suchen, Löschen, etc.). Aber was sollen wir machen, wenn wir einen Mitarbeiter aufgrund seines Nachnamen und für das spezifische Unternehmen suchen möchten? Kein Problem, es steht für uns eine Liste mit bereits generierten “Finders” (die schlussendlich mit Spring Data http://www.springsource.org/spring-data generiert werden) zur Verfügung:

~.domain.Employee roo> finder list --filter lastname

~.domain.Employee roo> finder add --finderName findEmployeesByLastnameLikeAndCompany

Jetzt können wir die neu generierte Methode einfach in unserer Anwendung benutzen:

Employee.findEmployeesByLastnameLikeAndCompany(lastname, company)

Trotz breiter Funktionalität (wie suchen, ändern, löschen, toString, etc.), welche für uns zur Verfügung steht, sieht unsere Mitarbeiter-Klasse immer noch ordentlich und sehr übersichtlich aus (die Zauberei von AspectJ):

@RooJavaBean

@RooToString

@RooEntity(finders = { "findEmployeesByLastnameLikeAndCompany" })

public class Employee {

     @NotNull

    @Size(max = 40)

    private String lastname;

    @ManyToOne

    private Company company;

}

Nun, unser Datenmodell ist fertig und wir wollen eine Web-Ebene (Frontend) zu unserer Anwendung hinzufügen:

~.domain.Company roo> web mvc setup 

~.domain.Company roo> web mvc all --package ~.web

Dieser Befehl scannt unser Projekt nach Entitäten und erstellt automatisch die MVC-Controllers (mit REST-Muster) mit den entsprechenden JSP-Seiten, Tiles, CSS-Dateien, Grafiken und Themes. Von nun an können wir unsere Anwendung durch den Maven-Befehl im Tomcat deployen und danach gleich testen:

~.web roo> perform command --mavenCommand tomcat:run

Unser Frontend sieht jetzt wie folgt aus:

Vielleicht möchten wir einige andere Funktionen hinzufügen? Eine Sicherheits-Ebene? Lassen Sie uns die grundlegende Benutzer-Authentifizierung für unser Frontend integrieren:

~.web roo> security setup

Wollen Sie die Frontend-Seiten automatisch testen? Kein Problem, wir können mit Hilfe von Selenium (ein bekanntes Framework für Webanwendungen – http://seleniumhq.org) die Tests mit dem Firefox-Browser ausführen:

~.web roo> selenium test --controller ~.web.CompanyController

Das wäre alles für heute. Wie Sie sehen können, innerhalb weniger Minuten haben wir fast die vollständige Web-Anwendung mit JPA, Hibernate, MySQL, JSP mit Tiles, CSS, Security, Backend und Frontend Tests umgesetzt. Roo bietet aber noch viel mehr Möglichkeiten, welche wir hier gar nicht erwähnt haben. Was noch sehr interresant ist, wir können zum Beispiel den Datenbank-Anbieter in einigen Sekunden mit einem einzigen Befehl wechseln. Das Beste an Roo ist, dass man die Anwendung weiter in seiner Entwicklungsumgebung entwickeln kann, ohne Roo zu verwenden, was dazu führt, dass man (wie von Spring beworben) schneller entwickeln kann, ohne die technische Integrität und Flexibilität zu beeinträchtigen.

Stolperfallen? Wie bei vielen neuen Technologien gibt es wohl Probleme, die am Anfang schwierig werden. Roo ist ein ziemlich neues Werkzeug (2009) und hat noch einige Bugs. Wenn wir Spring Roo intern mehr und mehr benutzen werden, finden wir sicher einige Bugs und wir können Ihnen die Schwierigkeiten des Roo in einem weiteren Blog mitteilen. Spring Roo ist aber bereits zu diesem Zeitpunkt ein wertvolles Tool, welches uns Entwickler sicherlich bei unseren alltäglichen Problemen (die fast bei jedem neuen Projekt auftreten) helfen kann.

Haben Sie Erfahrungen mit anderen RAD Frameworks / Werkzeuge wie Grails oder Ruby on Rails und würden diese gerne mitteilen? Bitte tun Sie dies in den Kommentaren unten!

An einem EMR Workshop für Partner in Walldorf letzte Woche hat die SAP die Applikation und den aktuellen Stand der Entwicklung näher vorgestellt –  was Anlass dazu gibt dies hier kurz vorzustellen.

Fokussierung auf den Mensch und seine Bedürfnisse und Ansprüche

Die Bedienung der App ist intuitiv und zu 100% auf die Bedürfnisse der Benutzer ausgerichtet. Das ist insbesondere in Bezug auf die Tatsache, dass es sich um eine mobile Anwendung handelt, welche bestehende Daten und Funktionen von SAP Backend Systemen zur Verfügung stellt, keine Selbstverständlichkeit! Entgegen der klassischen Fokussierung auf Systeme und Prozesse, wo es im Wesentlichen darum geht, die bestehenden Funktionen und Daten einfach mobil bereitzustellen, wurde bei der Entwicklung der EMR konsequent auf die Bedürfnisse des Benutzers eingegangen. Die EMR App wurde von Personen designed, welche keine Kenntnisse der bestehenden Funktionen und Systeme hatten, sondern sich ausschliesslich zusammen mit Ärzten und Pflege Personen der Analyse der realen Prozessen und der Aufnahme der Bedürfnisse widmeten. Der zentrale Grundsatz bei der Entwicklung war der Leitsatz „User experience is everything“ und dieser wurde konsequent angewendet was sich im Resultat eindeutig zeigt.

Ausrichtung auf Offenheit und Erweiterbarkeit

Ein weiterer wesentlicher Aspekt der EMR App (und vielleicht auch eher untypisch für eine SAP basierte mobile Lösung) ist die Ausrichtung auf Offenheit und Erweiterbarkeit. Die App kommuniziert ausschliesslich mit einer Middleware, dem SAP EMR Mobile Server. An diesen können Backend Systeme über sog. Konnektoren angebunden werden, welche individuell in die bestehenden Systeme integriert werden. Damit wird die Möglichkeit gegeben, für die mobile EMR Anwendung beliebige Backend Systeme zu nutzen, sowohl SAP wie auch Non-SAP System.

Darüber hinaus wurde die Möglichkeit geschaffen, über sog. „Facetten“ eigene Informations- und Anwendungskomponenten zum Patienten in die App einzubinden. Dadurch können bestehende Applikationen von Drittanbietern einfach eingebunden oder neue Facetten für bestehende Lösungen implementiert werden. Die SAP versteht ihre EMR ganz klar als eine Art „Framework“ für die Implementierung von mobilen Lösungen für das Gesundheitswesen, welches mit vorgefertigten Applikationskomponenten ausgeliefert wird, aber individuell auf die Bedürfnisse und vorhandenen Systeme ausgerichtet werden kann.

Rasche Implementierungszeit, sofern der Standard genutzt wird

Im Zusammenspiel mit dem SAP eigenen KIS System (IS-H*MED) kann die Lösung fast zu 100% „out-of-the-box“ genutzt werden. Einzig für die Darstellung von Röntgenbildern benötigt es eine Integration in ein bestehendes PACS. Für letzteres gibt es vorgefertigte Schnittstellen, welche bei Kunden auch bereits im Einsatz sind. Bei der Charité Berlin, einem grossen Gesundheitsdienstleister in Deutschland bei welchem die EMR im Einsatz ist, erfolgte die initiale Einrichtung der EMR anscheinend innert 5 Tagen. Dies war möglich, da sich die Installation und das anschliessende Customizing sehr einfach gestalten. Es war auch ganz klar das Ziel der SAP, eine Lösung zu bringen, welche rasch und einfach zu implementieren ist und so einen leichten Einstieg in das Thema mobile Lösung ermöglicht. Auf der anderen Seite muss aber auch erwähnt werden, dass ohne ein vorhandenes SAP KIS System die gesamte Integration in Backend Systeme zusätzlich zur Implementation noch erfolgen muss – und dann ist eine Implementierung in so kurzer Zeit kaum mehr möglich.

Integrationsmöglichkeiten sind noch nicht vollständig gegeben

Aus technologischer Sicht kommuniziert die EMR App über oData (Open data Protocol) mit dem SAP EMR Mobile Server. Letzterer ist ein SAP NW Applikationsserver ABAP 7.02 der mit den Komponenten SAP Gateway Server 2.0 und dem EMR Add-on bestückt werden muss. Diese Middleware Schicht übernimmt die Kommunikation mit den Backend Systemen, wobei in der aktuell verfügbaren Ramp-up Version lediglich RFC Schnittstellen zur Verfügung stehen, was eine Einschränkung auf SAP basierte Backend Systeme bedeutet. Dass das nicht genügend ist versteht sich von selbst und auch bei SAP ist das von Beginn weg klar gewesen. Aus diesem Grund wird daran gearbeitet, neben den RFC’s auch SOAP Schnittstellen bereitzustellen, sodass beliebige Integrationen zu beliebigen Systemen möglich gemacht werden können. Diese sollen mit der Verfügbarkeit der EMR App für Endkunden im April 2012 fertiggestellt sein.

Potential für die Schweiz

Als Lösungsanbieter für das Gesundheitswesen in der Schweiz haben wir uns bereits letztes Jahr mit der Positionierung der SAP EMR auseinandergesetzt. Die Herausforderung die sich uns stellt ist die Tatsache, dass das SAP eigene KIS (IS-H*MED) in der Schweiz bei keinem Kunden im Einsatz ist. Es benötigt also in jedem Fall eine Integration in ein anderes Non-SAP KIS System. Und da die Heterogenität in diesem Bereich sehr hoch ist und die verschiedenen KIS Systeme meist keine offenen Schnittstellen anbieten, wird der Aufwand für die Implementierung einer EMR im Bereich der Integration liegen.

Trotz diesem Wermuttropfen bietet die EMR Lösung von SAP aber das Potential, um in einem spezifischen Bereich in ein kleines mobiles Projekt einzusteigen und einige dedizierte und wichtige Funktionen den Benutzern bereitzustellen. Vorab die Offenheit und Erweiterbarkeit, sowie auch die einfache und rasche Implementierung der Lösung auf bestehender SAP Infrastruktur begünstigen einen einfachen Einstieg. Im Anschluss kann die Lösung dann kontinuierlich ausgebaut und optimiert werden.

Wichtig ist auch, dass es sich bei der EMR um eine erste Version handelt, welche noch viel Entwicklungspotential hat. Die SAP hat sehr hohe Erwartung in ihre mobile Lösung und ist auch Willens diese kontinuierlich auszubauen und weiterzuentwickeln. Dazu sind auch Kunden und Nutzer herzlich eingeladen, ihre Ideen und Wünsche mit einzubringen. Im “Idea Place” von SAP, der Community Plattform von SAP auf welcher neue Ideen und Wünsche von jedermann formuliert werden können, hat die EMR bereits einen festen Platz eingenommen.

Heute haben wir das ThermoDock® erhalten und natürlich sofort ausversucht.

Wie bei allen Devices ist das Einrichten einfach. Die Anwendung runterladen, den Stecker an das iPhone anschliessen und los geht’s.

ThermoDock® ist ein Fieber-Messmodul das mit Infrarot die Temperatur misst.  Das funktioniert einwandfrei und gibt die gleichen Messwerte wie andere Thermometer. Die Messwerte werden auf dem iPhone gespeichert und können bei Bedarf via E-Mail versendet werden. Dabei wird ein Mail an einen zu definierenden Empfänger erstellt welches die Messwerte in verschiedenen Formaten (html, txt, csv) enthält.

Nach ein paar Versuchen mischt sich ein komisches Gefühl in das Erlebnis. Irgend etwas gefällt mir nicht an der grundsätzlich gut gemachten Anwendung.

Datenintegration

Einmal mehr zeigt es sich, dass eigentlich zwingend ein Datenintegrationsstandard definiert werden sollte. Die Daten sind auf dem iPhone in einem beliebigen Format vorhanden und können als E-Mail versendet werden. Es ist meines Erachtens keine Integration in eine Online-Plattform vorgesehen und damit sind die Daten nur isoliert vorhanden. Es besteht keine Möglichkeit, die Daten zum Beispiel in meine Fitbit-Daten (www.fitbit.com) zu integrieren und damit einen Zusammenhang zu meinen weiteren Tätigkeiten (Beispiel: körperliche Aktivitäten) herzustellen oder die Daten anderweitig in einem Zusammenhang mit anderen Daten visualisieren zu können.

Anwendung (Apps)

Die Anwendung stellt die Funktionen für alle Produkte (Messgeräte für Blutdruck, Gewicht, Blutzucker und Fieber) der Firma MEDISANA zur Verfügung und wird mit „Einzigartiges Design“ beworben und ja, das ist es in der Tat – Einzigartig.

Obwohl grundsätzlich hübsch im Design, ist es aus meiner Sicht gewöhnungsbedürftig in der Anwendung. Schwierig zu erklären. Mit ein wenig Geduld kann man sich einfach durch die verschiedenen Funktionen navigieren. Der Grund meiner Irritation liegt darin, dass die Anwendung gesucht hübsch ist. Da hat sich ein Team wirklich Mühe gegeben und versucht eine verspielte Apps zu bauen. Und genau das ist es was mich am Ende stört. Das Apple-Design lebt nicht von Verspieltheit, sondern von einem klaren, simplen Design. Kein rumspielen und herausfinden. Sondern klare Linien und einfache Bedienung.

Zwischenfazit

Ich werde mal damit starten, ThermoDock® über eine längere Zeit zu testen und mal schauen, ob ich mich an die Apps gewöhne.

Die Funktion “Messen der Temperatur” wird auf alle Fälle korrekt bereitgestellt. Die Verpackung und Usability ist auch eine Geschmacksache.

Angenommen ich habe eine Blog-Software und möchte einen Test schreiben, welcher einen Blog-Eintrag veröffentlicht. Hierbei interessiert mich nur gerade das Veröffentlichen des Bloges. Alle restlichen Funktionen und Abläufe z.B. die Registrierung eines Blog-Benutzers interessieren mich jedoch nicht. Der Test wird also wie folgt beschrieben:

• Name: Blog-Eintrag veröffentlichen
• Vorbedingungen: Blog-Benutzer existiert und kann Einträge veröffentlichen
• Testresultat: Der Blog-Eintrag wurde korrekt veröffentlicht
• Testfall: Der Blog-Benutzer schreibt einen Blog und veröffentlicht diesen auf der Homepage.

Bei der Durchführung dieses Tests habe ich nun das Problem, dass ich die Vorbedingungen sicherstellen muss. Sprich ich muss zuerst einen Blog-Benutzer anlegen, welcher Einträge veröffentlichen kann. Ein kleiner und einfacher Test kann also auf Grund der Vorbedingungen schnell sehr aufwendig werden. Vor allem wenn z.B. Ausnahmefälle (z.B. mit einem gesperrten Blog-Benutzer) getestet werden müssen. Ebenfalls habe ich das Problem, dass die Überprüfung des Testresultates nicht immer einfach ist. Für automatisierte Tests im Java-Umfeld gibt es hierfür ein Zauberwort: „Unitils“.

Unitils ist ein Test-Framework, welches auf JUnit basiert und verschiedene Module zum Testen von Java-Anwendungen beinhaltet. Eines der Module heisst DBUnit. Mit Hilfe dieses Modules kann unser kleines Problem sehr einfach und elegant gelöst werden. Mit DBUnit kann ein definierter Datenzustand in der Datenbank inialisiert werden. Ebenfalls können nach einem Test die Datensätze mit Hilfe von DBUnit überprüft werden. Der Ablauf ist sehr einfach:

1. Die Datenbank wird mit einem definierten Zustand initialisiert
2. Der JUnit-Test wird ausgeführt
3. Die Modifikationen in der Datenbank werden überprüft

Dadurch können auch Spezialfälle sehr schnell und einfach getestet werden.

Datenbank initialisieren

In Schritt 1 wird mit Hilfe einer XML-Datei der Zustand der Datenbank definiert. Die Datenbank wird vor der Ausführung des Tests automatisch durch Unitils initialisiert.

Beispiel XML:

<dataset>
 <TBL_USER ID=”1” LOGINNAME=”testuser” ACTIVE=”1” />
 </dataset>

Hier wird also ein Benutzer „testuser“ in der Datenbank angelegt, welcher aktiviert ist und somit Blog-Einträge erfassen kann.

Datenbank überprüfen

Auch die Testresultate können mit Hilfe einer XML-Datei definiert werden. Unitils überprüft nach der Testdurchführung die Datenbank auf Grund der in der XML-Datei definierten Datensätze.

Beispiel XML:

<dataset>
 <TBL_BLOG ID=”1” USER_ID=”1” BLOG=”Dies ist ein Blog...” />
 </dataset>

Hier wird also überprüft, ob in der Datenbank der Blog-Eintrag korrekt erstellt und mit dem Benutzer verknüpft wurde.

Datensets (XML-Dateien)

Ein Test kann beliebig viele Datensets laden. Ebenfalls können die Datensets (XML-Dateien) von beliebig vielen Tests verwendet werden. Mit Hilfe von Defaultdatensets können so sehr schnell die Vorbedingungen sämtlicher Tests abgedeckt werden. Z.B. könnten wie folgt Defaultdatensets definiert werden:

• Aktiver Benutzer
• Gesperrter Benutzer
• Blog Eintrag für Benutzer
• etc.

Kennen Sie das Problem mit den Vorbedingungen für einen Test? Welche Lösung haben Sie dafür?

Diese Erwartungen werden auch an Softwareprojekte gestellt. Solch hohe Ansprüche werden leider oft durch ein minimales Testkonzept anvisiert. Tests werden manuell durchgeführt und gehen sogar teilweise vergessen respektive die Zeit oder das Budget reichen nicht mehr. Bei einer neuen Softwareversion, Weiterentwicklung werden nur die neuen Funktionalitäten getestet und die bestehenden geraten in Vergessenheit. Dadurch können kurzfristig sehr einfach Kosten eingespart werden. Doch ist dies längerfristig gesehen auch der richtige Weg? Die Antwort lautet: „Nein!“.

Langfristig leidet die Qualität der Software enorm, denn die älteren Funktionen geraten zunehmend in Vergessenheit und werden nicht mehr bei jeder Version getestet. Dadurch können sich sehr schnell Fehler in der Software einnisten, welche mit einem grossen Aufwand und somit hohen Kosten wieder korrigiert werden müssen.

Dies zeigt auch eine Grafik der Firma SQS (Software Quality Systems AG):

Quelle:  http://www.sqs.com/de/de/Download/Datenblatt_EED_DE.pdf

Je früher ein Fehler entdeckt wird, desto niedriger sind die Kosten für dessen Korrektur. Wie können solche Fehler frühstmöglich erkannt bzw. vermieden und dadurch langfristig Kosten gespart werden? Durch automatisiertes Testen. Das automatisierte Testen ist der Garant für einen langjährigen Erfolg. Selbst für kleine Projekte!

Beim automatisierten Testen werden bereits während der Entwicklung einer neuen Funktion Tests geschrieben, welche in Zukunft immer und immer wieder automatisch ausgeführt werden. Diese Tests werden durch eine geeignete Infrastruktur (z.B. einen Buildserver) zyklisch ausgeführt und die Entwickler automatisch über dessen Ergebnisse benachrichtigt. Dadurch kann bereits während der Implementierung sehr schnell ein Fehler erkannt und korrigiert werden.

Ist in Ihrer Software die Qualität gewährleistet? Wie testen Sie Ihre Software?

Bei der emineo setzten wir immer stärker und konzentrierter auf Test-driven development. Was bei reinen Open-Source Entwicklungen problemlos funktioniert, ist bei SAP NetWeaver basierenden Entwicklungen eine höhere Herausforderung welche wir aber in verschiedenen Projekten bereits erfolgreich einsetzten können.

Frage ich Kollegen und Bekannte, wie viele Km ich täglich in meinem Büro-Job laufe, erhalte ich als Antwort im Normalfall „so ca. 2 Km“. Tatsächlich laufe ich an einem normalen Tag locker zwischen 4 und 7 Kilometer. Kommt noch Sport  dazu, komme ich auf 10 bis 14 Km. Über die Wochen gesehen, kommt da ein Tagesdurchschnitt von 6 bis 10 km zusammen. Mithilfe der Fitbit Benchmark  sehe ich zusätzlich, dass ich mich innerhalb meiner demografischen Daten deutlich mehr als der Durchschnitt bewege.

Da Fitbit nicht nur meine Bewegung am Tag aufzeichnet, sondern auch meinen Schlaf, weiss in unterdessen auch, dass ich im Durchschnitt 6 Stunden und 48 Minuten schlafe und damit leicht unter der empfohlenen Schlafdosis und dem Durchschnitt bin – ja das merke ich jeden Tag.

Ja, Fitbit zeichnet meine Bewegungen detailliert auf und erlaubt mir damit ungefähr zu wissen, wie ich mich Bewege (Tag und Nacht) und wie sich diese Bewegungen zum Durchschnitt innerhalb meiner demografischen Daten verhält.

Auf die Frage, ob ich damit mein Bewegungsmuster verändert habe, kann ich noch keine Antwort geben. Bis jetzt hat es nicht dazu geführt, dass ich mir aktiv vorgenommen habe jeden Tag mindestens 10 Km zu laufen oder länger zu schlafen. Aber ich denke, es hat auf alle Fälle mein Bewusstsein in Bezug auf meine Bewegungen verändert und ich entscheide mich heute schneller für den laufenden, denn für den fahrenden Weg.

Aber ich trage den Fitbit auch primär aus Neugierde und nicht weil ich aktive etwas ändern wollte oder musste. Aber für den Einsatz im therapeutischen Bereich oder der Rehabilitation scheint mit Fitbit zur Bewusstseinsbildung einen wertvollen Beitrag leisten zu können.

Zusätzlich ist der Fitbit von allen bisherig getesteten Geräten das mit dem grössten Komfort. Sicher besteht immer ein wenig die Angst des Verlierens, aber die Einfachheit im Tragen und dem automatischen Datenübermitteln sobald man in der Nähe der Station vorbei geht (integriertes WiFi) ist ziemlich bestechend und der Fitbit muss ca. alle 5 Tagen mal für 2 Stunden an Netz zum Aufladen. That’s it.

Somit ist der Fitbit extrem einfach in der Handhabung und benötigt kein technisches Know-how. Die Daten könnten einfach in eine Plattform (Beispiel: IBM Patient Empowerment-System) eines Leistungserbringers integriert werden und damit könnte ein proaktives Monitoring erfolgen und der Patient kann gezielt unterstützt und gefördert werden. Nebst seinem erhöhten Bewusstsein aufgrund der verfügbaren Informationen.

Damit kann Fitbit aus unserer Sicht mit dem Einsatz von Fitbit einen echten Mehrwert generiert werden nebst dem spielerischen und informativen Element.

Worum geht’s im Detail? Um die Verwendung nichtinitialisierten Daten, automatische Typenkonvertierung und Namen für Attribute.

Was sollte die ganze Sache machen? In einer Web-Site gab es einen Link, um Bilder die “hidden” sind, also nicht dargestellt werden obwohl sie bereits in den Browser geladen sind, zur Anzeige zu bringen. Drückt man diesen Link, soll ausser dem Sichtbarmachen des Bildes der Text “zum Anzeigen drücken” ersetzt werden mit “zum Verschwinden lassen drücken”.

Implementiert wird das Ganze so, dass der identische Link je nach Anwendung den ersten oder zweiten Text anzeigt. Anhand eines Attributs, das zum umschliessenden DIV-Element gehört wird geprüft welche Funktion auf den Link angewendet wird.

Und jetzt geht’s los: im Initialfall existiert dieses Attribut noch gar nicht wenn das Script beim Laden der Seite ein erstes Mal ausgeführt wird. Im Code wird erkannt dass das Attribut “undefined” ist (d.h. nicht existiert), dann wir ein Attribut mit dem Namen “hidden” erstellt und der Wert der zugewiesen wird sagt aus, dass das oben erwähnt DIV-Element nicht darzustellen sei. Dazu nimmt man den Wert 1 (vermutlich eine Zahl und kein String, aber dies sei dem Browser überlassen). Wird der Link geklickt wechselt der Wert auf 2 und die Darstellung ändert (Bild wird sichtbar, der Text auf dem Link ändert sich).

Soweit so gut, dass ist was der Internet Explorer macht. Andere Browser sagen sich “hey, es soll ein Attribut namens “hidden” gesetzt werden, vermutlich meinte der Entwickler aber dass das Element hidden sein soll. Also wird das DIV-Element hidden gesetzt, immer…

Ein erster Schritt zur Korrektur ist, dass der Name des Attributs ein bisschen optimiert wird, so heisst es neu “pictureHidden”.

Und wieder geht es im Internet Explorer. Andere Browser denken sich: die Prüfung im JavaScript auf für das Attribut “pictureHidden” auf den Wert “undefined” mach ich doch gar nicht, denn das Attribut gibt’s ja gar nicht. Von der hehren Absicht ein solches zu erzeugen wenn es dieses Element noch nicht gibt lassen sie sich wenige beeindrucken.

Ein zweiter Schritt zur Korrektur ist die Definition dieses Attributs “pictureHidden” im zugehörigen DIV-Element, weiter ersetzen wir die Zahlen durch die boolschen Werte “true” und “false” weil zwei definierte Zustände eigentlich eine schöne Sache sind.

Gesagt getan, die einen Browser sind begeistert vom neuen Script, schalten das Bild ein und aus, ganz nach Belieben des Benutzers. Nur – einige Browser schaffen es nur den Link verschwinden zu lassen, ohne dass das Bild erscheint. Dafür wird aber auch der Link nicht mehr angezeigt.

Was ist los? Ja jetzt sind wir bei der Typenkonvertierung. Im DIV-Element wird der Wert als String zugewiesen. Im Test wird auf eine boolesche Variable geprüft. Da denken sich die einen Browser ja der String “true” der sieht ja so ein bisschen wie das boolsche true aus, nehmen wir mal an es stimmt. Andere Browser denken sich “wenn der Programmieren einen boolschen Werte gemeint hätte, hätte er das Attribut sicher mit einem solchen abgefüllt (es sei verschwiegen, dass man für das Element den Werte gar nicht anders als in Form eines Strings zuweisen kann…) als mach ich mal gar nichts bis irgendwas.

Ein dritter Schritt zur Korrektur ist die Prüfung des Attributwerts gegen Stringliterale zu machen. Et voila, jetzt verstehen mich alle Browser.

Zusammenfassend sieht die Lösung also folgendermassen aus:

• deklariere die Variable
• initialisiere die Variable
• achte auf die Typisierung
• greife erst auf die Variable zu wenn sie bereits existiert und initialisiert ist

Im allgemeinen Trend sehe ich immer wieder das typsichere Sprachen und ein strenger Compiler als bemühend wahrgenommen werden. Als nicht JavaScrip-Crack hätte ich aber ein weniger dynamisches System vorgezogen und mir neben dem „mich ärgern“ auch zwei Stunden Arbeit erspart.

Es ist erstaunlich was ein einzelner Mensch bewirkt und auslöst. Der Tod von Steve Jobs bewegt, obwohl wir ihn ja gar nicht kennen. Das Synonym von Steve Jobs und Apple. Man könnte das Gefühl bekommen, dass Apple einen einzigen Mitarbeiter hat und dies obwohl es deren ca. 46’000 sind.

Traurig, dass Steve Jobs so früh sterben musste und seine Familie, Freunde und sein Leben nicht länger geniessen konnte.

Und was wird aus Apple?

Ich muss ja gestehen, dass ich ein später Bekehrter war. Ich bin Dipl. Informatiker, beschäftige mich seit mehr als 15 Jahre mit der Entwicklung und Einführung von Computer-Systemen. Ich hatte fast alle Generationen von Smartphones, gestartet mit Nokia und anschliessend mit Microsoft weiter gemacht. Macht ja Sinn wenn auf dem PC alles Microsoft ist, dies auch auf dem mobilen Gerät einzusetzen.  Und dann vor nicht langer Zeit, immer noch mit einem HTC, habe ich mir die Vorträge der Microsoft Konferenz in Barcelona angeschaut und bin anschliessend in den Apple Laden und habe mir das erste iPhone gekauft.

Heute interessiert mich nicht mehr die Technologie, sondern die Lösung welche von Menschen verwendet wird.

Zurück am Arbeitsplatz war das iPhone nach 30 Sekunden synchronisiert, up and running. Ok, ich konnte nicht so viel Einfluss auf das Ganze nehmen, ich habe die TCP/IP Einstellungen und sonst noch einiges Technisches gesucht. Nicht gefunden und na ja, habe ich das jemals gebraucht? Und ja, spätestens jetzt war ich ein Bekehrter.

Den privaten PC habe ich schon lange mit Mac ausgetauscht. Nicht nur weil sie besser in die Wohnung passen, sondern weil sie um einiges langlebiger sind. Ok, ich habe hierfür noch keine passende Erklärung. Aber Tatsache ist, das mein Mac-Air einfach läuft und läuft und läuft. Immer gleich stabil und gleich schnell. Und was ist mit meinem PC im Geschäft. Ich denke, der läuft jeden Abend langsamer als am Morgen. Ich kann wirklich zuschauen. Obwohl ich mit dem PC auch nicht mehr mache als mit meinem Mac. Ausser dass es gewisse Programme (Beispiel: MS Project) für den Mac nicht gibt und meine Dokumente bei Kunden identisch aussehen und funktionieren müssen.

Und da ist natürlich das iPad. Das Gerät (der Begleiter) das ich mit Abstand am Meisten verwende und das mich immer begleitet – ging das mal ohne? Ich hatte das Glück, eines der ersten iPad’s zu ergattern und ich habe das seinerzeit meiner Partnerin geschenkt. Sie hat sich natürlich höflich bedankt und ziemlich schnell gefragt, für was sie das denn brauchen würde. Ok, es ist hübsch, handlich – und für was zu gebrauchen? Heute ist es auch bei ihr das Gerät, das sie am meisten verwendet und ich werde bei jedem Generationswechsel das Neuste kaufen.

Mit einer eigenen Firma habe ich mir schon so manche Gedanken zu Apple gemacht. Wer wünscht sich das nicht, dass er Schlange vor seinem Geschäft hat, nur weil ein bisher schwarzes Produkt in weiss erhältlich ist. Das Käufer tagelang vor dem Geschäft campieren und dann noch monatelang warten.

Was für eine Symbiose von Einfachheit, Designe das der Mehrheit gefällt, Funktionalität, Nutzen, technischer Machbarkeit, technologischer Verfügbarkeit und einfach das richtige Momentum. Nicht nur einmal, sondern bereits ein paar Mal nacheinander.

Wie wird das weiter gehen? Ist das möglich ohne die charismatische Persönlichkeit von Steve Jobs? Kann ein einzelner Mensch einen solchen Einfluss haben? Irgendwie befürchte ich, dass man in ein paar Jahren den 5.10.2011 als den Wendpunkt definieren wird, an dem Apple langsam und schleichend an Bedeutung verloren hat. Ich hoffe und ich wünsche es mir, dass Apple weiterhin die Welt ein wenig verändert und uns weiterhin inspiriert und zum Staunen bringt. Zeigt was möglich ist.