Workshop - PUG Challenge Americaspugchallenge.org/downloads2016/940 - Hands on Busine… · Web viewYou can now drag the Applicant from the Vocabulary area and drop into the Input

Hands on Business Rules Workshop:

Corticon for OpenEdge in Action

ContentsIntroduction.................................................................................................................................................3

Use Case......................................................................................................................................................3

Setting up your environment - Getting started with Progress Arcade.........................................................3

WHAT IS PROGRESS ARCADE?.................................................................................................................3

HOW DO I ACCESS THE FEATURES OF PROGRESS ARCADE?....................................................................4

LAUNCHING YOUR OE CORTICON DEMO MACHINE ON PROGRESS ARCADE..........................................4

Overview of Corticon Rule Modeling Methodology....................................................................................6

Exercise 1 – Model Corticon Decision..........................................................................................................7

Step 1 – Create Vocabulary.....................................................................................................................7

Step 2 – Model Business Rules in Rulesheet Editor...............................................................................13

Step 3 – Create Tests.............................................................................................................................21

Step 4 – Deploy Decision Service...........................................................................................................24

Step 5 – Test Deployed Decision Service...............................................................................................28

Exercise 2 – Integrate Corticon Decision Service.......................................................................................31

Step 1 – Configure the Environment......................................................................................................31

Step 2 – Add “Using” References...........................................................................................................33

Step 3 – Add Variable Definitions..........................................................................................................35

Step 4 – Add Decision Service Execution Code......................................................................................35

Step 5 – Run OpenEdge Application......................................................................................................37

Exercise 3 – Update Deployed Decision Service........................................................................................40

Exercise 4 – Dynamic OE Data Integration with Corticon EDC...................................................................42

Bonus activities..........................................................................................................................................48

Bonus Exercise 1 – Add new Rulesheets to Ruleflow.............................................................................48

Bonus Exercise 2 – Consuming the Decision Service with soapUI..........................................................50

Bonus Exercise 3 – Configure Server Console for Monitoring................................................................54

Bonus Exercise 4 – Use PDSOE ABL Macros...........................................................................................58

Bonus Exercise 5 – Deploy Multiple Versions and specify Effective Date ranges...................................59

Bonus Exercise 6 – Advanced RuleFlow features...................................................................................62

Bonus Exercise 7 – Invoking Corticon Decision Service from a Rollbase Application.............................68

Conclusion & Next Steps............................................................................................................................75

P a g e | 2

© 2016 Progress Software Corporation and/or its subsidiaries or affiliates. All rights reserved.

IntroductionThis document outlines the exercises that you will complete as part of the workshop. It guides you step by step through building a simple Corticon decision service and integrating this with an OpenEdge application. No previous knowledge of Corticon is required. However, a basic understanding of OpenEdge ABL, Temp-Tables and DataSets is advisable.

A basic OpenEdge application is provided as a starting point. The end product of the workshop will be decision logic deployed and running in the Corticon Server and integrated with the OpenEdge application.

Use CaseDuring this workshop you’ll be asked to create a decision service and integrate this service with your backend OpenEdge application. You are working for an IT department of a large Insurance company. This company is modernizing its IT infrastructure by externalizing as much as possible all business logic in a services layer. This promotes speed of development, ease of maintenance, reuse of the same services across other applications (such as the web site), traceability and quality of the logic. The decision service we are going to work on is a service that assesses the risk of someone applying for a new insurance policy. Usually “risk” translates to higher or lower premiums to be paid for insurance coverage. Later we’ll extend the service to encompass other elements.

Setting up your environment - Getting started with Progress ArcadeWe will use a Progress Arcade virtual image in the Cloud with all Progress software required already installed for you to complete the workshop exercises.

WHAT IS PROGRESS ARCADE?Progress® Arcade™ is a web portal where you can deploy and manage Progress applications in a Cloud-based environment. You can use Arcade to migrate existing Progress applications to a public Cloud environment, run and test the application in the Cloud, and then deploy the application. Deployment includes the ability to host demos or to publish applications that are available to subscribers.

Progress Arcade is also a site where you can interact with other Arcade users, and find out about services offered by various Progress Technology Partners.

P a g e | 3


HOW DO I ACCESS THE FEATURES OF PROGRESS ARCADE?The features of Progress Arcade are grouped into functional areas, represented by six panels on the Arcade home page. The panels include:

Stage & Test – Gain experience in running your application in the public cloud. Deploy - Deploy your application into full production for customer use directly from the public

cloud (not currently available). Demo – Publish your application for demonstration purposes using the public cloud. Expo – Search for information on complementary products and services offered by the Progress

community. Community Café – Access Progress product resources and network with others in the Progress

community. Product Showroom – Learn about the features and benefits of Progress products. Specify what

technology you are interested in, and within minutes get a public cloud-based machine dedicated to your exclusive use.

LAUNCHING YOUR OE CORTICON DEMO MACHINE ON PROGRESS ARCADETo launch your OpenEdge Corticon Demo machine:

1. Several machines have been started for this workshop. Each of you will be given a unique DNS address by the workshop host (see PowerPoint slide on how to do this) at this point which points to a virtual windows server running on Progress Arcade.

2. On your laptop, choose Start| Accessories| Remote Desktop Connection and paste your unique DNS into the Computer field. Click the Connect button.

You may need to click the button left of Options to change (erase) the domain name.

3. Enter Administrator as the Username, and OERules2016 as the Password.

P a g e | 4


4. Click the Yes button to say you trust this remote connection.

5. You should now be connected to the demonstration machine running in Progress Arcade.

Note: The machine instance may have a different keyboard setting than what you are using. If your laptop has a different keyboard, you may need to set this up yourself on the machine instance through Control Panel| Region and Language settings.

P a g e | 5


Overview of Corticon Rule Modeling MethodologyModeling decision logic / calculations as business rules with Corticon generally follows a 4-step process, illustrated below:

Figure 1: Corticon Rule modeling Workflow

Starting point is defining the metadata schema describing the data on which the business rules will operate. In Corticon this meta data schema is termed a Vocabulary. In this workshop this step is streamlined by using existing OpenEdge metadata to generate a starting point Corticon vocabulary.

RuleSheets are the spreadsheet-like decision tables in which you will do actual rule modeling. The RuleSheet editor is also the place where you will apply Corticon’s rule integrity checks to ensure completeness of coverage of the rule logic, and to detect and avoid conflicts between rules.

RuleTests provide a means of defining and running Unit Tests that can ensure the rules (columns) in your RuleSheets are performing as intended.

RuleFlows provide a powerful way to graphically organize a rule process flow. This enables a complex problem to be broken down into discrete RuleSheets that can then be defined and maintained by the most appropriate resource (developer / business analyst / subject matter expert…). Individual RuleSheets (and indeed entire RuleFlows) can also then be re-used within other RuleFlows, providing significant productivity benefits though increased reusability of decision logic. RuleFlows are where you define runtime versioning and effective dating, and the RuleFlow is what is deployed to a Corticon Server where it becomes a Corticon Decision Service accessible as a SOAP or RESTful Web Service.

