Blog

Alle Beiträge von Jan Galinski

Transformers – verwandelbare Objekte

In meinem vorangehenden Beitrag habe ich die Möglichkeiten der Predicates aus commons-collection vorgestellt. Predicates erlauben, auf einfache Art und Weise Aussagen über Objekte zu überprüfen und dadurch ein wiederverwendbares  Regelwerk zu implementieren. Sie haben jedoch eine Einschränkung: Ein konkretes Predicate bezieht sich auf einen konkreten Type (z.B. Predicate). Die Wiederverwendung wird dadurch erschwert.

Hier kommen Transformer ins Spiel, ebenfalls aus dem commons-collection Frameworks, das wieder in seiner generischen Erweiterung zum Einsatz kommt.

weiterlesen

Subject, Predicate, Object – RuleEngine light mit commons-collection

Unsere Geschäftslogik ist voll von Ja/Nein bzw. Wenn/Dann Entscheidungen. Wir benutzen diese Fragen für die Validierung („handelt es sich um eine gültige Telefonnummer?“), für Ablauflogik („Wenn die Bestellung freigegeben wurde, mache weiter mit A, sonst mit B“), für Filter („gib mir aus diesem Array alle Bestellungen deren Betrag größer sind als 5k€“) und vieles andere mehr.

Das Problem: wir behandeln diese Geschäftsregeln nicht als vom Vorfall unabhängig zu beantwortende Fragen, sondern als direkt zum jeweiligen Code gehörende Bedingung. Die fachliche Anforderung „Ermittele die Volljährigkeit eines Kunden, bevor eine Bestellung platziert wird“, erfolgt dann gerne direkt im Code:
weiterlesen

JUnit mit Guice Test-Runnern

Das Dependency Injection Framework Google Guice kann eine große Hilfe beim Testen mit JUnit sein. Es kann als dynamische Factory sowohl Mock-Objekte als auch Alternativ-Implementierungen bereitstellen und so den Einrichtungsaufwand erheblich verringern.
Koppelt man dieses Konzept mit eigenen Test-Runnern, ist das Ziel einer Zero-Config Test-Suite zum Greifen nahe.

weiterlesen

SDN: WebDynpro Configuration Adapter

Mit der WDConfiguration bietet WebDynpro (Java) eine komfortable API um auf Properties der Applikation zuzugreifen. Die mit einer WebDynpro Development Component ausgelieferten Properties haben jedoch zwei Nachteile: Sie sind zur Laufzeit nur vom Admistrator bearbeitbar und die Anwendung muss neu gestartet werden, damit die Einstellungen greifen.

Für einen generischeren Ansatz empfielt es sich, die Konfiguration auszulagern, entweder in ein File im KM Reporsitory oder in eine Datenbank-Tabelle. Genau hier kommt der Configuration Adapter zum Einsatz: Unabhängig von Ort und Art der Speicherung stellt er die WDConfiguration API zur Verfügung, so dass aus Sicht der Anwendung eine einheitliche Verwendung ermöglicht wird.

Der Configuration Adapter wurde von Holisticon im Rahmen eines Kunden-Projektes entwickelt und im SAP Developer Network veröffentlicht.