Design Time at Run time - maximale agility met Oracle Fusion Middleware
28 feb 2012 - Lucas Jellema

Verschenen in OGh Visie december 2011
Agility omvat het vermogen van een organisatie om - gedreven door gewijzigde business requirements - snel aanpassingen door te voeren in de uitvoering van bedrijfsprocessen, met minimale risico's en kosten. In de wereld van Oracle gaat het uiteraard om wijzigingen in software die door de organisatie wordt ingezet.
Design Time at Run time - maximale agility met Oracle Fusion Middleware
Agility is het streven van steeds meer organisaties. Voor dit begrip bestaat eigenlijk niet echt een Nederlands equivalent. Agility omvat het vermogen van een organisatie om - gedreven door gewijzigde business requirements - snel aanpassingen door te voeren in de uitvoering van bedrijfsprocessen, met minimale risico's en kosten. In de wereld van Oracle gaat het uiteraard om wijzigingen in software die door de organisatie wordt ingezet.
  
Snelle aanpassingen in de software die door een organisatie op run time wordt gebruikt voor de uitvoering van de bedrijfsprocessen vormen een grote uitdaging. Onderstaande figuur geeft een beeld van deze uitdaging. De organisatie is hier gekenschetst in twee dimensies - die van IT tegenover Business en die van Design Time tegenover Run Time. De ontwikkeling van software vindt van oudsher plaats in het kwadrant IT/Design Time. De snelle wijzigingen die agility een organisatie zou moeten opleveren zijn benodigd in het recht daartegenover gelegen kwadrant Business/Run Time.


Slechts weinig organisaties hebben software engineering zodanig ingericht dat in heel korte iteraties nieuwe inzichten en requirements vanuit de business worden overgebracht naar de IT-afdeling om daar te worden ontwikkeld tot gewijzigde software die ook heel snel in productie worden uitgerold. Vertraging en telefoonspel-achtige vervorming van wat precies en snel gevraagd werd treedt dikwijls op gedurende de route van eindgebruiker of applicatiebeheerder via business eigenaar, functioneel ontwerper, programmeur, tester en uiteindelijk beheerder. De figuur hieronder schetst hoe in veel organisaties het traject loopt van requirement tot realisatie. Dit is zelden een traject dat agile kan worden doorlopen.




In deze figuur zit ook een voorbeeld verstopt voor aanpassingen in de run time systemen die wél snel kunnen worden doorgevoerd.

De content editor is dikwijls in staat om in de run time omgeving of in een staging-omgeving dicht tegen productie aan, op een WYSIWYG wijze aanpassingen door te voeren in de tekstelementen en documenten die aan de eindgebruikers getoond worden vanuit de content repository. Er bestaat dus een snelle weg over weinig schijven naar aanpassingen in het productiesysteem.
Oracle Fusion Middleware (FMW) is uitgerust met een mechanisme dat 'design time at run time' wordt genoemd. Het doel van dit mechanisme is om applicaties die 'live' zijn - die zich dus al in productie bevinden - te kunnen aanpassen, via run time WYSIWYG-editors. De aanpassingen van het gedrag en het uiterlijk van applicaties die op deze wijze worden doorgevoerd, worden vastgelegd in een meta-data repository (MDS). Tijdens het uitvoeren van FMW applicaties - ADF, WebCenter, SOA Suite composites, BPM processen - wordt de MDS geraadpleegd om de huidige juiste source voor de applicatie te bepalen. Dankzij dit mechanisme kan een FMW component op agile wijze worden bijgesteld en aangepast - in de run time omgeving en met een kort deployment-traject.



Composers
Voor de manipulatie van het uiterlijk en het gedrag van FMW componenten in de run time omgeving biedt Oracle een aantal Composers. Iedere Composer is een user interface op de MDS repository die manipulatie van specifieke meta-data mogelijk maakt.
  • (WebCenter) Page Composer - tot de functionaliteit van veel Portal-producten behoort de mogelijkheid om pagina's in het portaal op run time te bewerken. Dit omvat ondermeer het toevoegen, verplaatsen of verwijderen van (statische) content elementen en zogenaamde (dynamische, interactieve) portlets. De WebCenter Page Composer brengt die mogelijkheid ook voor ADF Web applicaties. Delen van pagina's kunnen worden aangemerkt als 'customizable', hetgeen betekent dat een applicatiebeheerder op run time de pagina in edit-mode kan brengen en de wijzigbare onderdelen van pagina's kan gaan herorganiseren (zie figuur).

 



