Docs‎ > ‎Reactive Logic Tutorial‎ > ‎

Business Logic Demo

This page uses a small but representative sample application (shown at right), to demonstrate how API Creator enables you to eliminate a significant obstacle in building and running modern systems for integration and mobile data access.

Problem: Servers are hard to build - particularly the business logic

REST/JSON Servers are the accepted approach for mobile app access to integrated data. But these are slow and complex to build. In a Java stack, you might need to use Jersey, Jackson, JPA etc.

Such frameworks can reduce coding, but these are complex and time-consuming. And worse, they don't address Business Logic and Security, which can comprise significant effort.

So we pose the question:

What is the absolute fastest and easiest way 
to build a REST Server?

Instant API - API Creator

The Espresso Logic Short Video demonstrates building a server in about five minutes that would otherwise require weeks. It's further described in the following sections. 

The business logic requirements, which can be expressed in five lines, clear to IT and business users alike, require hundreds of lines of code to implement. So, make the requirements executable. Provide a Logic Designer that accepts spreadsheet-like expressions that express what your data means - how it is computed, validated, including actions (auditing, deep copy, etc), and so forth. Provide an API Creator that directly executes this spreadsheet-like logic on all RESTful update requests (PUT, POST and DELETE).

Sample Problem

To make things more definite, we'll use a familiar sample problem: Customers, Orders, Items and Parts. The following image shows the basic schema (click thumbnail for full screen). You might provide a user interface (using the Data Explorer), or use JavaScript/HTML5 to build a user Interface.

For more information:

1 - Expose Database Tables as REST Resources

To build a REST server, we connect API Creator to our database. Since it's a service, there's no installation / configuration hassles. It is all done through the browser, using the Browser.

This automates our Web Service Layer and our Data Access, so you are up in seconds. Our tables, views and Stored Procedures are REST Resources. We can build client apps for "admin" tables that do not require logic or retrieval with related data. Even faster, we can test them with the Rest Lab without writing a program.

The Logic Sample database is automatically created in your account. You can examine (or repair!) it using the Logic Demo zip file.

For more information:

Custom Multi-Table REST Resources

If we use these resources for presenting related data, there will be one message for each table (Customer, Order, Items). That can result in latency and affect performance. The following image shows the resource properties page:

You can define custom, multi-table resources that deliver such data in a single JSON response. Simply select the tables. The system defaults the SubResource join (Customers/Orders) from the Foreign Key Validations.

You can control which attributes are returned to the client, their alias names. You can also define Resources using JavaScript. After you define your Resource, you can test it in the Rest Lab (click the thumbnail):

Automation includes support for enterprise-class level services such as pagination, optimistic locking, and change summary information for client refresh.

For more information:

Business Logic must be addressed

The real work involves the business logic. Let's see why by considering Place Order. The following image shows the use case and dependencies:

Analysis reveals we need to check credit. The balance cannot exceed the credit limit, where the balance is the sum of the unpaid order totals, which is the sum of the Line Item amounts, derived as the quantity times the parts' price. This is a nice clear requirements spec. But it represents quite a lot of business logic.

First, we must identify all the related Use Cases that must also respect these rules. If we miss one, serious bugs will result. Each of these must be then designed for change detection, and propagation to dependent data. And optimized. Pretty soon, the simple five-line spec becomes 500 lines of code. And yet, the requirements, as illustrated with the venerable cocktail napkin, were so simple. If only they were executable...

2 - Declare your Business Logic

Presumptions can hide opportunities. Consider the presumption that domain-specific logic requires domain specific code. It's a big assumption. We're talking 500 lines of code. That's weeks of work to build and test, and a huge web of dependencies to maintain. That's not fast, and it's not simple.

What if, instead of programming our server for each Use Case/dependency, we could just directly enter the requirements from the cocktail napkin?

Now that would be simple and fast. And it's exactly what you do. The previous image shows all the logic required to supplant 500 lines of code. You can explore logic. Note the multi-table derivations, such as the customers' balance. You can chain the derivations and use them in related logic (used by the credit limit check, uses the amount_total result). They are optimized to eliminate and simplify SQL access.

For more information about exploring logic, see Specify your Business Rules.

3  - Declare Security for a Public API

We are very nearly done. To make our API public, we require fine-grained security down to the row- and column-instance. You can define one or more roles for a user. Roles are powerful: you can associate roles data rows in your database, and use their column values to filter queries against other tables. For example, you might filter orders for a sales rep to just the ones assigned to them, without the ability to alter the paid flag. As with logic, security is point and click, not code.

For more information about an example of filtering orders, see Demo API Security.


  • API Creator fits into your Enterprise/Web Architecture, with enterprise-class support for pagination, optimistic locking and refresh.
  • We did not write any code. Not for request handling, database access, or business logic. But we can if necessary. You can extend the logic using server-side JavaScript, so scales to complexity (for example, a Bill of Materials explosion with four rules).
For more information about how the logic scales to complexity, see the Reactive Logic Tutorial.
  • We solved all the Use Cases. Even though we targeted only Add Order. Re-use and quality are automatic.
For more information about re-use and quality, see Specify your Business Rules.
  • The logic is unordered. Live API Creator takes care of the order through logic dependency analysis. This is repeated on every change, so maintenance is simple - just change the logic.
For more information about how Live API Creator uses 
  • We did not optimize our logic - that is also the system's responsibility. So our logic is pruned based on actual changes, and SQLs are eliminated / optimized to reduce server traffic. As for ordering, these optimizations are repeated on each change.
  • Our logic is transparent - business users can read it and spot errors/omissions. So we finally have a common business/IT language, that is both transparent documentation and maintainable implementation. A corporate asset.
  • You can debug your server using API Creator.
For more information about the API Creator tools to debug your server, such as:
Subpages (1): Demo API Security