P a g e | 6


Exercise 1 – Model Corticon DecisionA Corticon decision model is comprised of a Vocabulary (data model), and sets of Rules against that model. The Vocabulary can be built from scratch inside OpenEdge Developer Studio (Corticon perspective), but it can also be generated from existing artifacts. OpenEdge 11.3+ provides the ability to create a Corticon Vocabulary from existing data structures like Temp-Tables and Pro DataSets. In this exercise we will create the Vocabulary from a Temp-Table within the provided application. Once we have the Vocabulary, we will model the business rules and use the analysis tools in OpenEdge Developer Studio to ensure accuracy and completeness. If there are any defects, we will resolve them. Finally we will use test data to execute the rules, and see the outcome of a given decision.

When we are satisfied with the decision model, we will use the publish wizard to deploy the service to the Corticon Server running under the Tomcat application server which is part of OpenEdge Developer Studio.

The Corticon Server (axis.war) is bundled with Corticon Studio (installed on this image including the Corticon Eclipse plugin into OpenEdge Developer Studio. It was added explicitly to enable OE developers to only need Corticon Studio for the developing and testing of OE/Corticon applications. This will make the decision available as a callable service from any application via SOAP or REST, as well as through the built in Corticon integration with OpenEdge 11.3+.

Step 1 – Create VocabularyLaunch Progress Developer Studio for OpenEdge from the desktop. If you are prompted to select a Workspace, you should use the following location D:\Progress\PDSOEWorkspace. You will see the “Risk Rating OE App” project opened. Double click Underwriting.i to reveal the contents of a pre-defined temp-table (Figure 3).

P a g e | 7


Figure 2: Corticon Designer Perspective

Figure 3: Existing OpenEdge metadata: TempTables / ProDataSets

Right mouse click on Underwriting.i and select Export/Business Rules Vocabulary Definition (Figure 4).

Figure 4: Generate intermediate .brvd file (Business Rule Vocabulary Definition)

P a g e | 8


This will launch the export wizard where you can specify to temp-tables and datasets you wish to export, as well as the location of the exported file (Figure 5).

You should choose the Applicant Temp-Table for export. You can choose any location and name for the export definition file. Be sure to remember your choices, as you will use this file to import into OpenEdge Developer Studio in a later step.

Figure 5: Select appropriate data structure to export to .BRVD file

Now change the perspective in OpenEdge Developer Studio to the Corticon Designer perspective by hitting the “Corticon Designer” button in the upper right corner.

Close the Underwriting.i file.

P a g e | 9


Figure 6: Open the “Risk Rating Rules OE” Rules Project

Right click on the ‘Risk Rating Rule OE’ project and select Import->Import… (Figure 6). This will launch the import wizard. From here you should choose “Business Rule Vocabulary Definition” (Figure 7).

Figure 7

P a g e | 10


Next you should select the .brvd file that you exported in the previous steps (Figure 8).

Figure 8

And finally you will specify the name and location in the Corticon project for the imported vocabulary file. You should choose the Vocabulary folder, and name the file Underwriting (Figure 9).

Figure 9: Specify the name and location where the vocabulary file should be created

P a g e | 11


You should now see Underwriting.ecore in the Project Explorer. (Figure 10).

Figure 10: Open the Underwriting.ecore vocabulary file in the Vocabulary Editor

In the right pane, the generated vocabulary will be displayed. Notice the little “lock” icons – this indicates that the vocabulary has been generated as Read Only. If you want to extend or customize the vocabulary then you can select ‘Set to Read/Write’ from the Vocabulary menu, which will remove the lock icons. Note that the Reimport function in the BRVD Import wizard you just stepped through enables you to incrementally and non-destructively import changes to the OE metadata on which the vocabulary is based.

Step 2 – Model Business Rules in Rulesheet EditorTo create a new Rulesheet, right mouse click on the project and select New/Rulesheet (Figure 11). Choose the “Rulesheet” folder and name it RiskRating (Figure 12). You are then prompted to specify the Vocabulary you want to use for this Rulesheet. Select the Underwriting.ecore file that you previously created (Figure 13). You are now presented with a blank Rulesheet, ready to use for modeling our rules (Figure 14).

P a g e | 12


Figure 11

Figure 12: Specify the RuleSheet name and location

P a g e | 13


Figure 13: Confirm which vocabulary the RuleSheet will use

Figure 14: RuleSheet editor

P a g e | 14


If your Corticon Designer Perspective within Eclipse is arranged slightly differently from Figure 14 above you can drag tabs around to position them how you prefer. It saves screen real estate if you drag the Rule Statements and Rule Messages tabs to be beside Properties, Problems and Error Log tabs. The Natural Language tab is not visible by default, you can make it visible by selecting ‘Show view’ from the Window menu. The Natural Language tab is not used in this workshop but feel free to ask your instructor about it.

To model the rules, first type in the Rule Statements (Figure 15). Then you assign the conditions and actions that make up the two rules in this example. For the first rule, drag the “isSkydiver” attribute over into the first row of the Conditions area. Then drag “riskRating” to the first row of the Actions area (Figure 15).

Figure 15: Drag isSkydiver and riskRating attributes into Condition & Action areas respectively

In Column 1, select “T” as the Condition (cell a1) and “High Risk” as the the Action (cell A1). (Figure 16).

P a g e | 15


Figure 16: Enter values for condition expression (cell a1) and for the associated action (cell A1)

For the second rule, drag “age” attribute to the second row in the Condition area. In Colum two type in “<35” for the Condition value, and type in “Low Risk” for the action value (Figure 17).

Figure 17

P a g e | 16


Finally, link together the Rule Statements with the declarative representation, but typing in the corresponding column number. This provides design-time linkage between the rules (columns) in the decision table and natural language rule explanations, making the RuleSheet more accessible and understandable by less technical users.

The Rule Statements can also optionally be returned by Corticon Server to any calling application or workflow. This means that Corticon not only makes a decision or calculation (determining an Applicant’s health risk rating in this case) but also provides for each individual invocation a complete plain English audit trail describing every rule that was fired to cause Corticon to return the result that it does. To enable such runtime use of Rule Statements select a Post level (essentially a logging severity level indicator) and select the entity in the vocabulary to which the RuleStatement in relevant (we only have the Applicant entity in our scenario), as shown (Figure 18).

Figure 18

Now we can check for any flaws in the rule model, such as conflicts and incompleteness. This means there are rules that overlap, or there a gaps in the logic and not enough rules to cover all possible scenarios. Conflicts can be resolved by using overrides, and incompleteness is handled by adding additional rules as suggested.

P a g e | 17


Figure 19: Corticon's “Magic Buttons", the Rule Integrity Check icons

Figure 20: Example of Conflict Integrity check’s Analysis Results

P a g e | 18


Figure 21: Example of Completeness Integrity check output

Solve these rule integrity issues as follows:

1. For the rule conflict, introduce a rule priority override for rule 2 in rule column 1. OR, make rule 2 more specific by selecting ‘F’ in cell a2. Either approach essentially means that we consider Skydiving to be dangerous regardless age, so ignoring rule 2 (the age rule) makes sense in this context.

2. For the missing rule (3), add a risk rating of MEDIUM RISK. Also don’t forget to add the missing rule statement text (Applicants who don’t skydive and are 35 or older have a MEDIUM RISK rating).

P a g e | 19


Figure 22: Complete and consistent rulesheet

NB: For simplicity reasons, we have ignored the potential NULL values in rule 3. Corticon will flag the possibility that your input data may not contain values. Usually this situation is prevented by setting the Mandatory flag to TRUE in the vocabulary meaning data presence is enforced at service level. This is not possible with the current level of integration between OE and Corticon. That said, based on customer input, Progress may relax this restriction in the next version of Corticon.

NOW, be careful! SAVE your rulesheet. This is the only way we can test the rules!

Step 3 – Create TestsRight click on the Project and select New/Ruletest. Name it Applicant and save it in the Ruletest folder. You will then choose the Rulesheet that you want to test against. Select the RiskRating Rulesheet you have just created (Figure 23).

You can now drag the Applicant from the Vocabulary area and drop into the Input section. Double click on the age attribute and type in 35. The double click isSkydiver and choose “false”. You can provide a name to identify this applicant, although it is not necessary for the decision to execute. You may also delete the other attributes for clarity’s sake if desired (Figure 24).

P a g e | 20


Figure 23: Selecting a RuleTest target

Figure 24: Specifying some test case data

Once complete, press the “Execute” button to run the test and see the outcome of the decision, as well as the corresponding Rule Statements for every rule that fired (Figure 22, 23).

P a g e | 21


Once complete, press the blue arrow “Execute” button to run the test and see the outcome of the decision, as well as the corresponding Rule Statements for every rule that fired (Figure 25, 26).

Figure 25: Executing a RuleTest

Figure 26: RuleTest results

P a g e | 22


Step 4 – Deploy Decision ServiceA decision service is a collection of one or more Rulesheets orchestrated in a Ruleflow. To deploy a decision service, first create a new Ruleflow by right mouse clicking on the project and selecting New/Ruleflow. Name the Ruleflow RiskRatingService (Figure 27). Next select the Vocabulary to use for this Ruleflow. Choose the Underwriting.ecore that you created earlier. Finally, drag the RiskRating.ers Rulesheet from the Project Explorer on to the Ruleflow canvas and SAVE.

Figure 27: Creating a RuleFlow

Figure 28: Drag RuleSheet(s) onto the RuleFlow canvas

P a g e | 23


The decision service is now complete and ready to be deployed to the Corticon Server. We will be running Corticon Server within the Pacific Application Server (same Apache-based container as PASOE). In order to start the Corticon Server:

1. Go to the Windows Start Menu All Programs/Progress/Corticon 5.5/Start Corticon Server 5.5

2. Wait 30-40 seconds for Corticon Server to start up. A PAS-Corticon console window will pop up and when the server is ready it will show a message like: “INFO: Server startup in 33918 ms”.

Figure 29: Corticon Server startup console output

In OpenEdge Developer Studio, right mouse click on the project and select “Publish”. Provide the connection details to the Corticon Server you want to publish to (Figure 31).

URL: http://localhost:8850/axis

User: admin

Password: admin

Select the “RiskRatingService” flow and Finish (Figure 32).

P a g e | 24


http://localhost:8850/axis

Figure 30

Figure 31

P a g e | 25


Figure 32

To access the Corticon Server Console and confirm the service is deployed, launch the web browser from the desktop and go to the URL: http://localhost:8850/axis (see shortcut in Chrome menu bar).

User: admin Password: admin

Once logged in you can access the deployed decision services (Figure 33), and see a list of all decisions and various details. You should see v1.0 of the RiskRatingService service (Figure 34).

Figure 33

P a g e | 26


http://localhost:8850/axis

Figure 34

Step 5 – Test Deployed Decision ServiceThe Corticon RuleTest Editor within OpenEdge Developer Studio allows you to test RuleSheets, RuleFlows or deployed decision services, whether they are deployed locally to a Corticon Server instance on the same machine or to a remote Corticon Server instance.

To test your deployed Decision Service: return to the Ruletest you created, and update the test target. Double click on the file path of the RiskRating.ers file (Figure 35), selection Localhost:8850 from the “Remote Servers” list, click the “Update List” button, and select RiskRatingService from the list of Decision Services deployed to that server (Figure 36).

Now when you execute the test, OpenEdge Developer Studio will (by default) create a SOAP message, post it to the remote URL and display the result payload from the deployed decision service (Figure 37). You can configure the RuleTester to send JSON requests rather than SOAP – the Corticon Server v5.4.0 added the ability to expose Decision Services as RESTful web services (in addition to WSDL-defined SOAP web services).

P a g e | 27


Figure 35: RuleTest target URL

Figure 36: Specifying a Corticon Server as target of a RuleTest

P a g e | 28


Figure 37: Corticon Server RuleTest target URL

P a g e | 29


Exercise 2 – Integrate Corticon Decision ServiceIn this exercise we will use the OpenEdge Rules ABL API (introduced in OpenEdge 11.3.0) to integrate the deployed decision service with an existing ABL application. Because the decision service vocabulary was created from existing Temp-Tables, these can be seamlessly used as the data payload, with no mapping or transformation necessary.

Step 1 – Configure the EnvironmentLaunch Developer Studio for OpenEdge from the desktop, if it is not already running and activate the OpenEdge Editor perspective. To leverage the OpenEdge Rules ABL API you will need to add one External Directory, and one External Library to the PROPATH of your project.

Right mouse click on the “OE Risk Rating App” project and select Properties. Navigate to Progress OpenEdge\PROPATH .

Click “Add External Library” and select “C:\Progress\OpenEdge115\gui\rules\OpenEdge.BusinessRule.pl” (Figure 38)

Click “Add External Directory” and select “C:\Progress\OpenEdge115\gui\rules” (Figure 39)

You should now see the 2 components in the Properties view (Figure 40).

Figure 38

P a g e | 30


Figure 39

Figure 40

P a g e | 31


Step 2 – Add “Using” ReferencesIn the Project Explorer, double click on SampleApp.cls to bring up the visual editor for the application form (Figure 41). To view and edit the code associated with the form, right mouse click on the form and select “View Source”, or press F9 (Figure 42).

Figure 41: OpenEdge Visual Designer perspective of GUI for .NET UI

Figure 42: OpenEdge Editor view of ABL code behind GUI for .NET UI

P a g e | 32


The first step is to add the USING references as shown in Figure 43. The code snippet is provided so you can copy and paste into your project.

/*Begin code snippet*/USING OpenEdge.BusinessRules.DecisionService.USING OpenEdge.BusinessRules.RulesServerConnectionParameters.USING OpenEdge.BusinessRules.RulesServerConnection.USING Progress.Json.ObjectModel.JsonObject.USING Progress.Lang.AppError./*End code snippet*/

Figure 43

P a g e | 33


Step 3 – Add Variable Definitions

Next you will add the reference to the Include files and Variable definitions as show in Figure 44.The code snippet is provided so you can copy and paste into your project.

/*Begin code snippet*/

DEFINE VARIABLE oOptions AS JsonObject NO-UNDO.DEFINE VARIABLE oParams AS RulesServerConnectionParameters NO-UNDO.DEFINE VARIABLE oConnection AS RulesServerConnection NO-UNDO.DEFINE VARIABLE decisionService AS DecisionService NO-UNDO.DEFINE VARIABLE dVersion AS DECIMAL NO-UNDO.DEFINE VARIABLE cServiceName AS CHARACTER NO-UNDO./*End code snippet*/

Figure 44

P a g e | 34


Step 4 – Add Decision Service Execution CodeIn this step you will add the code to execute the decision service when the “Execute” button is clicked. The code will create a connection to the Corticon Server. It will create a record in the temp-table based on the values entered in the user interface. It will execute the decision service and the update the form with the results of the decision (Figure 45).

The code snippet is provided so you can copy and paste into your project.

/*Begin code snippet*//* Connect to Corticon */oOptions = NEW JsonObject().oOptions:Add ('URL', 'http://localhost:8850').oParams = NEW RulesServerConnectionParameters(oOptions).oConnection = NEW RulesServerConnection(oParams).cServiceName = 'RiskRatingService'.decisionService = NEW DecisionService(oConnection, cServiceName).

/* Replace prior line with this code to invoke a specific Decision Service version *//* dVersion = 2.3. *//* decisionService = NEW DecisionService(oConnection, cServiceName, dVersion). */

/* Prepare request data and Invoke Corticon */EMPTY TEMP-TABLE Applicant.CREATE Applicant.Applicant.age = INTEGER(THIS-OBJECT:txtAge:Text).Applicant.isSkydiver = LOGICAL(THIS-OBJECT:chkSkydiver:Checked). decisionService:InvokeService(INPUT-OUTPUT TABLE Applicant BY-REFERENCE).

/* Process Response Data from Corticon */FIND LAST Applicant.THIS-OBJECT:txtRiskRating:Text = Applicant.riskRating.

/* Process Response Rule Messages from Corticon */decisionService:GetMessages(OUTPUT table RulesMessage). listBox1:Items:Clear().FOR EACH RulesMessage:

listBox1:Items:Add(RulesMessage.MessageText). END./*End code snippet*/

P a g e | 35


Figure 45

Don’t forget to save!

Step 5 – Run OpenEdge ApplicationNow we will run the application. From Developer Studio, click the Run button and select “Run As\Progress OpenEdge Application” (Figure 46). This will execute your app at the form will be shown (Figure 47).

Input values for Name, Age, Skydiver and click the Execute button. Based up the values you provided you will see output similar to Figure 48. You can change the values and Execute again to get various answers from the decision.

P a g e | 36


Figure 46: Run As… OpenEdge Application

Figure 47

P a g e | 37


Figure 48: Testing with some applicant data

Leave your GUI for .NET application running. We will be using it again in the next exercise, which will show how Corticon rule updates can be redeployed and can change application behavior without even restarting your app let alone making any application code changes!

Congratulations! You have a working OE application integrated with the Corticon rules engine!

P a g e | 38


Exercise 3 – Update Deployed Decision ServiceIn this exercise, while leaving the OpenEdge application running, you make a change the decision service you previously modeled. Once you re-deploy, you will see that for the same input values into the OpenEdge application you will get a different answer.

The first step is to launch OpenEdge Developer Studio, if it is not already running. Update the rules to use 30 as the threshold age. Make sure to update the Rule Statements as well (Figure 49). Don’t forget to save!! Next, right mouse click on the Project and launch the Publish wizard again. Make sure to check the “Republish” option to overwrite an existing version (Figure 50).

Finally, click the execute button on your OpenEdge app and see the new results (Figure 51).

Figure 49

P a g e | 39


Figure 50

Figure 51

As you can see, changing the rules is quick and really easy and you don’t have to touch a single line of OE code! You don’t even have to restart your application for the new logic to take effect.

P a g e | 40


Exercise 4 – Dynamic OE Data Integration with Corticon EDCIn this exercise, you will configure Corticon’s Enterprise Data Connector (EDC) feature to connect a vocabulary to an OpenEdge DB (good old sports2000 with an Applicant table added). Then you will configure the Applicant Entity in your vocabulary to map to that Applicant table in the OpenEdge DB. And the final step is to configure the field from that table that each Attribute’s value can be retrieved (or stored) as required during the evaluation of the Decision Service’s business rules IF that data is not provided by the calling application or RuleTest.

The strength of Corticon EDC is that is required no application coding or even creation of SQL queries to to access data from external relational data sources. The benefits of using Corticon are:

- Simplification of application integration code (invocation): minimal data needs to be passed to a Decision Service built on an EDC-enabled vocabulary as Corticon has the smarts to enrich the request with any addition data its rules require.

- Simplification of application integration code (response handling): Corticon EDC can also update data directly in OpenEdge (if desired and where appropriate), can reduce the complexity of application code that processes responses from Corticon as that code may no longer need to perform as many data management tasks.

- Reduction in request payload size: in many real world situations some of a Decision Service’s rules will only ever be evaluated for a small percentage of incoming requests. If such rules require data not needed by the ‘common evaluation path’ rules, then it is inefficient to have the calling application prepare that data and pass it to the Corticon Decision Service in a request message. It is more efficient to configure that Decision Service (via Corticon EDC) to be able to dynamically retrieve that data if and only if it is required based on which specific rules are evaluated for any particular request.

Configure a Data Source connection at the Vocabulary LevelBefore we can configure Corticon EDC settings we need to change the User Role such that Corticon EDC’s settings are accessible in Corticon Studio / PDSOE. To do this select Preferences from the Window menu, and in the dialog that pops up expand the Progress Corticon node and click on ‘Rule modeling’. On the right hand side now check ‘Integration & Deployment’, and click OK. If you have your vocabulary file open you will need to close it and re-open it for the additional configuration options of the new user role to become visible.

At any stage in this Exercise feel free to compare your updates to assets in your ‘Risk Rating Rules OE’ project with the completed example in the ‘Risk Rating Rules OE COMPLETED’ Project. The Vocabulary and the RuleTest in particular have updated to configure and test Corticon’s EDC functionality.

Having (re)opened you Underwriting.ecore vocabulary, click on the root ‘Underwriting’ node of the vocabulary and select the Database Access tab on the right hand side. A sports2000 DB is already running locally on port 12345, specify your vocabulary’s settings as in Figure 52 below and click the ‘Test Connection’ button to ensure the settings work and the DB is up and running:

P a g e | 41


Figure 52: Datasource configuration for Corticon Enterprise Data Connector

Note that the ‘Progress OpenEdge 11.4’ selection in the Database Sever dropdown also works for the v11.5 installation in your virtual image - and Corticon v5.5 GA will include OpenEdge 11.5 in the drop down list.

The Password in the above settings should match your virtual image login credentials: PUGChEx2015

Configure Entity-level persistence properties Next we need to configure the persistence properties of our Applicant entity. We need to set three things, Applicant Entity config should look like Figure 53 below:

- Entity Identity – equivalent to the Primary Key of the database table the entity is mapped to. For our purposes select your Name attribute as the Entity Identity (not realistic but OK for this workshop). [Note there are other Identity Strategies supported – with other Identity Strategies it is not necessary to explicitly include attributes in your vocabulary to match DB primary key fields].

- Set the Datastore Persistent property to ‘Yes’. - Specify a value for the Entity’s Table Name property, say ‘APPLICANT’ (please do not choose

EDC_APPLICANT, as that will break EDC connectivity in the ‘Risk Rating Rules EDC OE’ Project)

P a g e | 42


Figure 53: Entity configuration properties for EDC connectivity

Define Attribute-level persistent propertiesNext we could configure a Field name in the mapped table for each attribute of the Applicant entity. In our case we are going to have Corticon EDC generate the table in the DB so we will leave the Field Name properties empty so that Corticon EDC uses the attribute names as Field Names.

Note: If we were mapping to an existing DB table, we can import the DB schema by selecting Database Access->Import Database Schema from the Vocabulary menu, and then each attribute’s Field Name can be selected from a drop down list of the Fields in entity-mapped table.

Generate DB table from Corticon EDCNow we are ready to generate the table for our entity in the sports2000 DB. To do that select ‘Database Access -> Create/Update Database Schema’ from the Vocabulary menu. You should get a popup stating “Create/Update Database Schema complete”. If you get any errors let your instructor know.

To check the table was created correctly:

- open the DB Navigator perspective in PDSOE (Open Perspective from the Window menu- double click on the sports2000 connection profile- click OK to confirm connection- click on the active sports2000 connection - expand the DB summary that should appear in the right hand side pane- click on the WORKSHOP_APPLICANT (if listed) - review the Table info shown in the DB Details tab: should look like Figure 54 below:

P a g e | 43


P a g e | 44


Figure 54: DB Details from DB Navigaotr perspective for EDC-generated table

Connectivity between your Corticon vocabulary (and any RuleSheets built against that vocabulary) and your OpenEdge DB is now fully configured. Next we will modify our RiskRating.ert RuleTest asset to show the benefit of using Corticon EDC to dynamically retrieve data:

Open RiskRating.ert and add another TestSheet to it by selecting ‘Testsheet->Add testsheet’ from the RuleTest menu.

If desired you can rename this by selecting ‘Testsheet->Rename testsheet’ from the RuleTest menu. Copy and paste the test cases from the original TestSheet, then remove the age and isSkydiver

attributes from each test case. Finally we have to configure the TestSheet itself to use EDC. To this select ‘Testsheet -> Database

Access -> Read Only’ from the RuleTest menu.

Now if you run the new TestSheet you should see output like Figure 55 below. Note that the age and skydiver values have been retrieved from the DB by Corticon – they are bolded because their value was set during evaluation of the rules rather than being passed in to Corticon:

Figure 55: RuleTest showing Corticon EDC retrieving data dynamically from OpenEdge DB

P a g e | 45


If you check the Preview of the DB table data in the DB Navigator view you will see that the RISKRATING column still contains null values. However, if you now change the Data Access mode to Read/Write and re-run the test case, and then re-check the DB table data you will see that the RISKRATING values have been updated in the database.

P a g e | 46


Bonus activitiesIf you complete the basic lab exercises before the allotted time, you may wish to look at some addition examples of functionality.

Bonus Exercise 1 – Add new Rulesheets to RuleflowThe current Ruleflow has only one Rulesheet. Real world decisions have many Rulesheets. Your Insurance Company has decided to not only assess the Applicant’s risk, but also calculate a monthly premium for the new policy. Let’s add this calculation to a new rulesheet. Doing it in a new rulesheet allows us to segregate rules which promote ease of maintenance and re-use of rules in other ruleflows.

In this step, create a new Rulesheet called PolicyPricing. Add 3 new rules that set a policy price amount for the three different risk levels High Risk, Low Risk, Medium Risk. Note that in the rule statements we have done some interesting things.

P a g e | 47


1. We have parameterized the rule statements with actual values passed into the rules engine as well as output calculated values. Just drag and drop them from the vocabulary into the rule statement.

2. One rule statement refers to multiple rules using a rule range in the Ref field. You can also refer to individual rules using the comma separator (depending on your locale).

3.

Figure 56: Sample policy pricing RuleSheet

You can then add this Rulesheet to your existing RiskRatingService Ruleflow and link the steps together. Now your decision service not only calculates a risk rating, but it also determines the policy price as well. If you make a few adjustments to your OE app, the new policy price will be displayed in the screen (Figure 57).

Review the Completed project in the ‘Risk Rating OE App COMPLETED’ project for more info on how to enhance and change your GUI for .NET app. And ask your instructor for assistance if required.

P a g e | 48


Figure 57: Additional GUI for .NET code required to update Policy Pricing text box

P a g e | 49


Bonus Exercise 2 – Consuming the Decision Service with soapUI

Your company has asked you to integrate the RiskRatingService decision service with another business application. In this non-OE application, you’d like to use the SOAP web services protocol to send data to Corticon and parse the response. You’ll need to make sure that Corticon accepts your SOAP message and you’d like to test this before the actual integration effort. You have selected soapUI, an open source utility, to do your testing. The free Eclipse plugin has already been integrated with your Progress Developer Studio.

SoapUI requires an integration artifact (WSDL) which details the decision service specifications. The Corticon Deployment Console (normally installed with a full, standalone Corticon Server installation) has the ability to create this for you. So let’s get started!

Please follow these steps:

1. Open the Corticon Console. Navigate to the list of deployed Decision Services. On the right hand side of each line you will see a “WSDL” link. Click that to access the WSDL for the RiskRatingService Decision Service, save that WSDL file to the desktop.

Figure 58: Corticon Deployment Console

P a g e | 50


2. Open the soapUI perspective in Progress Developer Studio (from Windows menu select Open Perspective -> Other and select soapUI from the available list).

3. Create a new soapUI project by right mouse clicking on Projects in the soapUI pane.

Specify a Project Name and for the Initial WSDL file browse to the WSDL file you saved to the desktop and press OK. Expand the processRequest node in your soapUI project and open the Request1 in the tree structure in the left pane (double click Request1). The request payload will open. As you can see, some of inputs are missing.

Figure 59: soapUI - decision service SOAP request

P a g e | 51


4. Instead of manually specifying or deleting the request attribute values, let’s create the payload in Corticon Studio’s RuleTest editor and then copy it into our soapUI request message. Reopen your Corticon Designer perspective and RiskRating.ert RuleTest. Then from the RuleTest menu select Testsheet->Data->Input->Export Request SOAP and save it to the desktop.

5. Open that saved SOAP request in Notepad++, select all, and paste it over the entire contents of Request1 in soapUI perspective in PDSOE.

6. One edit that is required is to manually specify the decisionServiceName="RiskRatingService” attribute of the CorticonRequest element in the SOAP message.

7. Click the green arrow to execute the query. Did you see results like in Figure 60

Figure 60: Results from invoking a decision service in soapUI

Note 1: Corticon Server returns two objects: the WorkDocuments and Messages. Both can be used to do all sorts of things (persist the data, display data in a screen, display the rule trace in a screen).

Note 2: soapUI can be used to perform web services testing. But also for load/performance testing it is a great tool.

P a g e | 52


Bonus Exercise 3 – Configure Server Console for MonitoringYour management has requested better insight in the decisions being taken by the rule server. Corticon Server is able to monitor the values that are passing through the engine or being generated as the result of rules processing. All these statistics can be requested by API for integration with backend monitoring tools or business intelligence solutions. But the information is also displayed in the Corticon Server console!

Select “Configure Rules Server” from Corticon Server Console’s Home screen. Ensure all options are “Yes” under Decision Service Options (Figure 61). Go to list of Decision Services and select RiskRatingService. Drill down to Service Configuration and add Applicant.riskRating as a Monitored Attribute (Figure 62). For all future executions of this service, Corticon will capture statistics for the attribute that you can review (figure 63, 64).

Figure 61

Now go back to the Corticon Server Console Home screen, select Decision Services, click on RiskRatingService and then select the Service Configuration tab.

P a g e | 53


Figure 62

To add a monitored attribute type the attribute name in Entity.Attribute notation into the Monitored Attribute text box and click Add. For some types of attribute you can also specify the classification ranges that you want the monitored attribute to be analyzed against, you can do this in the Analysis Bucket text box.

P a g e | 54


The monitored attributes do not operate retrospectively so go to an appropriate RuleTest, check that it is targeting the deployed RiskRatingService Decision Service running on the Corticon Server and run a few test invocations. Then go to the Decision Services list view in Corticon Server Console…

Figure 63

…and click on the Executions metric for RiskRatingService to drill into the analytics view…

Figure 64

P a g e | 55


Feel free to insert other monitoring attributes.

P a g e | 56


Bonus Exercise 4 – Use PDSOE ABL MacrosCoding the integration code in Progress Developer Studio requires work. To minimize the coding effort, Progress made a number of macros available. There are 3 default macros provided to assist with code insertion.

1. BR-CONNECT2. BR-GETMSG3. BR-INVOKE

The templates for these are editable and found in System Preferences (Figure 65). You can experiment using these macros to automatically insert the code that you copy/pasted in the previous exercise.

Figure 65

Tip: For non OE developers, just reset your perspective to OpenEdge Editor. Revisit the SampleApp.cls by going to the code window (remember F9). Type the macro name followed by a spaces, and the macro will auto-generate all the template code for you.

P a g e | 57


Bonus Exercise 5 – Deploy Multiple Versions and specify Effective Date rangesCorticon supports concurrent deployment of multiple active versions of the same decision service. In practice, most organizations need this. This feature supports back dating or future dating of decision services. For example it helps conducting “what if” exercises like “What if we run against a previous or future version of a decision service?” Multiple version of the same decision service can “live”in Corticon Server. The invocation request payload parameters provide the necessary data to Corticon Server to automatically run the correct version of the Decision Service against the request payload.

Figure 66: Version and date parameters in a SOAP request payload

Your ABL code also supports these decision service invocation parameters.

P a g e | 58


To create a new version, navigate to the Properties panel for the Ruleflow (Figure 67). Update the Major Version to 2 and save the Ruleflow. Now when you publish the Ruleflow, you will see two versions deployed on the Corticon Server (Figure 68).

Figure 67

As you can see Corticon also support effective dates for versions. This means you can specify for what date ranges a certain version is applicable. As above, navigate to the properties for the Ruleflow, then specify a start and stop date/time. Re-publish the decision service, and you will see that there are now effective dates shown for the decision service in the Corticon Server Console Decision Service list (Figure 64).

Note: The date settings in Progress Developer Studio – perspective Corticon Studio are set to US date format (MM/DD/YY). This can be changed in the Corticon configuration settings when the software is installed. We hope you don’t mind we left it to a US setting?

P a g e | 59


Figure 68

P a g e | 60


Bonus Exercise 6 – Advanced RuleFlow featuresIn Corticon v5.5 (due to be released the week of PUG Challenge 2015) two powerful new features have been added to the RuleFlow editor: the ability to embed RuleFlows within RuleFlows, which further enhances Corticon’s ability to reuse decision logic efficiently; and the ability to define conditional branching between RuleSheets / RuleFlows. The Arcade image you are using for this workshop is a beta release of Corticon v5.5 and so contains these features. This exercise shows how these two features can be used to improve RuleFlow design.

Our starting point is a RuleFlow that contains multiple RuleSheets but is not applying any best practices to make itself intuitive. Open the PolicyFlowModel.erf RuleFlow from the ScoringModel/RuleFlow directory within the ‘Complex Ruleflow Exercise’ project. To start with this RuleFlow looks like this:

The use case for this RuleFlow is very similar to our original Risk Rating Service use case, it is just a more in-depth implementation that performs more complex Risk Scoring before classifying that Risk Score as a Risk Class which then drives some standardized policy pricing and then some state-specific pricing adjustment rules. Feel free to explore the RuleFlow and its constituent RuleSheets to familiarize yourself with the use case.

The first improvement to this RuleFlow we can make is to specify a more user-friendly Name to each step in the RuleFlow. Click on a RuleSheet, select the properties tab and set Name values for each RuleSheet in the Ruleflow.

The second improvement that can be made it to group related RuleSheets into SubFlows. A SubFlow on a RuleSheet is purely a graphical construct that provides a way of grouping RuleSheets in order to improve the visual appeal and understandability of a RuleFlow. SubFlows have no impact on the flow of

P a g e | 61


rule evaluation. In order to add SubFlows to your RuleFlows, click on RuleFlow in the Palette to the right of the RuleFlow editor and then drag the rectangular shape you require on the RuleFlow canvas. Then drag the desired RuleSheets into the SubFlow. You will need to reconnect the RuleSheets within the SubFlow.

If we give the above RuleSheets simpler Names and re-organize them into SubFlows the RuleFlow might look like this:

Next we will further simplify our RuleFlow by converting the Risk Scoring SubFlow into a reusable RuleFlow and then embedding that RuleFlow within our master RuleFlow. So create a new RuleFlow called RiskScoring.erf and (from the project explorer tab) drag the 5 RuleSheets in the Risk Scoring SubFlow above into the new RiskScoring.erf RuleFlow. It will look something like this:

P a g e | 62


Now we can replace the Risk Scoring SubFlow in our ‘master’ RuleFlow with the Risk Scoring RuleFlow. Embedding RuleFlows within RuleFlows is a new feature of Corticon v5.5. This should make our master RuleFlow appear something like this:

Now we will use another new Corticon v5.5 feature: Conditional Brnaching to replace the sequential flow within the State Adjustments SubFlow with conditional flow logic that branches based on the State attribute of the Applicant. Without the conditional Branch in place it is necessary to open up each sequential RuleSheet and examine any filters or preconditions it may contain to determine any effective ‘branching’ that the filters and preconditions apply. For instance, double click on TX Health, then select ‘Advanced view’ from the RuleSheet menu, and you will notice there are two precondition filters defined for the RuleSheet:

P a g e | 63


These precondition filters mean that the RuleSheet will only be evaluated if the two conditions are both true. So even before Corticon v5.5’s Conditional Branching functionality it was possible to achieve the same end result of conditional RuleSheet execution, however it is MUCH easier to interpret the flow of execution of a RuleFlow when the branching logic is defined in Branch object rather than hidden as filters and preconditions within RuleSheets.

To implement conditional branching in our RuleFlow:

1. select Branch from the RuleFlow editor Palette 2. draw the desired rectangle shape on your RuleFlow canvas3. drag the RuleSheets that will be conditional branching targets into the Branch object (MA, CA,

TX Health and TX Life). It is typically more intuitive to arrange branching options vertically to visually reinforce that we’re branching between them – in our case we won’t be selecting between the two TX RuleSheets, rather those should be executed sequentially for any applicants from Texas, so those two should connected horizontally, in either order, (see figure below)). Don’t be concerned that the RuleSheets will now have a red X on them, that is just indicating that none of them have yet been specified as the target for any specific branching logic.

P a g e | 64


4. Now select the Branch object and click on the Properties tab. First we need to specify which attribute’s value we are going to branch on. This attribute has to be either an enumerated type or a Boolean attribute.

5. Click the Browse button for the Branching attribute and select the ‘state’ attribute of the Applicant entity.

6. Click the Fill button to populate the node mapping table with the possible values of the branching attribute.

7. For each required value of the branching attribute click in the node area and select from the RuleSheets that you dragged into your Branch object. This should get rid of the red Xs in your Branch object.

8. Delete your now empty State Adjustments SubFlow 9. Add a connection from your Classification and Pricing SubFlow to the new ‘State Adjustments’

Branch you have just configured.

Your RuleFlow should now look something like this:

P a g e | 65


Finally, we could choose to collapse the two TX state adjustment RuleSheets into a single TX state adjustments RuleFlow. A Branch object can conditionally branch to both RuleFlows and RuleSheets. You can also nest Branch objects within Branch objects. If we made this change the final PolicyFlowModel.erf RuleFlow would look something like this:

P a g e | 66


Bonus Exercise 7 – Invoking Corticon Decision Service from a Rollbase ApplicationIn this exercise we will see how to invoke a Decision Service in the Progress Corticon Server from a Rollbase application. Specifically we will create a simple Rollbase application with a single Applicant object that will invoke the NewPolicyProcessing Decision Service that you created in Exercise 1 of the Corticon Workshop labs. In the current release of Rollbase Corticon must be invoked in the same manner as any other SOAP/HTTP Web Service, tighter integration is planned for future Rollbase releases. In order to call a Corticon Decision Service as a web service we will add the following to our Rollbase Application’s Applicant object: Document template (to represent a parameterized SOAP Request); an HTTP Post Trigger (to make the SOAP web service call); and an Object Trigger (to parse the SOAP response and update a field in our Rollbase Applicant Object).

The steps documented here will work equally well in a hosted or private cloud install of Rollbase, but for today you will use the same Progress-hosted Rollbase environment you used for the Rollbase workshop labs this morning.

Please refer to the Rollbase Workshop labs document for more detailed instructions on the basic steps to create a new Rollbase Application.

Create a Rollbase applicationWe will now create a simple Rollbase app that provides our client for the NewPolicyProcessing Decision Service. You will need to be logged in to Rollbase to do so.

If you would prefer to review a completed Rollbase application that is already integrated with Corticon you can import the Underwriting.xml Rollbase project export file that you will find on the Desktop of your Workshop Arcade image into your Rollbase account.

Create a New AppSelect the New App option from under the Applications dropdown (in the right-hand column). Select the ‘A new Application (from scratch) option, and click Create.

Give the application a name: we will use Underwriting and click Save, keeping the default values.

Create an Object DefinitionWe now need to create an object: objects are the core building block of Rollbase and can be thought of in similar terms to a database table, only far more powerful. Rollbase allows you to specify attributes and properties which add and extend the behaviour of the object automatically.

Once the application saves successfully, you will be prompted to create an Object Definition, by

selecting the + link. Select the A new Object (with Tab) option and click Create. We will name this object Applicant and will further select the Audit Trail property from the Optional Object Properties. We will keep all the other default values and click Save.

Rollbase will prompt for Tab details – we will simply take the default values and Save.

P a g e | 67


Add fields to the Object and ViewsAt this point we have the basic skeleton for an application – Rollbase has created a number of screens automatically for us, and we are now taken to the Underwriting application’s main screen. An example appears below. Of particular importance to note here is that we now are actually running the application.

Selecting the New Applicant button takes us to an input screen, as seen below. This screen is not especially useful yet, since there’s only a single field, and we need more information in order to make a decision. Rollbase allows us – as long as we have sufficient permissions – to edit screens and objects “on the fly”, via the Edit this Page functionality highlighted below.

P a g e | 68


Once in the Page Editor, we can add the fields we need to capture and display the data relating to our NewPolicyProcessing Decision Service.

We will add four new fields to our Cargo object, by dragging the New Field option from the Create group into the Default New Fields Section. For more information see the Rollbase Workshop labs document, or refer to Chapter 1 of Rollbase in Action. The necessary fields are described in the table below.

Name Type CommentName Integer RequiredAge Integer RequiredIsSkydiver Checkbox

Once the fields have been added, the screen should look similar to the screenshot below.

We now select Save & Synchronize, and check the Select All checkbox and select Save. We are now taken into the New Applicant (ie add record) screen, which now contains our new fields.

It makes more sense for our current purposes to use the Name field as the Record Name. So remove the Applicant field from the Add New Applicant view. Then edit the Applicant Object Definition and set the RecordName to a value such as {!name_field_integration_name} substituting the integration name you specified when you added the Name field to the Object.

P a g e | 69


We also want to see the results of the Decision Service call somewhere. We will add that to the Applicant View and Edit Applicant pages. To do so, we select the newly-created Applicant record from the list, using the Edit Action link. We select the Page Editor again using the Edit this Page link.

We now add the new field, as described in the table below:

Name Type CommentRiskRating Text Read Only

After this, the screen should look similar to the screenshot below.

Now select Save. Note that we do not want to synchronize this with the New Applicant page.

This returns us to the application’s New Applicant page. We can now enter some data into the page. The values aren’t especially important at this point. Once done, click Save.

Calling the NewPolicyProcessing Decision ServiceWe now need to tell Rollbase to call the NewPolicyProcessing Decision Service. We do this using simple javascript within an object script event trigger. Rollbase triggers are described in Chapter 10: Workflow and Triggers of the Rollbase in Action book.

To add the necessary triggers, select the dropdown from the Applicant tab, and select the Object Definition from the menu (see below).

P a g e | 70


We are now in the Object View page.

Create sample JSON requestBefore we create an Object Script Trigger, we will export a starting point JSON Request message for our Decision Service using the RuleTest we previously created to test our RiskRatingService RuleFlow.

In Progress Developer Studio check you are in the Corticon Designer perspective and open your RuleTest. Ensure that there is just a single Applicant test case in the Input column of the active TestSheet, deleting others if necessary. Then from the RuleTest menu withIn Corticon Studio select TestSheet -> Data -> Input -> Export Request JSON and save the JSON file to the DeskTop. For now the request message will look something like this:

{"Objects": [{ "isSkydiver": "true", "name": "John", "age": "45", "__metadata": { "#id": "Applicant_id_1", "#type": "Applicant" }}]}

Now in Rollbase, within the Object Definition view of our Applicant object, scroll down to the Triggers section or jump there via the Triggers link in the grey header section. Now click on the New Trigger button to add a new trigger, and choose the Object Script option near the end of the list, and click Next.

We first need to decide when this trigger is to be fired, in the Trigger Timing section. For our trigger, make sure that the After Create and After Update options are checked. This means that any time the values in the Applicant object change the trigger will fire.

Give the trigger a name – Applicant_invokeDecisionService for example – and then paste in the Javascript snippet below into the Formula section of the Trigger’s configuration:

P a g e | 71


var url = "http://oebpm-demo.dyndns.org:8850/axis/corticon/execute";

var data = {'Objects': [{ 'isSkydiver': {!isSkydiver#value}, 'name': {!applicant_name#value}, 'age': {!applicant_age}, '__metadata': { '#id': 'Applicant_id_1', '#type': 'Applicant' } }]}

var headers = { "dsname" : "RiskRatingService" };

var corticonResponse = rbv_api.sendJSONRequest(url, data, "POST", "application/json", null, null, headers);

var corticonResponseObject = JSON.parse(corticonResponse);

rbv_api.setFieldValue("newapplicant", {!id}, "riskrating", corticonResponseObject.Objects[0].riskRating);

Click Save. As you can see the JSON request message we output from the Corticon RuleTest has been used in the second line of JavaScript, but has been updated to insert values from Rollbase objects using syntax like {!isSkydiver#value} to substitute the value of the isSkydiver field of the Rollbase object into the JSON payload. The code is largely self-explanatory: we have to specify the Decision Service name and that is done by setting an HTTP Header called dsname, then we use a Rollbase API to make the HTTP POST call, and then use standard JSON.parse call to parse the response, and then use a Rollbase API to set the value of the riskrating Rollbase field.

Testing the integrationWe have now put all of the necessary pieces in place for our Underwriting Rollbase app to be able to call out to the Corticon Server and execute the RiskRatingService Decision Service.

To validate that the integration works, we go back to the application. Select the Underwriting application via the APPLICATIONS drop-down on the left-hand side. This will return us to the application start page (a list of All Applicants). If we select the Edit Action on the record we created earlier, we will initially see no value in the RiskRating field. If we now change the value of the Age or IsASkydiver fields, and save, we can observe that the values of these RiskRating field changes according to the rules applied to the data by the invocation of the NewPolicyProcessing Corticon Descision Service.

An example Applicant is shown below, along with the RiskRating that has been calculated by the Decision Service.

P a g e | 72


Congratulations! You have a working Rollbase application integrated with the Corticon rules engine!

P a g e | 73


Conclusion & Next StepsThis concludes this workshop. We hoped you enjoyed it. Due to the limited time, we only scratched the surface of what is possible with Corticon for OpenEdge.

What to do next?If you’d like to learn more about Corticon have a look at the Corticon YouTube channel for some great technical videos: http://www.youtube.com/playlist?list=PLC679RvCan2AFmzCof-8KZV0Mx8WpeE9L

Further learning? Note there are e-learning courses available on the Progress Education Community. Within 3 days, we’ll teach to create the most sophisticated Corticon rule models through following courses:

1. Introduction to Decision Modeling with Progress Corticon StudioThis course is an introductory course for Corticon. It provides an overview of Business Rule Modeling Systems (BRMS), their purpose and value, and the function of the different components of Progress Corticon. It teaches how to write and test business rules using Progress

P a g e | 74


http://www.youtube.com/playlist?list=PLC679RvCan2AFmzCof-8KZV0Mx8WpeE9L

Corticon Studio and covers the basic concepts of creating Vocabularies, defining rules in Rulesheets, testing rules using Ruletests, and creating Ruleflows.

2. Advanced Decision Modeling with Progress Corticon Studio

This course focuses on advanced features in Corticon Studio. It begins with a review of the following rule modeling components—Vocabulary, Rulesheet, Ruletest, and Ruleflow. You learn about Vocabulary features such as Custom Data Types and Domains. You learn about Rulesheet features such as Scope, Aliases, Collections, Filters, Dependency, and Looping. You then learn about the following Ruleflow features—Subflows, Iteration, and Service Call-outs. Finally, you learn about Ruletest features such as Annotations, generating data trees, and testing multiple Ruleflows from a single Ruletest.

3. Using Corticon Business Rules in a Progress OpenEdge Application

In this course, you will learn how to use Corticon’s business rules in an OpenEdge application. First you will learn how to set up an integrated development environment that contains OpenEdge and Corticon. Then you will learn how to export a Business Rules Vocabulary Definition from an OpenEdge application. Finally you will learn how to use a Corticon decision service from an OpenEdge application.

After taking this class, you should be able to:

Set up an integrated environment that contains Corticon and OpenEdge Export a Business Rules Vocabulary Definition file from an OpenEdge application Use a Corticon decision service from an OpenEdge application

Lastly, talk to your Progress Account Manager or SE

to get your rules projects going!

P a g e | 75
