Oracle Intelligent Advisor  

Oracle Intelligent Advisor (OIA) is a powerful rule engine that supports complex decision-making and calculations. The use-cases for OIA are endless. Whether you need to enable user-friendly self-service, improve personalized assistance through chatbots, reduce the workload of customer service agents, provide decision analytics, or fully automate decision-making OIA comes to the rescue.  

Why OIA?

Consistent decision-making 

OIA ensures consistent decision-making across various communicational channels and reduces the possibility of human error. All the above-mentioned use cases may be combined in a project and OIA guarantees that end-users receive the same result through different channels.  

For instance, a user may get assistance from a chatbot or fill-in an Interview to determine eligibility for a certain bank loan. Once he is reassured by the decision and explanation, he receives through these self-service channels he hands in his application.  The agent handling his case at the bank utilizes the automated decision-making process and at the push of a button he is presented with the exact same decision and explanation the client had received.  

Consistency is a guarantee because the core of the rule engine is the same, regardless of the end user or the channel: the rules. 

Personalized service 

OIA allows customers to get personalized advice by completing an OIA Interview on a self-service portal. The client can pick what benefit they are applying for on a user-friendly interview screen. 

The interview changes dynamically based on what data the customer provides. For instance, once the customer selects whether they are applying for a house loan or a car loan, the interview will only ask for the input data that is relevant for the chosen loan type. 

In case the client provides data that rules out eligibility – for instance the client is not employed when applying for the loan – the interview immediately returns the negative decision with the relevant explanation. 

Dynamic interviews ensure that the customer receives the decision in the shortest amount of time with the minimum number of clicks.  

Reduced workload for agents 

OIA interviews may also be designed for the use of call-center agents. Supporting the work of agents by OIA can significantly decrease the time required to process a case. By making use of OIA’s input validation, consistent decision-making, and detailed explanation on how a decision was reached the likelihood of human error can also be reduced.  

Automating complex decision-making 

Depending on the purpose of the project OIA may run in the background without a surface. OIA does not have its own database. It collects the data from other services and returns the answer. The rule engine is able to make a decision using thousands of input values within milliseconds and send back the result and the relevant explanation. 

Rules written in natural language 

OIA rules are written in Microsoft Word and Excel. OIA stands out from other rule engines because in OIA rules can be written in natural language. As a result, no serious IT background is necessary in order to build an effective decision-making system. 

The fact that the rules are written in easily understandable language greatly promotes the cooperation between the clients and developers. OIA supports various custom languages in addition to English. 

Built-in functions 

Built-in functions enable complex calculations and logic in the rules. The main types of built in functions are numerical functions, date and time functions, text functions, entity and relationship functions and temporal reasoning functions. 

Temporal variables 

A specialty of OIA is handling temporal variables, that is variables the value of which change over time. Therefore, it’s easy to handle past changes in the rule engine and calculate the margin that results from these changes. 

Built-in regressive testing  

OIA allows for saving test cases and running them at a click of a button, guaranteeing that during a new development no bugs can hide among the rules.  

The test cases are created in excel files, using color-coded input, expected and actual values. The user-friendly surface enables close cooperation with the client while creating test cases. 

The test cases can range from unit tests written to guarantee that small parts of the rules work as expected to complex test cases that cover all the rules and the whole decision-making process. 

Conclusion 

Oracle Intelligent Advisor is a powerful rule engine that can be implemented in various business scenarios. OIA ensures quick and consistent decision-making across multiple channels. It can speed up the decision-making process, reduce the workload of agents and consequently reduce costs. 

The fact that OIA can read rules from documents written in natural language simplifies the development process, allows for easier communication between developers and customers and strengthens cooperation. 

Megrendelőnk régóta a Siebel Call Center alapú rendszert használja az értékesített termékeihez kapcsolódó bejelentések, hibajegyek komplex kezelésére, alkalmazásaikat szerverekről, Windows operációs rendszeren futtatják.  

Azzal az igénnyel fordultak hozzánk, hogy a rendszer hatékonyságának növelése, valamint a saját üzemeltetésű infrastruktúra üzemeltetésének elhagyása érdekében az on-premise működésről szeretnének átállni felhős rendszerre. 

A folyamat elkezdése előtt a rendszert dockerizáltuk, annak érdekében, hogy bármilyen platformon – legyen az Windows, Linux vagy IOS – bármilyen környezetben egységesen tudjuk megkezdeni a fejlesztést és a későbbiekben az üzemeltetést is. 

