BPMN: Credit Card Request demo

Intro 

Before you jump in to implement the below tutorial, make sure you also check the below BPM related website to better understand what BPM is all about:

• Thinking Matters by Keith Swenson.

In addition to this, make sure you also check about Michael Hammer. Start with this "The Process Centered Company".

Why ? Because then you will better understand the Oracle BPM documentation  that has the below details around the "Process owner":

Process owner
Process owners are responsible for controlling and managing deployed business processes. They are responsible for the overall supervision of the running business process. They often use metric analysis tools such as dashboards to understand the current state of the managed business processes.
Process owners typically use Process Workspace. They also use Business Process Composer to change the behavior of a process by editing Oracle Business Rules. They may also use the Oracle BAM console to view metrics dashboards.

However, this tutorial has one goal and this is to make the students able to go very fast with the Oracle BPM 12c product and to define a BPM application that very fast will run.

What I love about the Oracle BPM is that what you model is what you run.   This idea and the SCA approach !
Note: Yes; guilty:  I see the BPM and the BPMN just as a program.


BPMN: Credit Card Request demo


Below you will find a demo example that covers the main patterns you need when implementing an Oracle BPM 12c project.
The project is nothing new  since will use some of the previous main services already covered in this blog (e.g. email, the credit card validation service).

Disclaimer: None of the below info or details should be linked with a real life scenario or people. No real credit cards or company was used  to define this demo tutorial. 

The story, all names, characters, and incidents portrayed in this production are fictitious.  

In addition to this it looks there might be some issues with the blogger/blogspot on how the pictures are inserted and visible; worst case right-click to see the picture at its full size.

The project would have not been possible without the help of the below main resources:

• LuhnChecker web service provided by CDYNE 
• https://ccardgenerator.com  to Generate Credit Card Numbers with Complete Details
• https://www.databake.io to Generate realistic test data
• YOPMail for the Disposable E-mail Address.

The business scenario 





The flow of the project is simple: a fictive customer is using an UI to submit a request for a credit card.  The message submitted is basic info  that could be requested in such a scenario like the name, SSN, monthly payments/ expenses, education level, current occupation, income and the credit card type requested.

From here,  some fictive bank departments (implemented as 3 different employees ) will handle the request and based on some internal rules  some employees will approve or reject this request or will manually assign a credit card and the related info (number, CVV code and expiration date).
In addition there could also be an automatically reject step based on some business rule like: the monthly payments(expenses) > income and/or the customer is "Unemployed".

At the end , the customer will receive an email with the feedback: the card was approved or the card was rejected.

All this scenario will be implemented  in a BPMN flow:

To keep it simple we will use only 3 users that  will interact; each will have a specific business step to follow:

• The first employee [level1_cardofficer] will check the submitted request based on some internal rules  that are not visible in the BPMN flow. This rule is only known to the employee and there is no need to be visible in the BPMN flow. 
• The second employee [level2_cardofficer]  will manually assign a credit card and it's details (number, CVV and expiration date). More important is that this employee  has no idea about the customer's details so there is no link between the credit card and the customer.  In addition just to make sure that a valid credit card will be assigned a web service will be invoked to validate the info manually added by the employee and in case the details are wrong then the employee will need to update the info. 
• The third employee [level3_cardofficer] is the last one that will give  the OK for the request. The employee is also not able to  link the card details with the customer but can see that all previous card details are valid. The rule behind this approval step is only known to the employee and there is no need to be visible in the BPMN flow. 

In addition to the above manually approving steps, we can also define some rule like:

