APIs are the accepted cloud-based data access approach, supporting mobile apps, web apps, enterprise integration, and partners. But they are slow and costly to build and maintain, particularly the business logic and security. This can be as much as half your application.
In this article:
Reactive Logic and Security in Data Explorer
In Data Explorer, reactive logic and security works as follows:
- Connect and use Data Explorer. Data Explorer a running RESTful service that is a multi-table user interface (UI) and RESTful API, and includes the service and data access layer (DAL).
For more information about business logic, see the Demo API Sample.
Access Data using APIs
Most API developers agree that a service-oriented architecture (SOA) is the ideal solution for mobile database access. A REST server, delivering JSON objects, has become the common approach, servicing mobile apps, web apps, other corporate systems, and partners.
Of special interest is the business logic. In this context, a REST server provides:
- Retrieval services.GET requests assemble the desired data from the database, for example, a Customer with their Payments, Orders and LineItems, subject to security, such as only return Customers in my region, and Balances only in my district.
- Update services.PUT/POST requests send updates to API Server. API Server applies the transaction logic to ensure database integrity. For example, adding an order might require sending congratulatory emails to the sales rep and customer, a credit check service call, and ensuring the updated customer balance does not exceed the credit limit. If no validations are violated, API Server writes the results to the database.
Transactional business logic is complementary to other aspects of business logic such as workflow, decision logic, analytics, and enterprise application integration.
Live Data: Security and Integrity are Key Requirements
REST APIs are public, enabling business partner access to data. Such public APIs demand that the web services enforce your policies for security and integrity. Building a "dumb" server that provides REST access to a raw database data is not sufficient. Your API requires reactive logic for security and integrity.
But Not So Easy to Build, Particularly the Business Logic
While it is easy to see what web services do and where they fit in, it is not so easy to build them. As illustrated in the following diagram, a conventional approach involves multiple subprojects:
- A REST-services layer.To analyze the request, unpack parameters, and invoke the business and data access layers
- A business-logic layer.To execute the security and business logic
- A database layer.To perform physical read/write. For example, a Java stack might include data access objects for read/write interfaces, which invoke Java Persistence API (JPA) operations on annotated domain objects.
The most obvious point is the time and expense to build a Web services server. The service and data layers are tedious, but the real work lies in the business logic layer:
- Business logic must be enforced over multiple use cases.
- The credit limit check logic must be applied to other transactions such as changing order LineItems and re-assigning orders to a different customer.
- Each use case must address complex, multi-table dependencies.
- Code is slow to build and costly to maintain, often requiring a different skill set. This is more than an IT problem. It can represent a brake on the business.
- Code is manual. There are inevitable quality issues. Was the discount applied to changed orders, not just new ones? It is difficult to establish compliance to regulations or company policy.
- Code is not transparent. There is no common business/IT language to address requirements risk.
Live data means you connect to get an operational user interface and default RESTful API and define the following:
- Resource definitions.Reduce latency and provide application-friendly document-model JSON results by defining multi-table resources.
- Security.Fine-grained authorizations that control access down to the row and column level by defining role-based authorization for each table.
Until now, organizations had to put up with manual approaches, suffering excessive time and expense, with poor agility and transparency. After all, it is business logic, surely it must require domain-specific code. Not any more.
The following diagram illustrates an example of executable logic from the cocktail napkin:
You declare your business logic as a series of spreadsheet-like expressions (rules). These expressions automate complex multi-table transaction logic. The rules are simple and transparent to server as a communication bridge between IT and business users. They are also powerful. For example, the five rules would require hundreds of lines of code in a conventional approach.
The expressions address:
- Derivations, including multi-table derivations, such as the customerbalanceandamountTotal.
- Validations, such ascheckCredit.
- Actions, such as auditing, cloning, sending email, and copying data.
Logic declarations are non-procedural, business-oriented statements of
.You might regard such logic as the requirements document ordinarily input to the development process (architectural design, detail design, coding, and testing).
For more information about how to declare your business logic, see Logic.
Automation means that API Server directly executes the business-oriented logic declarations. This ensures database integrity, based on clear and concise statements that serve as both transparent documentation and maintainable implementation.
- Enforcement is active. API Server executes your logic on every REST-based transaction. Database integrity is not dependent on remembering to invoke the logic before updating the database.
- Re-use is automatic. For example, the rules conceived for Place Order are automatically applied to Change Order Line Items, Re-assign Order, etc. Logic is defined for "base resources", so is automatically applied for all resources previously defined.
- Multi-table dependency management is automatic, so maintenance is simply changing the logic. Unlike manual code, the system recomputes a correct order of operations based on dependencies.
- Optimizations are automatic, so logic is pruned based on actual updated data. SQLs are optimized for aggregate operations by using one row "adjustment" updates, rather than expensive aggregates which may be chained.
While this example is simplified for communication, logic is quite powerful. For example, it requires only a few specifications to perform auditing, or even complex logic such as a deep copy or a bill of materials explosion. You can extend the logic.
For more information:
End users are authenticated when they log in to API Creator. The authentication authorizes them to access information per the roles they play. Administrators can define role-based authorization for each table, including:
- Predicates that control which rows are returned.
- Columns specifications that allow you to enable, for example, only managers to see salaries in their department.
CA Live API Creatorenforces the underlying security provisions regardless of which defined resource is used.
For more information about authentication, see Authentication.
CA Live API Creatorprovides significant advantage to your project in automating your REST Web services, with unique automation for business logic and security.
CA Live API Creatorfits into your existing architecture, is extensible, and is crafted for performance.