Mivel az akkor használt rendszerük egy régebbi verzióval működött, így egy upgrade-et is végrehajtottunk, a 16-os rendszerről átálltunk a legújabb 22.6-os rendszerre. Erre azért is volt szükség, mert rengeteg hasznos funkció nem volt még elérhető a korábbi verzióban. Ilyen például a CRM GUI és a webtools funkciók. A két feature-nek köszönhetően már a párhuzamos fejlesztésre lehetőségünk nyílt webes felületen is.  

Ezt követően készítettük el a Proof of Conceptet. A felhőszolgáltatók közül a választásunk a linux alapú Oracle Cloud-ra esett, így a szokásos technikai kihívások mellett a Windows-os környezet Linux-ra történő áthangolása volt egy nagyobb feladat. 

Első lépésként kiépítettünk egy Linux Red Hat rendszert, ahova átmigráltuk az alkalmazást.  

A cloud-ban készítettünk két szervert (Linux és Windows), így a migrációt elővigyázatosságból két lépésben tudtuk elvégezni. Először Windowson telepítettük a felhőbe, majd tesztelést követően Linuxra is telepítettük.  

A két szervernek köszönhetően a Siebel Enterprise-on belül hibrid architektúrával dolgoztunk, aminek az volt a célja, hogy az esetlegesen felmerülő hibalehetőségeket tudjuk szűrni, illetve meg tudjuk állapítani, hogy azok miből adódhatnak (architektúra váltás vagy szerver probléma).  

A sikeres migrációt követően performancia méréseket végeztünk, amik a feltételezett eredményt hozták, Cloud-on hatékonyabban, gyorsabban működik a rendszer valamint az üzemeltetés is jelentősen egyszerűbbé vált. A POC bizonyította, hogy lehetséges a régi, jól működő rendszer modern környezetbe helyezése anélkül, hogy az üzleti logikát újra kellene fejleszteni. 

Önállóan működő és gazdálkodó költségvetési szerv, mely a költségvetés végrehajtása során a pénzforgalom lebonyolításáért, az elszámolásokért, költségvetési pozíciók előrejelzéséért, likviditás menedzseléséért, továbbá meghatározott adatszolgáltatásokért felelős.

Szektor: IT, Közigazgatás

Egy központi adatbázis rendszer kezeli többek között a család és szerzési támogatással kapcsolatos kérelmek beérkeztetését, iktatását, feldolgozását, kifizetését, statisztikák készítését és adatok tárolását.

A feladatunk a felújítási támogatás kérelmek teljes folyamatának integrálása volt a fent említett központi adatbázis rendszerbe, kezdve a különböző csatornákon beérkező kérelmek fogadásától egészen az utólagos statisztikák elkészítéséig.

A projekt megvalósítása az igényegyeztető felmérésekkel indult, ahol bemutattuk a központi adatbázis rendszer képességeit, és összehangba hoztuk a szakmai igényeket a rendszer technikai tulajdonságaival.

Az igények tisztázását követően a papíralapú, valamint az elektronikus kérelmek alapján létrehoztuk a különböző ügyek specifikus rendszerének felületeit és az adminisztrációs adatokat.

Első lépésben felvettük az ügytípust és ügyaltípust, ami jelen esetben maga a felújítási támogatás. Minden ilyen ügy saját adatlapot (az ügy főadatai) és részletek-adatlapot kapott (pl. ingatlanra vonatkozó adatok, banki adatok), illetve ügyspecifikus adatlapot alakítottunk ki a szerepkörök kapcsán is (pl. kérelmező, jogosító).

A fenti felületeken el lettek helyezve az adatellenőrzések indítására vonatkozó gombok is, amivel párhuzamosan és a szükséges egyeztetéseket követően bevezettünk négy új interfészt, melyek a kérelmekről beérkező adatok ellenőrzésére szolgálnak.

Interfészek:

• Hivatali kapun keresztül történő küldemények fogadása és feldolgozása
• Takarnet (a kérelemben szereplő ingatlan tulajdonlapját lehet lekérni a rendszerből, melyet az ügyintéző automatikusan csatolni is tud az ügy alá)
• NAV számlaonline
• TB jogviszony ellenőrzés

 

