Check alle échte Black Friday-deals Ook zo moe van nepaanbiedingen? Wij laten alleen échte deals zien

Workflow in bestaande applicatie dynamisch aanpassen

Pagina: 1
Acties:

  • TheDane
  • Registratie: Oktober 2000
  • Laatst online: 15:36
Hmz, moeilijke titel.

Goed, we hebben een (in PHP geschreven) applicatie die aanvankelijk door users in 1 land gebruikt werd. So far so good.

Nu zijn er andere landen in hetzelfde bedrijf die ook gebruik willen maken van deze applicatie. Het is alleen zo dat zij andere business rules hebben voor wat betreft publiceren, accorderen, budgetteren etc van de content die dmv het systeem gemaakt wordt (je moet hierbij denken aan een mix van een rudimentaire project manager meets CMS)

Voorbeeld:
Een medewerker van een afdeling (persoon A) van het bedrijf in land X schrijft een document (D). Een andere afdeling (en daar de leidinggevende van, ik noem 'm persoon B ) moet in land X eerst zijn akkoord geven voordat het document gepubliceerd kan worden.

Momenteel -heel kort door de bocht- krijgt B een mailtje van het systeem met de melding dat A een document heeft geschreven, en dat daar akkoord op gegeven moet worden voordat A de mogelijkheid krijg om op het "publiceer document" linkje te klikken.

Document D heeft in dit geval dus een status die door mensen met voldoende permissies geset kan worden.

So far so good, maar in essentie is dit hardcoded in 't systeem. Wisten wij veel ;)


Nu gaat land Y ook de applicatie gebruiken. In land Y bestaat het concept "akkoorderen" niet. Een medewerker kan hier zonder interventie van leidinggevenden zijn document publiceren. (wellicht omdat de afdelingen zo klein zijn dat de medewerker en leidinggevende een zijn. Of wat voor reden dan ook)

Voor land X en Y gelden dus verschillende regels voor het al dan niet tonen van het "publiceer document" linkje (of het uberhaupt toestaan van die actie)

Nog een voorbeeld:
In land X mogen per medewerker maximaal 5 documenten per jaar gepubliceerd worden. In land Y is dit onbeperkt.


Kortom, we hebben (landafhankelijke) business rules die we niet willen/kunnen hardcoden. Dit moet dus in de applicatie ingebakken worden op 1 of andere manier.

Hoe regel ik dit?


Drupal heeft hier een mooie "workflow" module voor:
screenshot
project pagina


Nu ben ik verder niks met Drupal van plan, maar conceptueel lijkt dit wel erg puick:
• Definieer event
• Definieer conditie
• Definieer actie

Maar -om toch even in Drupal termen te blijven- dan moet er dus een "hook" komen die bij iedere (public) method getriggered wordt, en het event evalueert, eventueel de condities en tenslotte eventueel actie onderneemt.
Events kunnen zijn:
• Nieuw document wordt gemaakt (dus zou getriggered moeten worden in de method die zorgt dat het document-toevoegen-formulier getoond wordt)
• Nieuw document gaat opgeslagen worden (dus zou getriggered moeten worden in de method die de POST variables ontvangt)

Condities:
• Huidig aantal documenten door persoon A < 5
• Lokatie (land van persoon A) = 'Slovakia'
(of combinatie van meerdere)

Acties:
• Stuur waarschuwingsmail naar corporate admin
• Onderbreek "save" actie en genereer adequate foutmelding
(of combinatie van meerdere)


Heeft iemand enig idee hoe dit te implementeren zou zijn?


Het leek mij handig om in iedere method waarvoor business rules kunnen gelden "iets" toe te voegen waarmee we kunnen evalueren of er uberhaupt een business rule is, en zo ja, wat de condities zijn waaraan al dan niet voldaan moet worden, en wat er dan voor actie ondernomen moet worden.

Maar hoe bepaal ik in dat "iets" (een of andere superclass method) dan welke event er optreedt? Ik zat te denken aan iets waarbij ik interpreteer welke method deze "hook" aanroept. Ik weet dan class = document, calling method = process_add_form() , dus event is dan 'nieuw document gaat opgeslagen worden'. (Inspired by [PHP] Zien welke functie een functie aanroept .. waar ook overtuigende argumenten zijn om hier absoluut geen stacktrace voor te gebruiken.) Jammer, maar ik wil dus eigenlijk ook niet die functieaanroep met parameter 'document.process_add_form' doen, want dan moet ik dat handmatig op 100 plaatsen gaan invoeren.

Maar hoe dán?


En dan de condities waaraan voldaan moet (of juist niet) worden:
Hoe kan ik die "handig" vertalen naar iets wat ik in een database kan opslaan? En er ook weer uithalen en correct interpreteren en afhandelen?


Of ben ik echt volledig op de verkeerde weg ;)
Any thoughts?

  • djluc
  • Registratie: Oktober 2002
  • Laatst online: 11:16
