Integratie van Oracle Applications met het Business Event System

November 2006 – Het Workflow Business Event System wordt als Oracle Workflow component standaard meegeleverd met Oracle Applications en is bedoeld om externe applicaties in de workflow te betrekken. Dit whitebook legt uit wat business events zijn, hoe deze gemaakt kunnen worden en hoe deze zijn in te zetten voor integratie. Het laatste punt wordt uitgewerkt aan de hand van integratie via BPEL.

Oracle Workflow

Oracle Workflow is altijd nauw verweven geweest met Oracle Applications. In de loop der jaren zijn steeds meer workflows onderdeel geworden van standaardmodules. Tegenwoordig is Oracle Workflow onderdeel van de Fusion Middleware stack en als stand-alone component met een eigen engine te gebruiken. Via PL/SQL en Java API’s is deze engine te besturen en te benaderen. Alle workflow informatie wordt hierbij in het WF schema in de database opgeslagen, waardoor een goede performance, schaalbaarheid en transactionele integriteit eenvoudig te realiseren zijn. De schakels in de workflow zijn dan ook sterk gebonden aan database users en rollen. Het Business Event System wordt echter alleen geleverd met Oracle Applications 11.5.9 of hoger.

Business Event System

Om ook applicaties en gebruikers buiten de database (of Oracle Apps) in de workflow te betrekken is het Business Event Systeem (BES) geïntroduceerd. Een business event is een proces wat mogelijk interessant is voor het lokale of externe systeem. Standaard worden ca. 1000 events uit Apps modules meegeleverd. Denk hierbij aan een event als CreateNewEmployee of aan het aanmaken van een XML document zoals een inkooporder. Deze business events zijn zichtbaar als integratiepunt in de integratie repository van Apps (vanaf 11.5.10). Wanneer je zelf een event definieert is dit event automatisch gepubliceerd als integratiepunt in de repository.

Event Manager

Met het toekennen van de autorisatie “Workflow administrator” geef je iemand toegang tot de Event Manager van het BES. Hier kun je events definiëren en wordt geregistreerd welk systeem op welk event geabonneerd is. Met een zogenaamde communication agent leg je vast langs welk protocol berichten worden uitgewisseld.

Als Oracle Workflow in de database geïnstalleerd wordt is deze database instance automatisch als lokaal systeem in de Event Manager terug te vinden. Externe systemen (database instances of hostmachines) moeten nog toegevoegd worden.

Advanced Queuing

In alle gevallen verloopt communicatie binnen het BES via Advanced Queuing (AQ). Ook het verkeer naar buiten begint bij AQ. Per agent leg je vast aan welke AQ queue ze gekoppeld zijn en of berichten worden verstuurd via sqlnet, http of smtp of een eigen protocol. Het is verstandig om voor elk gewenst type communicatie een eigen aanspreekpunt te definiëren. Ook ben je verplicht om voor ingaand en uitgaand verkeer aparte agents te definiëren.
Om berichten vanuit of naar het BES te kunnen sturen moeten ze wel van het objecttype WF_EVENT_T zijn.

SQL> desc wf_event_t
PRIORITY            NUMBER
SEND_DATE           DATE
RECEIVE_DATE        DATE
CORRELATION_ID      VARCHAR2(240)
PARAMETER_LIST      WF_PARAMETER_LIST_T
EVENT_NAME          VARCHAR2(240)
EVENT_DATA          CLOB
FROM_AGENT          WF_AGENT_T
TO_AGENT            WF_AGENT_T
ERROR_DESCRIPTION   RAW(16)
ERROR_MESSAGE       VARCHAR(4000)
ERROR_STACK         VARCHAR(4000)

De attributen in WF_EVENT_T kunnen dan gevuld worden met eigen code of gekoppeld worden aan standaard attributen in de workflow engine of aan attributen die je zelf gedefinieerd hebt in een workflowdiagram (wat in de database opgeslagen is).