A fejlesztési fázisban végeztük egy fontos szabálybázis működéséhez szükséges specifikálást a kiadott jogszabály alapján, melynek segítségével a rendszer képes meghozni az elvárt döntést a támogatás megítélése vagy elutasítása kapcsán.

Ezután elkészítettük a szükséges ütközésvizsgálatokat, majd a pénzügyekkel és utalásokkal kapcsolatos fejlesztéseket, illetve létrehoztuk a rendszerből kiküldésre kerülő dokumentum sablonokat (pl. megállapító határozat).

Utolsó lépésként elkészítettük a riportokhoz és kimutatásokhoz szükséges felületet és adatstruktúrát, melynek segítségével a rendszerben szereplő összes felújítási támogatással kapcsolatos adat lekérdezhető és igény szerint rendszerezhető.

Az éles működés indulását követő jogszabály változásokat is lekövettük, melynek eredményeként új mezők, bejövő dokumentum típusok és hitelintézetek számára készített rendszerkiegészítő funkciók implementálására is sor került. Ezen felül elkészítettük az utóellenőrzések elvégzését biztosító funkciókat és felületeket, ezzel segítve az ellenőrzést végző kollégák munkáját.

A projekt indulásakor az elsődleges elvárás az volt, hogy a kérelmek befogadására és feldolgozására alkalmas rendszer álljon az ügyintézők rendelkezésére. Bár viszonylag szűk volt a határidő, de a projektet az igényeknek megfelelően sikeresen teljesítettük, mely nagyban köszönhető a teljes projektcsapat rugalmas és profi hozzáállásnak, illetve a két fél közötti szoros együttműködésnek, ami igazán gördülékennyé és hatékonnyá tette/teszi a közös munkát.

Önállóan működő és gazdálkodó költségvetési szerv, mely a költségvetés végrehajtása során a pénzforgalom lebonyolításáért, az elszámolásokért, költségvetési pozíciók előrejelzéséért, likviditás menedzseléséért, továbbá meghatározott adatszolgáltatásokért felelős.

Szektor: IT, Közigazgatás

A fent említett rendszer kezeli többféle támogatással kapcsolatos kérelem beérkeztetését, iktatását, feldolgozását, kifizetését, statisztikák készítését és adatok tárolását. A feladatunk a projekt kapcsán az egészségbiztosítási területhez köthető feladatokat egy rendszerbe integrálni, kezdve a különböző csatornán beérkező kérelmek fogadásától egészen az utólagos statisztikák elkészítéséig.

Az utazási költségtérítési rendszer bevezetését megelőzően a betegeknek a támogatás kérelmezése előtt a háziorvosukhoz kellett menniük a támogatási igényt jelezni, majd az utazásokhoz köthető jegyeket és számlákat össze kellett gyűjteniük, melyet kizárólag személyesen vagy postai úton tudtak eljuttatni a Megbízónkhoz. Utóbbi rengeteg adminisztrációs feladattal és hibalehetőséggel járt, valamint az ügyfelek számára is időigényes volt az eljárás teljesítése.

A cél egy olyan új rendszer kiépítése, amely eltér a korábbi szokásrendtől, automatizálja a folyamatokat, amellyel hatékonyabb működést tudnak biztosítani, minimalizálni lehet a hibalehetőségek számát, valamint felhasználóbarát felületet nyújt a Megbízó kollégái számára.

A projekt megvalósítása 2021 márciusában az igényegyeztető felmérésekkel indult, ahol megismertük a megrendelői igényeket, valamint bemutattuk a rendszer képességeit, és összehangba hoztuk a szakmai igényeket a rendszer technikai tulajdonságaival.

Az igények tisztázása után a korábbi papíralapú kérelmek alapján létrehoztuk a rendszerfelületeket az ellátásra vonatkozóan.

Ezzel párhuzamosan, a szükséges egyeztetéseket követően létrehoztuk az interfész kapcsolatokat, melyek a kérelmekről beérkező adatok ellenőrzésére szolgálnak, például, hogy a szolgáltatást igénybe vevőnek van-e valid biztosítása.

Rendszerintegrációk segítségével hozzáférünk azokhoz az adatokhoz is, amelyeket a kezelőorvosok rögzítenek a beteglátogatásokról.

Létrehoztunk egy településmátrixot, ami kiszámolja a magyarországi települések közötti távolságokat.

Ezután elkészítettük a szükséges ütközésvizsgálatokat, majd a pénzügyekkel és utalásokkal kapcsolatos fejlesztéseket, illetve létrehoztuk a rendszerből kiküldésre kerülő dokumentum sablonokat.