(monthly expenses div (estimated income div  12) * 100 > 70%  AND  "Unemployed" => REJECT


The idea should be that  a bank will not spend time to check for a request if the monthly expenses  are more than 70% of the monthly income AND the customer has no job (reflected by the "Unemployed" key word); in this scenario the request is automatically rejected and an email with this feedback is  sent to the customer.
Again, this is a fictive scenario just for us to include such a step in the flow and to describe the pattern that could be used to implement such a rule.



The users 

We will create the 3 users on the BPM domain level. Actually is about a WLS [WebLogic Server] domain since we can ignore  the BPM; it could be any WLS domain.

The 3 new users will reflect the 3 departments or the employees of the bank that should handle the card request. For this demo it will not matter if is about the employees and not some departments as groups that have assigned some real users; is a demo so we keep it simple.

Note: Make sure you use your own specific host and port; in my case is about the localhost:7011. In case you don't remember the details then check the DOMAIN_Home/config/config.xml file and search for the listen-address and the listen-port (outside of the ssl element).

Use the WLS Admin Console [ http://localhost:7011/console] -> Security Realms -> myrealm -> Users and Groups -> Users tab and add 3 new users:

• level1_cardofficer
• level2_cardofficer
• level3_cardofficer

You can use the  "welcome1" password for all of them.

















For now ignore the users; we will later use them to log In into the BPM Workspace Console [http://localhost:7011/bpm/workspace/] and before this we will add them in the BPMN  flow.


The Oracle Database tables 

Please find below the zip file that covers the 3 tables:

• DB_SQL_EXPORT.zip

For this demo we will use 3 main tables from the HR schema; use the HR schema or any other schema but the idea was to use the default well known Oracle database schema.

Before going into the full details please note the below main ideas  for situations when you use a different DB schema.

Note: However, in case a different schema will be used  then make sure you add a new Data Source and define the new DbAdapter JNDI for the different custom schema.

If the new data source was defined using "oracle.jdbc.OracleDriver" then make sure you enable the "Emulate Two-Phase Commit" option:

The above  recommendation is important to  make sure that inserts into the DB are possible.

If the "oracle.jdbc.xa.client.OracleXADataSource" option was used for the data source then there is no need to enable the above options; the option is actually no more available on the same page.

Note: If you want to use a different database, like MySQL,  then follow the already covered details from an old tutorial: "US ZIP codes web service with MySQL & GeoNames".

Now back to our HR Oracle database schema and the 2 main steps you need to implement to use this database and the schema.

There are  2 main steps:

• create the database connection-link;  this is known as a "data source".
• create the DbAdapter link to the data source. This is specific to the SOA-BPM apps. 

For all such steps you will use only the WLS Admin Console:

• http://localhost:7011/console 

 Just follow the pictures for all the below steps.

Create the data source 







Use the below main settings:

• hr 
• jdbc/hr

Since we connect to the HR schema , the user will be "hr":











If you have a different server then assign this data sources to that soa-bpm server; if you are not sure then if save also to assign the data source to all servers you have in your list:







All done!


The DbAdapter JNDI details 


Now we will go with the DbAdapter application-resource  and will make  a connection to the above data source we just created.

















Please make sure you end up using the same eis/DB/hr  text on the JDeveloper side:




The above "eis/DB/hr" is what links the JDeveloper design-time environment with the BPM domain run-time environment.

Now back to the Admin Console....





























The messages 

The entire interaction will be based on the below  message types - reflected by the below XML Schemas (xsd):

• CustomerCreditCardRequest.xsd
• CustomerCreditCardApproved.xsd
• CreditCard.xsd

Make sure to download the files and save them in a location that is "near" the location used for the future BPM project; this will save you to import them faster.


The Email account 

Don't forget to define the email account you want to be used when emails should be send.

You can choose whatever the provider you want; follow the SOA and Gmail post for both the Gmail and the Yahoo details.
Don't forget  how many requests you will want to push on the server at once since this could impact the email account - if too many requests then the server will think you  try a DDoS attack...Like I tried some time ago when I used a CSV file to automatically push more requests... but this is a topic for the next tutorial.
Once more: if emails  will be generated  then keep it simple with the amount  of them or you will have issues with the email account.


The BPM SCA project

Now that we have the messages as XSD files, the database tables defined, the data source, the DbAdapter and the email account configured on the BPM domain level we can open the JDeveloper  and start with the BPM project/application.

Let's go fast now  with an overview about the future SCA:

• Components: BPMN, Mediator, Human Tasks and Business Rule. 
• References: one external web service to validate the credit card (LuhnChecker), 2 DB links to the external Database where we will save all the credit card request details (the approved customers and the rejected customers ) and 1 default Notification service (that you don't have to bother about). So, 4 external references to... rule them all. 
• Services: one database interface (DbAdapter) and one SOAP interface.

Intro BPM Application & the Empty Composite

Open JDeveloper and select File -> New -> Application -> BPM Application:








From here provide an Application name and  a location- folder. Make sure you create some extra folders inside of a main root folder and the reason is that sometimes  when the app is removed the entire folder is also removed.
In addition, having some chain of  extra folders  can help you to place the extra  files  like the XSD files in a location close to the app folder itself.

Select "Next" and add a Project name - this will be the name you will see it once you deploy the composite so make sure the Project name is relevant  enough.



Last step: make sure you select the "Empty Composite" option. This pattern will help you to start from zero and also will help you to better understand the resources  you need to define on your " empty blank canvas".






You now have a nice empty composite waiting for you to define your future process.

There is always 1 file that you need to remember - since is the file behind the nice GUI and the file is always in the SOA folder and its name is "composite.xml":





External References

We already know  what external resources should be used so we can already add them on the canvas.

Should those be added later ? No ! And the reason is simple: the BPMN component will  use them so the external references  (as pointers to the real external services) should  be already defined and available into the composite.

Reference 1: Luhn service 

The first  one is a SOAP web service pointing to the external Luhn  service.

So, add a SOAP Technology into the External References right-side:




Here we will define a name for this service  and more important the external location as a WSDL link:

• https://ws.cdyne.com/creditcardverify/luhnchecker.asmx?WSDL

Click on "Tab" and all will be automatically added  in the Port Type and choose the SOAP option.

Note: Since the URL is using the SSL (https) don't forget to add the specific certificate into the  Binaries_Home\wlserver\server\lib\DemoTrust.jks  repository... Otherwise  you will see an "SSL Handshake" error when you try to use this project- after the deployment.
This step is only related with the BPM domain as the run-time environment and for the JDeveloper there is no need to do more than just to copy-paste the WSDL location; it will work.











Reference 2: Save the approved customers into the CUSTOMERCARDS DB table 

The next reference points to the DB Adapter (Database) technology and the idea is to save (merge) the approved customers into the specific DB table.

For this demo the table is "CUSTOMERCARDS".

You will see that is all about some Next->Next steps and to select the specific table.

There is however one very important step that you should not ignore and this is the one related with the JNDI ! No matter the connection name you use by default please make sure that the JNDI defined is the same as the one defined on the BPM domain under the DbAdapter application (from the Deployments table).





In my case the JNDI used is:

• eis/DB/hr

You can keep the same "eis/DB/hr" for all future Database References as long as the DB schema used is the same one; in my case  is about the default HR schema where I defined all my tables.

Note: A new schema = a new DB user = a new data source on the BPM domain  level = a new JNDI on the DbAdapter application (from the Deployments table). 

Now back to JDeveloper and drag and drop a Database technology into the External References,  right-side:



Define a Name - it can be whatever the name as long as you remember at the end what is all about:



The next step is to realize a DB connection by providing the user+ password (hr + welcome1 in my case):





Please pay attention at the "Connection Name" since you will have to change it soon.

Pay attention an make sure you define the right JNDI name:





From here is only Next-> Next : select the operation as Merge and the table and choose all columns from the table.







Yes, we already know what table we want to select to save all the future customers  and in this case is  the "CUSTOMERCARDS" one:













Just go with Next till the last  step:









All done !


If you check now the  composite.xml file -is actually the SCA nice canvas- you can see that the new Reference was added.




Reference 3: Save the rejected customers into the CUSTOMERCREDITREJECT DB table 

The next reference points also to the DB Adapter (Database) technology and the idea is to save (merge) the rejected customers into the specific DB table.

For this demo the table is "CUSTOMERCREDITREJECT".

You will later see that the "CUSTOMERCREDITREJECT" table has the same info/columns as the request message itself since no credit card was assigned/generated. The idea here is just to keep in a table all the future customers that requested a credit card but were rejected.  In a real life situation maybe the bank will come back to such customers for whatever the extra steps; no need to  waste time now on such a scenario.

We can call this Reference as:

• CustemerRejectDB

Below are the main steps - very much similar as the above steps on DB.




Once more: pay attention and  use the same JNDI Name:







Import the table as the "CUSTOMERCREDITREJECT" one and Next:



Since the table is not linked with a different one just select Next:




Make sure that all the columns are selected:





And from here Next till the Finish:





All done and the new Reference is now visible into the project.


Till now we had 3 external references out of 4; the last one is "BPM-NotificationService" but this will be automatically created once the Notification activity will be added inside the BPMN component.

All done with the External References and now moving forward to the  next step.

Note: Of course there could be more such External References but you always create them based on the business scenario you already know it so for this tutorial there is no need for something more.

The Components 

We start now with the components.
The main component  will be the BPMN one; all other components will   "gravitate around" the BPMN and we will see why we create them.

There will be one extra component that is not directly linked with the BPMN one and this is the Mediator; the reason for it is to "mediate" between the BPMN component and some future details that for now we will skip.


The BPMN Component 

This is the starting point about the BPMN component and when we will switch to other components we will add a new title but  at the end all future components will be linked with this BPMN section.

Just place a BPMN Component in the middle of the composite and choose a name and use the Async option:



The main feature of this Async option is the fact that at the end the BPMN component will be exposed as a web service that could be later consumed inside other projects. It is a SOAP web service.

As always we need an Input but in this case no Output; the service interface will only have an Input.




How to create an input element is  an entire journey since you will need to define a Module  (as a collection of related elements) inside  the Business Catalog (that is the repository for all Modules).

Do keep in mind that we want to have as an Input a custom message that should also be defined and created and for this we will use an XML Schema (XSD file). We will call this message type as Business Object and we will place this new message type in the new Module we defined.


To make all such details more clear  I added the specific resource name at the end of each new object created.


Since we have nothing till now,  we need to browse and first choose and define a destination Module:



We create this new Module:



We select the new Module created:




Now that we have the new custom Module we can select the "based on external schema" to define the new Business Object (aka the new message type):





Note: Unfortunately  if you just select  an xml schema and import it there is a chance for you to see errors. This is because the XML schema should be more complex and the best is to use one of the old schemas you know were safe to be used or in the worst case you define manually each element in the new Business Object as field by field.
This  type of approach is not seen  when you create a BPEL component and is only specific to the BPMN one.

Select the CustomerCreditCardRequest.xsd file:









Now that the schema itself is imported into the project , select the xml element to be used:





Now that  the Module and the XML element was defined, don't forget to change the Name for this Business Object (the message custom type) into something custom:





The last step now is to use a custom name for the Input variable-element (aka the Data Object) that has the type of the previous defined Business Object:





All  done for the INPUT details:





Since we need to return no Output we can go Next -> Next :




And Finish:




All done for now. You now have the BPMN component and, in theory, you could also  drag and drop all the known BPMN activities that reflect your known business process.
However, we still need something more on the BPMN canvas before all this.


The Roles

Since we defined some users on the BPM domain level using the WLS Admin Console (http://localhost:7011/console) we should now link the BPMN roles with such users.
Make sure that  your BPM domain is up and running by using the DOMAIN_HOME/bin/startWebLogic.cmd/sh


Select the Organisation from the BPM folder:





Here create the 3 new  Roles. In addition you could also create the "Customer" one but this riole  will not be mapped on a real user.

For each of the 3 offers use the pencil to  edit them and to link them to the specific users from the run-time domain.

Note: When you open  the Identity Lookup  window give it some time so a connection will be established in the background.
















The Customer role  could be assign to some other user or no real user:





All done here; no need for more roles for this tutorial.


Now, of course, the above roles should be  reflected also on the BPMN canvas.









































The activities, gateways and events 

Now that  we have all the main key elements we can go and drag and drop all other  activities, gateways and events based on the process we want to implement.


To keep it simple we only used the below main elements:

























In addition, also drag and  drop a Business Rule activity and for now ignore it:





Use the above elements and add them on the canvas:





The main start and stop elements are reflected in the below picture:






When you need a new  sequence flow, just right-click and choose  one of the available options - based on the type of the gateways:









Till now we have completed the main step: to define the flow-model.
This is one of the 2 main steps; understanding  your process and knowing how to implement it on a BPMN diagram.

This is a  demo tutorial so at the end the process this diagram reflects maybe is  not that relevant but at the end is close enough to  what a credit card request could be in a real life scenario.  If we want or need to change something that would be the process itself and not the BPMN diagram; this only should reflect the real life process.

Moving forward now....


The other  main step  we need now to take care is about the messages. Once the flow itself was defined then to make it run it  means we need to know what messages are exchanged at each level-activity.

We already defined a Business Object (custom message type) when  we created the BPMN component and we even created a variable of that new type. We will go back to this pattern and implement more Business Objects and for each new Business Object we will create a variable (that will have the Business Object type).

In the below steps we will end up creating more such resources but we will not use all of them. The reason is the fact that I end up creating them ... but we will still go with all such steps  just to make sure we have more such resources (new types  and variables). Maybe  when we will use them you  will  better understand why only some of them are enough to be used.


The data 


We start first by creating the new Business Objects. The Business Objects define the customer message types. That is how  the future messages should "look like".
When you install the product you could find integer, Boolean or string types but not the "Customer" type.

All the new Business Objects will be defined on the Business Catalog level and will be included in a Module - it could be an existing Module or a new one. We already created such a new Module so we will use it for all other new Business Objects.





Each new Business Object will be created based on a XLM schema (xsd file) that we need to import.

































Now that we have the new custom types  we can create new variables based on those new types.

In this case the variables  are also known as Data Objects.

We will use only  the Process data objects option.





The data objects as variables will have a name + a type so then we need to browse for the specific custom type we want.
























In addition to all the  Data Objects variables based on  Business Objects we will also need  some simple variables; the extra variables will use the basic "string" type.


At the end you should end up with something like below:




Note: Ignore the card_logo_obj; this  should not be created. However the type used was base64.


As we can see we always end up with more variables (data objects) than the Business Objects created. This is because we also need some string variables to keep the output from  some other components (Human Task and Business Rule).



The SCA External  References  and the BPMN Service Activity 


Each BPMN activity will be linked to an external Reference. Yes, is about the SCA Reference now.

If you check the composite at this stage you will notice there is no link between the BPMN Component and the External References.

Actually there should be one link pointing to the BPM-Notification Service; this was added automatically when the Email notification activity was added on the BPMN canvas.Don't touch it ! 


So,  at the end each Service activity from the BPMN level will invoke a specific Reference: the 2 DB tables merge operation (to update the specific table with the rejected or the approved customers) and also the Luhn external service that will check if a card number is valid.


Note: The pictures saved reflect the first stage of the BPMN flow; even if no clear names are used still details should be clear enough.  Please ignore the extra service activity from the Level 2.










Each service exposes only 1 operation (e.g. merge) so there should be no mistakes done.




Now check the SCA composite and see the wire created between the BPMN Component and the External Reference.












The same pattern will be implemented on the end message event:






The Data Associations

Till now we only linked the service activities with the external References-services.

The last missing step is to map the data between the IN and OUT on each service activity.


Once you open the "Data Associations" link on each activity all will be more clear. The mapping is actually very simple because you already have the variables (you also know the type of each variable) and you can also see what message each external Reference-service is using.

What you will need to realize now is what variables from our BPMN should be used as the INPUT for the external service and what variable for the OUTPUT....

To make it simple:

• the rejected customers table will be updated with exactly the same info coming from the INPUT; no updates were done on this INPUT variable. 
• the approved customers table will use exactly the same info as the one received in the INPUT of the process +  the extra credit card details  (number, CVV and expiration date )
• the Luhn service that validates a credit number needs the data from the variable that has such details + the output will be mapped on the string variable  that only need to know if the card is valid or not... but here is the catch since the Luhn service return a different data type (boolean); we only need to change this type to sting. 

And now the pictures...













For the output we will use a  function to change the boolen to string:

















The SCA Human task and the BPMN User activity 

The user activities will be linked to some Human Task components on the SCA level....
Yes; we don't have them yet but soon will be visible.

Each Human Task needs an INPUT to show on the UI page. The OUTPUT from a Human task will be a simple string like "Approve"  or "Reject".

For the first one we don't need the user to change the data submitted by the customer:

 

Since the user will paste in the UI some card details (number, CVV and exp date) we  need for the data to be editable:




The last user will only check the  details and will approve or reject them; in addition to the same main request details this user can also see that the defined card is valid (even if there is no chance to end up with an invalid card):






For each  Human Task you  will auto-generate the specific UI. Is a simple step but it needs some time if we count the number of files generated.










The Business Rule 


In addition to all the BPMN exclusive gateways we can also "outsource"  some of the validation rules to the Business Rule SCA Component.

This Business Rule was later added into the flow so if you feel that it was "squeezed into" the flow you are not wrong; the idea was to provide the main patterns to be used with this component.




























































Add one more rule for the opposite scenario; yes on the Business Rule all situations should be implemented:














The exclusive Gateway


For this gateways we only need to define the "faulted" or rejected rule on the specific branch; that is on the Condition:





(number(bpmn:getDataObject('customerCreditCardRequest_obj')/ns:MONTHLYPAYMENTS)  div (number(bpmn:getDataObject('customerCreditCardRequest_obj')/ns:ESTIMATEDINCOME) div 12)) * 100 > 70





bpmn:getDataObject('business_rule_output') = 'REJECT'





bpmn:getDataObject('level1_CardOfficer_output') = 'REJECT'





bpmn:getDataObject('valid_card_obj') = 'false'





bpmn:getDataObject('level3_CardOfficer_output')= 'REJECT'



And below is the "Unconditional" path; as we can see no need to define a rule since is the default path:






The Email 


No matter what, at the end of this process an email will be sent to our customers to let them know the request status.

Since  the input message covers no such email field details, we will "fabricate" an email address based on the name field. If for example the name is  like "John Doe" then the email address will be "John_Doe@yopmail.com".

We will use the http://www.yopmail.com service for this.
YOPmail : Disposable and Free email address.

The alternative would have been to use a real email address or to use the same email account that is actually used on the BPM domain to send the emails.

Note: Of course in a real life situation this step makes no sense since  customers will provide a valid email address.

You will still need a valid email account to actually send the future emails. You can use the Gmail or the Yahoo one or whatever other email account. In my case I used an Yahoo one.

Note: Check the old "SOA and Gmail" tutorial on how to link the BPM  domain with your Gmail or Yahoo account.

There will be 2 main patterns to use: the approved email pattern and the rejected emails pattern - based on the 2 messages we need to send.

The  email notification activity-task is all that you need:






As we can see the From, CC and Reply to  can have some hard-coded values pointing to the real account you use.

The magic will be implemented on the TO field:




Note: Please use the "insert into expression" button and use your own variable; don't copy-paste the variable from the below example. Maybe in your case a different name will be used for this variable.

The below is what it needs to be used:

concat(substring-before(bpmn:getDataObject('customerCreditCardRequest_obj')/ns:NAME, ' ')  ,  "_"   , substring-after(bpmn:getDataObject('customerCreditCardRequest_obj')/ns:NAME, ' '),  "@yopmail.com")


It looks odd and complicated but is very simple actually since is a combination of  some functions; all of them part of the "String Functions":

• concat: Returns the concatenation of its string parameters.
• substring-before: Returns a substring 
• substring-after : Returns a substring 

The variable and the message filed is only from the customerCreditCardRequest variable (the input itself sent by the customer) and is only about the "Name" filed. Between the 2 strings we will add an "_" character.

At the end we need to add the  "@yopmail.com".

Once more:  the submitted name  is John Doe  so the  address is now "John_Doe@yopmail.com".

Note: Of course  this pattern could be used even on the other fields like From, CC and Reply To.

The next step is to define now the content of this email and here we have 2 main patterns:  the  text  when the  card request was rejected and the  message  when it  was approved.

We could add here a nice design for the future emails sent and also to include as much info  based on the submitted info but for  now we can keep it simple and we will  "concat" on some  template the name and the card type requested.

Note: Yes, we will use the same "concat"  function.




concat("Hi ",  bpmn:getDataObject('customerCreditCardRequest_obj')/ns:NAME ,  ". Your request for a card " ,  bpmn:getDataObject('customerCreditCardRequest_obj')/ns:ISSUINGNETWORK , " was not approved")

Note: For the Subject you can implement the same  pattern; for now is  a  simple text.





concat("Hi ",  bpmn:getDataObject('customerCreditCardRequest_obj')/ns:NAME ,  ". Your request for a card " ,  bpmn:getDataObject('customerCreditCardRequest_obj')/ns:ISSUINGNETWORK , " was approved.")




We now covered the BPMN Component. We will close this BPMN component and we will stitch on the SCA Composite level.

The end...for the BPMN !




The Database Service (interface) & the Mediator

On the Exposed Service (interface) left-side we have only a SOAP web service option. Sure, we can use this option for some future applications to consume this BPM application as a web service.

However we can also trigger this BPM application based on some DB insert into a specific table.

We will use here the "CUSTOMERLISTINSERT" table and each insert will generate a new credit card request.

This new pattern could be used if the bank has an internal app that can communicate directly with the database and there is no need to have a web page that will invoke the BPM app as a SOAP service.


You will also see why the Mediator component should be used.


The Database interaction is not different than the old one when the Database was used as a Reference and the specific details that should be implemented when the same Database now triggers-invokes the service.








And below is where the magic happens: the Poll option















Select all:



The new row inserted will be removed:





Make sure you select the frequency:




From here is Next->Next:

















All done.


We should now link this new Service (interface) with the BPMN Component:






Hmm.... Looks we can't.... In this case: use the Mediator Component !









The Mediator Component is uses to route, validate BUT more important is used to do Transformations !
A Mediator component has at least 1 operations and this is the Transformation one.









Very much like the old "Data Association " used on the BPMN level:






The end ! 


We covered all the steps for this application.  We now can deploy it and run it .


The deployment 


Keep in mind that at the end you will deploy 2 main resources: the SCA project itself  AND also the 3 Human Taks UI ADF applications.


Right-click on the composite project and select "Deploy".
































Once the deployment is done make sure you check and if needed you change the default machine's name with the "localhost" or the host you configured  for this domain.

Is this step a must ? Yes; otherwise  in the BPM Woklist you will see nothing or an error message.


Use the EM Console:

• http://localhost:7011/em

Click on each new " Card Officer " and go to the Administration tab and make sure the "localhost" is used.





DO NOT change other  settings !  The Host Name details only should be updated !  






The BPM Worklist 

Use the below Console to handle the new tasks created: 

• localhost:7011/bpm/workspace  

You will use those 3 users to act like the bank employees.

In addition,  an Oracle Apex  UI  was created around the BPM project.

Note: Thanks to my dear friend, Roxana Chiriacescu, for the help provided with the APEX UI.  
 













Once you push the "Create" button, a credit card request is generated on the BPM side and the 3 users should now  each handle the specific tasks. 

Note: In a real life scenario you will not be able to switch between the users; each user will have its own password and its own responsibility and some tasks will be handle only by some individual employees. For this demo it looks all is a game but in a real life scenario this simple task is  nothing like a game and the employees are not playing with such data. 










This user can only see  by default the  credit card type that should be assigned. The info  related with the card are manually added and the external service will validate the credit card number. 










Since all steps are done and the request was approved, the data is  saved in the specific table and  a notification email is sent to the customer.





This info is also reflected on the bank's  internal app:





THE END ! 




Soon I will come back with a new tutorial: how to consume this BPM service using a BPEL Component  that will read a CSV file and for each row will  create a credit card request.