Worden je acties niet centraal gestuurd? Ik zou daar beginnen te zoeken naar een oplossing. Wij coden veel in MVC, daar kunnen we in de controller een verzoekje voor bijvoorbeeld een permissie gemakkelijk wegwerken. In je database kan je dan iets als in een tabel zetten als:

action - group (via koppeltabel) - special
createnewdocument - editorsY,managersY -
publishdocument - editorsY,managersY - USER LIMIT 5
createnewdocument - editorsX,managersX -
publishdocument - managersX -

Je haalt bij de login o.i.d. dus de permissies op van de gebruiker. Eventuele speciale conditions moet je zelf even parsen. Aangezien (regel2) publishdocument over de documents gaat is het vrij simpel om daar bijvoorbeeld SELECT COUNT(*) FROM documents WHERE userid=23 voor uit te voeren en te kijken of dat minder is dan 5.

  • Orphix
  • Registratie: Februari 2000
  • Niet online
Factor je business logica uit in een aparte class/bestand/library. Maak een base class met daarin alle benodigde methodes en informatie die het nodig heeft om te kunnen beslissen. Voor elke andere set business rules kan je vervolgens een afgeleide classe maken.

Sla in je database op bij welke klant/gebruiker welke set business rules (welke classe) hoort. Creer vervolgens een object hiervan en laat die al het werk doen. Kijk ook naar het 'strategy' design pattern hiervoor.

Nadeel is wel dat je dit dus zelf moet coden en niet zomaar door de eindgebruiker te veranderen is, maar de vraag is in hoeverre dit ook daadwerkelijk de wens is? Je kan altijd nog je business rules class parametriseren vanuit instellingen van de klant uit om toch enigszins klant specifieke omgevingsvariabelen in je logica te verwerken.

Ik heb het idee dat je idd wel een beetje op de verkeerde weg zit. Het is niet nodig om hier een aparte rules engine voor te maken of door middel van reflectie erachter te komen hoe je events worden aangeroepen (wtf?), met standaard programmeer technieken moet je een heel eind komen.

  • TheDane
  • Registratie: Oktober 2000
  • Laatst online: 15:36
Thanks guys,

vooral
Worden je acties niet centraal gestuurd?
gaf me een "D'oh 8)7 " erlebnis :+
natúúrlijk kan ik dit op 1 plaats regelen. Ik had alleen beetje oogkleppen op, omdat we deze events eigenlijk ook vanuit CLI scripts en APIs willen triggeren. En dan ga je dus in feite niet via die centrale plaats. In ons geval. Ja, bij nader inzien had dat anders gemoeten, en ja, dat gaan we volgende keer ook zéker doen :P

Orphix > Ik werk bij een tamelijk klein bedrijf, 2 programmeurs, dus om voor iedere business rule die $klant verzint tijd vrij te maken uit lopende projecten, schiet niet helemaal op. Dus vandaar liever de mogelijkheid om dit op deze manier voor de klant variabel te maken. Handleiding erbij, workshop voor de gebruikers, en klaar is * TheDane .. hopelijk.

Nou heb ik niet de illusie dat we er zo makkelijk vanaf komen, maar toch ;)

Anyway, ik ben nu zover dat ik events kan afvangen en condities kan invoeren. Alleen nu nog de vertaalslag tussen wat ingevoerd wordt, en wat uiteindelijk door 't systeem gechecked moet worden. Ik sta maximaal 4 condities voor, die allemaal ge'AND worden, OF allemaal ge'OR'ed. Eigenlijk wil ik die and/or nog groeperen en nesten, maar dan wordt 't denk ik voor de gebruiker te moeilijk. En te specifiek.

[ Voor 14% gewijzigd door TheDane op 07-03-2008 23:09 ]