RESTify Your SQL Data
RESTify Your SQL Data
Look at an example that illustrates the App Logic approach.
Join the DZone community and get the full member experience.Join For Free
Strategic Business Agility
RESTful APIs are at the heart of Digital Transformation and are required for mobile apps and integration. They are core to Business Agility. That's strategic.
But the conventional development process — create an ORM and design and code your APIs — is remarkably code-intensive and complex. And then there's the Business Logic — a substantial portion of any system — more code. Not agile.
Strategic Business Agility requires higher levels of abstraction. Instead of servers that merely execute code, we need App Logic Servers that execute logic. The vision is a business specification, readable by Business Users, executable by an App Logic Server.
Let's see how.
App Logic Approach
App Logic Servers accept and execute not just code, but logic:
- Use the App Logic Designer for point/click API creation and logic, as shown below. Your logic is stored in a source-controlled set of files.
- The App Logic Server executes your design in response to app calls. It runs in standard containers (cloud or on-premise), stateless for scalability.
Code is by exception, providing extensible access to Java and Web Services.
Sample Problem: Placing B2B Orders
Let's illustrate the App Logic approach with an order processing example.
For this example, we'll use the Northwind database.
To make things concrete, we'll utilize CA Live API Creator (LAC, Version 5, Copyright © 2019 Broadcom).
We'll create this system in minutes, not weeks.
- Partner Order: A partner places an order by POSTing to an API.
- Check Credit: As the App Logic Server persists the order, it runs some typical multi-table logic (sum the order totals into the balance, validate credit limit not exceeded, etc).
- Alert Shipper: Reformat and post the order, to alert the shipper.
Connect to Start
To get started, use LAC's UI to connect to a database.
The system uses the schema to create the elements shown below:
- Default API
- ORM and Event Model
- Default Web App
An endpoint is created for every table, view, and stored procedure. Each endpoint provides Get, Put, Post, and Delete.
Enterprise-class features (pagination, optimistic locking, filtering, sorting) are fully automated.
ORM and Event Model
The system creates an ORM (Object Relational Model): objects for every table. These objects provide accessors for attributes (note code completion), related objects (from foreign keys) and methods for persistence (create, read, update, delete).
Default Web App
The system automatically creates a multi-table, multi-screen Web App.
Separately Executable: use it for prototyping, collaboration, or back office Data Maintenance.
It uses the APIs, so logic and security are fully enforced.
Use Author Mode to control layout and style.
Now, let's see how to build our sample B2B Order Processing system.
1. Declare PartnerOrder API
The default API is helpful but rarely sufficient. We commonly need to select attributes, alias them, and join related data.
The Partner Order solution is shown, creating the
PartnerOrder endpoint via a point/click (declarative) UI.
The endpoint is fully executable, able to accept partner posts, transform the data into our schema layout, and persist it.
2. Declare Check Credit Logic
Business Logic constitutes a large portion of any business application, so it must be addressed by an App Logic solution. The Check Credit rules are shown below.
Intuitive to Business Users, the rules represent quite a different paradigm for developers:
- Concise: these 5 rules would require several hundred lines of Java or trigger code to cover all the Use Cases (insert, update, delete, etc).
- Automatic Invocation: quality is promoted since the rules are automatically invoked.
- Automatic Ordering: the App Logic server orders execution by parsing the rules for dependencies, so logic maintenance does not require manual redesign.
- Automatic Optimization: rules are pruned automatically, with SQL optimization (e.g., the sum rule adjusts the referencing data without an expensive
3. Define Shipper Alert Integration
Line 3 represents the mapping and translation logic, using the
transformCurrentRow system service, based on a
ShipperAPIDef custom endpoint, created as described above.
Conclusion — Minutes, Not Weeks
We find the LAC approach promising, which we'd like to see extended with logic for services, not just databases.
Published at DZone with permission of Val Huber , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.