A fejlesztés során háromféle ügytípust különböztettünk meg:

• Utazási költségtérítés, amit bárki igénybe vehet
• Sajátos nevelési igényű gyerekek részére történő utazási költségtérítés
• Önkormányzatok által benyújtott igények

Az ügyek kezelése során kiküldésre kerülhetnek különböző kommunikációs csatornákon a rendszerben generált iratok. (megállapító sablon, elutasító határozat, tényállástisztázás stb.)

Az elektronikus kérelmek esetén már automata ügyfeldolgozás történik, a rendszer képes meghozni az elvárt döntést – a beérkezett adatok alapján – a támogatás megítélése vagy elutasítása kapcsán.

Utolsó lépésként elkészítettük a riportokhoz és kimutatásokhoz szükséges interaktív felületet és adatstruktúrát.

Az éles működés indulását követően felmerült igények alapján is kerültek be új funkciók a rendszerbe. Ilyen például az automata ügyfeldolgozás, ami azt a cél szolgálja, hogy a pénz automatizált kiutalását követően az ügy is automatikusan lezárásra kerüljön.

A projekt indulásakor az elsődleges elvárás a kérelmek befogadására és feldolgozására alkalmas felhasználóbarát felülettel rendelkező rendszer álljon az ügyintézők rendelkezésére. A megrendelő számára ezt biztosítanunk és azóta is folyamatában kezeljük a beérkező igényeket, mely nagyban köszönhető a teljes projektcsapat rugalmas és profi hozzáállásnak, illetve a két fél közötti szoros együttműködésnek, ami igazán gördülékennyé és hatékonnyá teszi a közös munkát.

A támogatási igénylés előtt a betegnek már nem kell a háziorvoshoz elmennie, a kezelőorvos rögzíti elektronikusan a megfelelő adatokat a megjelenés igazolására. Ezt követően a hivatalos igénylést már Ügyfélkapun keresztül is be tudja adni a beteg elektronikusan, valamint postán és személyesen is van továbbra is lehetősége leadni a dokumentációt, viszont ehhez már nem szükséges csatolni a menetjegyeket sem.

Introduction 

In this article, I would like to share an idea to solve a problem that occurs during the upgrade of an old Siebel version. 

This Problem usually affects upgrade projects with IP15 or older versions. 

Before OpenUI, Browser Scripts were the only way to write client-side scripts in Siebel. It was used mainly on Applets but there were occurrences for business components or for the application. 

These Browser Scripts should be replaced with OpenUI manifested JavaScript codes. In Siebel IP16 or above, these obsolete Browser Scripts, although they are supported by OpenUI, aren’t recommended. 

https://docs.oracle.com/cd/E95904_01/books/ConfigOpenUI/appendix_b_reference29.html 

Oracle suggests, that the Browser Scripts should be refactored to OpenUI. 