Vanuit de Resource Catalog kunnen elementen aan pagina's worden toegevoegd. Denk daarbij onder meer aan rijke tekst, plaatjes, hyperlinks, zelfgebouwde ADF Taskflows, grafieken, tabellen, elementen uit een content repository, WebCenter Services en Portlets. Naast toevoegen, verwijderen en verplaatsen van componenten, kunnen in edit-mode ook de eigenschappen van bestaande componenten worden aangepast - bijvoorbeeld style, boilerplate teksten en afmetingen.
WebCenter Portal biedt boven deze pagina-bewerkingen nog een ruime verzameling run time bewerking-voorzieningen. Deze maken het onder meer mogelijk om op run time nieuwe pagina's toe te voegen - die met de Page Editor van inhoud worden voorzien - nieuwe Data Controls en Task Flows toe te voegen, security en menu-structuren te wijzigen en via de skin en de mash up styles het uiterlijk van de applicatie fijn te stellen.


 
 

 

 

  • SOA Composer - onderdeel van de SOA Suite om via een browser interface op run time de definitie van Business Rules, Domain Value Maps en Human Tasks te manipuleren. SOA Composite applicaties bevatten veelal business-gedreven beslissingen op basis waarvan de flow in de applicatie op een specifieke manier gaat verlopen, bijvoorbeeld: bij welke ordergrootte is toestemming van een financiële controller vereist. Met deze composer kan de definitie van dit soort beslisregels eenvoudig en op run time worden gewijzigd.
  • BPM Process Composer - de BPM Suite wordt gebruikt om bedrijfsprocessen te modelleren en op run time ook daadwerkelijk uit te voeren. Een proces bestaat binnen BPM uit een combinatie van activiteiten (processtappen) die door een mens (task) of een service worden uitgevoerd. Op basis van de procesdefinitie worden op run time proces-instanties aangemaakt.

     
 

Met de BPM Process Composer kunnen procesdefinities via een browser-applicatie bekeken worden én worden gewijzigd. Processtappen kunnen omzeild worden of extra stappen en flows kunnen worden toegevoegd. NB: de beslissingen in het proces worden idealiter gemaakt op basis van Business Rules die met de SOA Composer gewijzigd kunnen worden.
 
    • (nieuw) Data Composer - met de Data Composer kunnen ADF Business Componenten worden aangepast en uitgebreid (nieuwe of gewijzigde attributen, UI hints, validatieregels, View Criteria) of zelfs worden toegevoegd (nieuwe Entity Objecten en View Objecten op basis van tabellen en views). De nieuwe ViewObjecten kunnen in de Page Composer worden gebruikt om formulieren, tabellen en grafieken toe te voegen in bestaande of zelfs in op run time gecreëerde pagina's.
    • (nieuw) Report Composer - de Report Composer ondersteunt de definitie van (eenvoudige) read-only overzichten op basis van ADF Business Componenten. De rapportages kunnen binnen de web applicatie worden getoond en worden gedownload als PDF en naar Excel.
Er wordt gespeculeerd dat Oracle met een nieuw artikel op de prijslijst komt - een bundeling van de Page, Data en Report Composers. Op dit moment is de Page Composer alleen beschikbaar als onderdeel van WebCenter Portal - en daarmee buiten bereik van veel organisaties die ADF applicaties ontwikkelen en heel goed gebruik zouden kunnen maken van de run time manipulatie van hun applicaties.
 
