Architecture‎ > ‎

Service Invocation

Service Invocation is an integral part of a Services Oriented Architecture.  Business Logic Extensibility enables you to invoke services from Business Logic Methods, as illustrated in this example.

Business Requirements

We presume that customers apply for a Sale, supplying an amountRequested and a series of Credit Accounts identifying their Bank and customerAccountNumber.

These are input (e.g., via a user interface) to the Approval Process.  The business logic requirements are to
  1. For each Credit Account, invoke a Bank Web Service.  We supply the Credit Account Number, and the Web Service returns the Amount Approved

  2. Compute the Total Amount Approved, by totaling the Amount Approved for each Account

  3. Compute the Approval Summary, by comparing the Amount Requested to the Total Amount Approved

In this particular example, Web Services are invoked synchronously.   Asynchronous processing would present a more complex problem, dependent on the actual Web Services implementations.  (Please contact us if your system includes such requirements - we would be happy to review it with you).


Stub for Service Proxy

We want to be able to run this sample without requiring complex internet connections, so we provide the stub shown below.

In actual practice, you would typically use commonly available tooling to create a Java proxy from your Web Service Definition Language file.  We presume our WebService takes an input parameter of the customerAccountNumber, and returns a Response Bean BankCreditApprovalResponse, which includes the attribute amountApproved.

In the code shown below, our simulated Web Service simply computes the amountApproved which we have embedded in the customerAccountNumber.   So, for example, supplying a customerAccountNumber of "=50" returns a BankCreditApprovalResponse.amountApproved of 50.




Database Design

The database design is illustrated below.  (Note: Bank.serviceName is not used - it is provided to suggest generalize the service invocation using reflection).



Logic Design

The entire logic is based on the Request pattern, and is shown in the screen shot below.

  • SaleCreditRequest#requestAction

Generalization

A production implementation may wish to generalize the transfer of attributes from the Response Bean to the Request object, perhaps using approaches similar to com.autobizlogic.abl.businesslogic.InsertIntoFrom - see copyAttributesFromTo

You can find this in the BusLogicExt project, available in your download.
This action rule runs in response to any insert, update or delete of a 
SaleCreditRequest.  The logic simply invokes the stub proxy, and copies the Response Bean attributes to the SaleCreditRequest attributes.

  • Sale#totalAmountApproved
Totals all the amountApproved results

  • Sale#approvalSummary
Computes whether the Sale is approved, by comparing amountRequested and totalAmountApproved



Logic Execution

The log is attached - you can study it to gain a better understanding of the logic execution.

Sample Installation

Version Alert

This sample requires ABL 2, the current download.  Moreover, it depends on a properly renamed SnapShotDB as provided on builds on or after: Business Logic Configuration: ABL 2.0 - build 0413 (2012-02-03-04-30)

If your ABL 2 build is prior to that, you will need to alter the SnapShotDBj references.

To install the sample:

  • Product Installation: install the download.
  • Download and unzip PointOfSale.zip, below
  • Import>Existing Project into the workspace you created from product installation

To run the sample, debug SaleInsert (a jUnit test utilizing SnapShotDB) as illustrated below:




ċ
PointOfSale.zip
(346k)
Val Huber,
Feb 7, 2012, 9:56 AM
ċ
PointofSaleLog
(12k)
Val Huber,
Feb 4, 2012, 9:40 AM
Comments