I wanted to achieve a general, object-oriented, and logically well-built solution, with the approach of, staying in Oracle`s OpenUI architecture, and try using the best of its features. 

 

The task 

I was working on a project with many of these Browser Scripts and the OpenUI was just getting introduced in its IP15 environment. The goal was to replace all Browser Scripts with a corresponding OpenUI solution. We were speaking of more than 50 Applet and 2-3 Business Component scripts. 

It is possible to implement every logic in OpenUI but requires some refactoring, since it has a completely different structure. The labor cost in this case would significantly increase with the number of scripts to be migrated. I wanted to come up with a more general solution that could improve the efficiency of the migration.  

With a new solution, the syntax and codes of Browser Script could be kept and reused in the OpenUI environment. 

The idea 

The idea was to use a proxy or a wrapper as an interface between Browser Script and OpenUI logic and fortunately OpenUI supports classes and an object-oriented approach.  

The first challenge was to find a way how the Browser Script Methods could be invoked in OpenUI. 

I will demonstrate the details later, but here is an example: When I refer to “Applet_PreInvokeMethod” in OpenUI, it should behave the same as in Browser Script. 

Although, it would be relatively easy to migrate with a guideline, the chances of failure will increase when it must be done 50 times. With a translator or a wrapper, these repetitions and the risk of copy-paste errors can be avoided. 

First, we summarize the statements of OUI and BS. 

Here is a partial list of these differences in the statements: 

this.FindControl(„controlname„)	var ctrls = this.Get(„GetControls”)  ctrls[controlname]
this.BusComp()	this.Get(„GetBusComp”)
this.BusComp().GetFieldValue(fieldName)	var bc = this.Get(„GetBusComp”); bc.GetFieldValue(fieldName);
this.BusComp().WriteRecord()	var bc = this.Get(„GetBusComp”); bc.WriteRecord();
confirm(„text”)	var answer = SiebelApp.Utils.Confirm(‘text’);
alert(„text”)	SiebelApp.Utils.Alert(„text”);
theApplication().GetProfileAttr(„Attr”)	SiebelApp.S_App.GetProfileAttr(„Attr”)
theApplication().SetProfileAttr(„ActBusCase”, „TRUE”);	var bs = SiebelApp.S_App.GetService(„DEMO OpenUI Services”);  var psInput = SiebelApp.S_App.NewPropertySet();  psInput.SetProperty(„AttributeName”, „ActBusCase”);  psInput.SetProperty(„AttributeValue”, „TRUE”);  bs.InvokeMethod(„SetProfileAttribute”, psInput);
return („CancelOperation”);	returnStructure [„CancelOperation”] = true;
return („ContinueOperation”);	returnStructure [„ContinueOperation”] = true;
this.InvokeMethod(„CheckRufRUEExist”);	SiebelApp.S_App.GetActiveView().GetApplet(this.GetObjName()).InvokeMethod(„CheckRufRUEExist”);

The next step was to build a context, where all the BrowserScript lines would be “OpenUI-functioning”. 

 Thanks to OpenUI and the modern Javascript architecture, a parent class was introduced. 

At this point, I would like to write a few words, about how this OpenUI architecture provides us an environment, which we may call object-oriented. There are many documents and articles about the principles of OpenUI, like what a Presentation Model or a Physical Renderer is and their recommended usage. However, the core logic and how OpenUI is built are a bit weakly documented. Javascript is not an Object-Oriented language but is certainly capable of something similar. This is aided by the technologies like constructor objects and prototypes in JS. Oracle also used these when they were designing the basic architecture, this Class-Based solution can be used for any custom solution. 

The solution 

I have written a new Presentation Model class: BrowserScriptPM.js and BrowserScriptListAppletPM.js 

It has some implemented methods, but it is an abstract interface class in general and should only be used as a superclass. 

List of BrowserScript methods and their corresponding OpenUI method: 

Applet Browser Script Methode	OpenUI Object	Method/Event	List/Form Applet
Applet_PreInvokeMethod	PM	Method: InvokeMethod	List + Form
Applet_ChangeFieldValue	PM	Method: FieldChange	List + Form
Applet_InvokeMethod	PM	Method: PostExecute	List + Form
Applet_Load	PR	PR Method: ShowUI	List + Form
Applet_ChangeRecord	PM	Event:  Select Row	List
Applet_ChangeRecord	PM	Method:  ShowSelection	Form

 

This PM acts as a base PM class for every applet which had BrowserScript. 

For instance, we have the following applet with browser script “Applet_InvokeMethod” implemented:
EVO TT Account Trouble Ticket List Applet 

How can we migrate it to OpenUI? A possible solution is to write a whole new PM and set everything up to achieve the same logic as it was in the browser script. 

With the help of our parent abstract class, it`s enough to create a new PM with the following code: 

How does it work? Trough the base class, it is functioning with the following statement: 

upon this idea, the parent class prepares every browser script call. 

It consists of implementation for the interface and an abstract method declaration that could be implemented in child classes: 

 

An extra wrapper for “theApplication” object was also required to avoid code reformatting. 

Conclusion

With this method, we achieved our goal to migrate the scripts, and we also introduced a neat feature of OpenUI and Javascript. As a result, an applet script should take no more than 3-5 minutes. The task was reduced not more than to register the new PM and copy-paste the browser script into the PM template.  

 When an error occurred in the logic, it was an easy fix because only the parent abstract class needed some adjustments. 

As a bit of advice, always try to take into consideration creating a parent super class for such solutions. 

Now we can: 

• keep our codes better organized 
• adjust and modify code easily 
• avoid repetition 
• use these structured classes as a template and reduce spaghetti code 

In this particular case, it was worth it. But if there were less than 10 Browser Scripts, I`m not sure if I would recommend building a similar framework but I would certainly think about it in in any other case. 

Gábor Káli – Senior CRM Developer