Per agent kun je een queue handler specificeren waarmee je het bericht transformeert naar het in het externe systeem verwachte formaat. Je kunt deze handler zelf bouwen, maar in de praktijk gebruik je een van de meegeleverde agents/queues. (WF_DEFERRED voor asynchroon verkeer met abonnees, WF_IN en WF_OUT voor workflow verkeer, WF_JMS_IN en WF_JMS_OUT voor Java Messaging Services of WF_NOTIFICATION_IN/WF_NOTIFICATION_OUT voor Apps notifications en email berichten en email respons.

Figuur 1, Add Events in het Business Event System

Events definiëren

In het bovenstaande “Add Events” scherm zie je direct alle standaard Apps events. In dit scherm kun je events toevoegen en groeperen in event groups. Aan een event kun je een Generate functie koppelen die de event data aanmaakt (normaliter xml).

function <function_name>
        (p_event_name in varchar2,
         p_event_key in varchar2
         p_parameter_list in wf_parameter_list_t)
         return clob;

Door te klikken op de “Subscription” kolom kun je aangeven welk systeem via welke agent op het event geabonneerd of welke workflow wordt aangeroepen. Ook is het mogelijk zelf code te schrijven om eigen regels voor event subscription te implementeren. Deze code heet een rule functie en moet aan de rule API voldoen. Door het instellen van een volgnummer (phase) geef je de volgorde van executie aan. Ook geef je aan of het event key- of message-based is. Voor het lokale systeem is de event key soms voldoende. Alle noodzakelijke informatie kan immers in de database opgezocht worden. Synchroon verkeer is dus mogelijk. Voor het externe systeem is een event per definitie message-based (tenzij er databaselinks zijn). In het laatste geval ben je verplicht de verwerking op deferred (phase > 100) te zetten en de Generate functie te implementeren, om een bericht aan te maken.

Events raisen

Een event kan op twee manieren getriggerd worden; door het opnemen van een zogenaamde event activity is een workflowdiagram of door lokaal of extern de WF_EVENT.Raise() API aan te roepen. De PL/SQL API hiervan is.

wf_event.raise
   (p_event_name => ,
    p_event_key => ,
    p_parameters => l_parameter_list);

In onderstaand plaatje is een met Workflow Builder gemaakt diagram te zien waarin 2 event activities zijn opgenomen.

Figuur 2, Workflow Builder met 2 "event activities"

Een event kan dus gebruikt worden om berichten te versturen, een workflow te starten/continueren of om andere (maatwerk)code aan te roepen. Een event biedt dus ook een user hook om de standaardfunctionaliteit van Apps te customizen. Houdt er wel rekening mee dat het raisen van een event in een database trigger er geen commits in de verdere verwerking mogen zitten. Dit kan ondervangen worden door in plaats van een aanroep naar WF_EVENT.Raise() een API uit de workflow engine aan te roepen die een in de achtergrond draaiende workflow met een event activity opstart.

Berichtenverkeer

Als een event wat een bericht genereert eenmaal op de queue staat zijn er tal van manieren om dit bericht in te zetten voor point-to-point of subscribe/publish berichtenverkeer. Hierbij kan uiteraard gebruik gemaakt worden van de Oracle Fusion middleware zoals InterConnect of BPEL Process Manager of andere message service providers zoals JMS.

Ook de bij Apps meegeleverde XML Gateway kan hiervoor ingezet worden. Zodra een event is aangemaakt en zichtbaar is in de integration repository is er in de Gateway een XML representatie aanwezig die bijvoorbeeld gepubliceerd kan worden als web service.

Ook verkopen Oracle en andere bedrijven Applications adapters, waarin communicatie met veel voorkomende systemen al ingebakken zit.

Integratie met BPEL Process Manager

Het is mogelijk om BPEL Process Manager (hierna kortweg BPEL genoemd) te triggeren zodra een event ge-raised wordt. Vooraf dienen de libraries orabpel.jar, orabpel-thirdparty.jar en oc4j.zip gekopieerd te worden naar de applicatieserver van Apps. Het CLASSPATH van het Applications Framework (AF_CLASSPATH) moet naar deze libraries verwijzen. Definieer een agent van het type Custom met phase > 100 en implementeer deze agent door een Java Rule functie en de Generate functie te implementeren. Maak een JAR file van deze code en plaats dit in dezelfde directory als de JAR files. Bij de literatuurreferenties staat een verwijzing naar een voorbeeldprogramma van Oracle. Hier wordt in de rule functie het bericht aangemaakt en het BPEL proces getriggerd via Remote Method Invocation (RMI). Het aangeroepen BPEL proces moet dan de zogenaamde RMI interface implementeren zodat het proces niet alleen als webservice aan te roepen is, maar ook rechtstreeks via RMI.

Uiteraard is het ook mogelijk om vanuit BPEL een workflow of (maatwerk)code in Apps te starten. Integratie met BPEL kan echter ook gerealiseerd worden via de XML Gateway of de Oracle Applications Adapter, maar dit is een ander whitebook.

Conclusie

Met het Business Event System zijn een groot aantal standaardprocessen uit Oracle Applications eenduidig en relatief eenvoudig te integreren met andere systemen. Ook biedt het een raamwerk voor integratie van andere (maatwerk) processen binnen en rond Oracle Applications. Een voordeel is dat nadat eenmalig de details geregeld zijn, integratie op procesniveau mogelijk wordt en de gedefinieerde events op een hoog niveau “georkestreerd” kunnen worden met Oracle Workflow of BPEL of beide. Omdat Oracle Applications zwaar leunt op allerlei workflows en BPEL een steeds belangrijkere rol wordt toebedacht zal het BES in de toekomst ongetwijfeld een belangrijke rol blijven spelen in het SOA-lizen van Oracle Applications en opvolger Oracle Fusion.

Literatuurreferenties

• Getting Started with Business Event System and Advanced Queuing
• Oracle Applications Integration Cookbook
• Procesgeorienteerde integratie met BPEL