SharePoint und Rule Engines (SP 2013 VS Workflows, Simple Rule Engine, NxBRE )

Update (2019): Nun, das ist eine Serie die ich mal gestartet aber nicht beendet habe. Damals noch auf blogger - mein erster Blog - gebloggt, dann ein Paar Monate später Papa geworden und Prioritäten gesetzt. Leider kam diese Serie nie zu einem Ende. Jedoch ist der Source Code mit allen hier genannten 3 Möglichkeiten fertig Entwickelt und liegt seit Jahren auf GitHub (in den jeweiligen Branches).

Was sind Geschäftsregeln?

In der Regel sind das Abläufe und Prozeduren basierend auf definierte Gegebenheiten und bei Änderung eintretenden Aktionen. Mehr dazu in diesem Wikipedia Eintrag.

Was sind Business Rule Engines?

Hier kann ich getrost den mageren Wikipedia Eintrag Zitieren:

Eine Business-Rule-Engine (BRE) ist eine technische Softwarekomponente als Bestandteil eines Business-Rule-Management-Systems (BRMS), die eine effiziente Ausführung von Geschäftsregeln bzw. Business-Rules ermöglicht. Das primäre Ziel der BRE ist es, die Geschäftslogik von der Programmlogik oder Prozesslogik zu trennen, was grundlegende Änderungen an der fachlichen Geschäftslogik ermöglicht ohne Änderungen am Programm-Code oder am Design des Geschäftsprozesses vornehmen zu müssen.

Aha... Und der Zusammenhang mit SharePoint?

SharePoint bietet eine sehr einfache Möglichkeit und Werkzeuge für Regel-gesteuertes Entwickeln. Die Rede ist hier von Workflows. Workflows können in Visual Studio entwickelt und einer (z.B. Farm) Solution hinzugefügt oder in einer bestehenden Site per SharePoint Designer erstellt werden.

In früheren SharePoint Versionen konnte man in einer Farm Solution innerhalb von Visual Studio zwischen zwei Typen auswählen, State Machine oder Sequential Workflows. Beide hatten den Nachteil dass Änderungen am Flow immer mit einem Aktualisieren der Solution verbunden waren. Ein weiteres bearbeiten mit dem SharePoint Designer war nicht möglich.

Annahme:

Nun gibt es seit SP 2013 mit dem Workflow Manager die Möglichkeit Workflows in einer deklarativen Basis in VS zu erstellen. "Super" dachte ich mir,  endlich scheint es möglich zu sein in Visual Studio Entwickelte Workflows per SharePoint Designer anzupassen. Dies hätte den Vorteil dass man abstraktere Lösungen entwickeln und je nach Umfang die Geschäftslogik (sofern diese natürlich als Workflow abgebildet wurde) on the fly anpassen kann.

Da ich bei der Entwicklung der SharePoint Hosted Vacation Manager App eine innige Affäre mit den SP 2013 Workflows hatte und jede menge Erfahrungen sammeln konnte (natürlich nur im App Kontext, eine Farm Solution mit den SP 2013 Workflows hatte ich noch nie erstellt) bannten sich neue Hoffnungen in mir.

Gleich eine Idee in den Raum geworfen (Bonusberechnung pro Projekt) und angefangen eine SharePoint Solution zu entwickeln.

Die Idee (User Story):

Als Projektmanager möchte ich in einer Projekt Liste die Einnahmen, Ausgaben, die Projektteilnehmer, Fälligkeitsdatum und eine RegelGruppe als Metadaten pflegen können und beim Abschließen eines Projektes automatisch den Bonus pro Teilnehmer, nach frei definierbaren Regeln, berechnen Lassen.

Das Regelwerk

Entscheidung

Falls das Feld "RuleGroup"befüllt ist, soll die Regel mit dem Wert aus dem Feld "RuleGroup" angewandt werden ansonsten nehme die Default Regel. Falls keine Regel für den Wert aus dem Feld "RuleGroup" existiert gebe eine Meldung zurück.

Default Regel

Falls die Differenz v. Einnahmen u. Ausgaben größer 0 ist, soll die Differenz durch die Teilnehmeranzahl dividiert werden. Dies ergibt dann den Bonus pro Teilnehmer

Technische Umsetzung:

Es wird eine SharePoint Farm-Solution erstellt mit folgenden Komponenten:

- Felder: Titel, DueDate, Participants, Earnings, Expenses, RuleGroup und BonusPerParticipant

- ContentTypes: Project

- Lists: Projects, WorkflowHistoryList, WorkflowTasks

- Workflow: BBP (Typ Site Workflow)

So, schnell eine Solution erstellt und alles soweit implementiert. Alles (mittlerweile) easy peasy mit VS 2012.

"Deploy Solution" aus dem VS Kontextmenü ausgewählt und Schuss.... Die Solution wurde erfolgreich deployed (Zeitaufwand bis dato ca. 30 Minuten).

Ergebnis:

%XO%$&/?§.... Nachdem deployment wollte ich per SharePoint Designer den Workflow bearbeiten... Wollte trifft es so ziemlich ... Ging aber nicht (hier bitte nochmal der Aufruf, falls es doch möglich sein sollte bitte in den Kommentaren melden, eine kurze Recherche erbrachte leider auch mehr Frust wie Hochgefühle).

Irgendwie war ich danach enttäuscht und lies das Thema auf sich liegen mit der Aussicht auf "Dat werd isch ma irgendwann mache ge".

So der Zeitpunkt ist jetzt gekommen. Da ich bei der Entwicklung von Semantic Applications For SharePoint mit semantic Reasoners in Berührung kam und ich ein Gefühl für die Thematik entwickeln konnte, fiel meine Wahl auf Rule Engines und zwar Business Rule Engines.

Überblick über Business Rule Engines im .NET Umfeld

Ich werde hier jetzt keine Engines aufzählen, weil es gibt viele. Viele Kommerzielle und einige Open Source. Manche (wenn nicht sogar die meisten) basieren auf den v. Charles Forgy entwickelten RETE-Algorithmus. Was fast alle gemeinsam haben ist der Fakt, dass es Forward Chained Inferencing Engines (Vorwärtsverkettungs Inferenzmaschinen) sind.

Egal welche Rule Engine wir nehmen, schießen wir mit unserem Beispiel mit Kanonen auf Spatzen. Jedoch liegt hier weniger der Sinn im Sinn selbst sondern zählt hier eher der Lerneffekt.

Aha... und weiter... welche nun?

Mein Augenmerk lag eher auf den Open Source Bibliotheken.

Kriterien meiner Suche waren:

- Open Source

- Stabil

- Gut Dokumentiert

- Kleine Lernkurve

- Regeln sollten in einer deklarativen Form vorliegen (z.B. XML)

Gefunden habe ich NxBRE und Simple Rule Engine, wobei letzterer eher dürftig dokumentiert ist. Beide sind alt, NxBRE soll sogar (laut eigenen Aussagen) die erste open source .Net Business Rule Engine sein. Nichts desto trotz konnte ich beide erfolgreich in das Beispielprojekt implementieren. Dazu in den nächsten Posts mehr dazu.

Am Ende werde ich die Beispiel Solution zum Download anbieten.