Customization en Personalization
Wijzigingen in applicaties zijn vaak niet bedoeld voor alle gebruikers of onder alle omstandigheden. Misschien is de huidige functionaliteit van de applicatie perfect - alleen niet voor die ene afdeling of collega's met die specifieke rol of die bijzondere locatie. Design Time at Run Time maakt het niet alleen mogelijk om applicaties 'on the fly' aan te passen, maar ook om die aanpassingen slechts door te voeren voor een specifieke situatie. Customization is de term die Oracle hanteert voor variaties in de applicatie. Tijdens de ontwikkeling van de applicatie worden customization layers gedefinieerd - de dimensies waarlangs variatie mogelijk is. Voorbeelden van customization layers zijn onder meer afdeling, rol, regio maar bijvoorbeeld ook tijdstip en uiteindelijk zelfs gebruiker.
Bij het doorvoeren van aanpassingen in de applicatie via design time at run time moet worden aangegeven voor welke situatie in welke customization layer de wijziging van toepassing is.
 
 



 
 
 
Wanneer een gebruiker de applicatie benadert wordt bepaald waar deze zich bevindt in elke customization layer.  Op basis daarvan worden in MDS de relevante delta's gecombineerd tot de source zoals die van toepassing is. De gebruiker ziet de applicatie zoals deze er gegeven de customizations die horen bij de huidige context uit zou moeten zien. NB: customization is niet alleen beschikbaar tijdens design time at run time, maar ook gewoon tijdens design time. Als tijdens de ontwikkeling van applicatie componenten al bekend is dat voor verschillende gebruikersgroepen of voor andere dimensies verschillen in de applicatie gewenst zijn kunnen deze als customizations ontwikkeld en uitgerold worden.

Het is mogelijk om gebruikers van ADF applicaties in staat te stellen om (eenvoudige) instellingen in de applicatie als persoonlijke voorkeuren te laten vastleggen. Dit personalization mechanisme heet ADF Change Persistence en omvat ondermeer zaken als de kolommen - hun breedte en positie - in een tabel, de organisatie van het dashboard en het standaard openen of sluiten van detailblokken. Dit mechanisme kan zonder enige ontwikkelinspanning worden benut.


Proces
Design Time at Run Time wordt onder meer toegepast om SaaS-applicaties (aangeboden vanuit 'de cloud') aan te passen tijdens implementatie voor een bepaalde organisatie of gebruikersgroep. De standaard SaaS applicatie kan dankzij customization die met DT@RT wordt geconfigureerd toch enigszins op maat worden afgesteld. Hierbij gaat het grotendeels om eenmalige aanpassingen.
Inzet van DT@RT om continue agility en controle voor 'de business' te bieden vergt de inrichting van een zorgvuldig proces waarin wijzigingen worden geformuleerd, aangebracht, goedgekeurd en gepubliceerd - net als met content management. De skills die benodigd zijn om met de verschillende Composers de gevraagde functionele wijzigingen door te voeren zijn ook niet triviaal. Het lijkt raadzaam voor de persoon die de rol van 'live application editor' op zich neemt om korte lijnen te houden met ontwikkelaars voor technische begeleiding. Die korte lijnen zijn ook waardevol om de terugkoppeling van de run time wijzigingen naar de ontwikkelteams te faciliteren.
Een belangrijke rol is ook weggelegd voor beheerders: ze krijgen te maken met de MDS repository met meta-data die, naast de gebruikelijke sources, bepalend is voor het gedrag en het uiterlijk van de applicatie. Deze data moet verwerkt worden als een nieuwe versie van de applicatie wordt uitgerold. Daarnaast moeten op run time doorgevoerde wijzigingen vanuit de MDS repository worden geëxporteerd en gedistribueerd naar andere omgevingen



.


Conclusie
De design time at run time faciliteiten van Fusion Middleware maken het mogelijk om een substantieel deel van wat de applicatiecomponenten doen en hoe ze eruit zien, aan te passen in zeer korte iteraties uitgevoerd binnen de run time omgeving. Hiermee kan de meest extreme vorm van agility worden bereikt, waarbij business requirements vrijwel direct kunnen worden gerealiseerd. Succesvolle introductie van DT@RT, inclusief customization en personalization, vereisen dat tijdens de ontwikkeling van applicatiecomponenten gedrag en uiterlijk waar nodig expliciet configureerbaar worden gemaakt. Bovendien is een goed proces voor run time editing en publicatie benodigd.

Lucas Jellema is Oracle ACE Director for Fusion Middleware en is werkzaam als Chief Technology Officer bij AMIS Services. Dit artikel is een weerslag van de presentatie die hij heeft gehouden tijdens de afgelopen OGh DBA en SOA/BPM dag in FIGI Zeist.