Change management is a key consideration for building and maintaining systems, to provide both agility and control. This article discusses the following elements:
- API clients and how they are affected by changes to the other elements.
- Database/schema changes, such as dropping or renaming columns.
- Logic changes (reactive logic and security).
- Schema resources, endpoints thatCA Live API Creatorcreates from schema tables, views, and stored procedures when you create your API and connect to a database.For more information about schema resources, see Customize your API.
- Resources that you explicitly define using API Creator, with provisions for join and column selection/alias.For more information about how to customize your API by adding resources, see Customize your API.
The following image shows change management in
CA Live API Creator:
In this article:
APIs resolve onto database calls, so can affect clients using the API. The impact is different for schema resources as opposed to the resources that you explicitly define.
Schema Resources Reflect Schema Changes
Clients that are using schema resources see all schema changes. New tables/columns may not affect applications, and renamed/deleted objects may or may not affect them, depending on whether they were referenced.
Resources Affected Only by Changes to Referenced Objects
The resources that you explicitly define shield API clients from the following schema changes by providing an abstraction layer:
- Custom APIs are unaffected by new tables/columns.
- Custom APIs are affected by deleted/renamed objects that are referenced. The resources that you explicitly define are not affected by deleted/renamed objects that are not referenced.
You can determine the impact.
Identify the Impact to your Resources and Rules Based on Schema Change
Determine what resources (and rules) might have been affected by schema changes by verifying your API. If the objects were renamed, you can repair the resource by including the new column, and aliasing it to the previous name.
For more information about how to verify APIs, see Database Connectivity.
Best Practice: Communication, Nightly Verify
Ideally, the team that is making the schema changes advises when the changes are made. If this is not practical, you can make verifying the API part of your nightly build. This ensures that breakage is detected and can be repaired quickly.
The following sections describe how business policy changes impact your system, both API consumers and existing logic.
Do not Affect API Consumers
A key architectural goal is to provide strong Separation of Concerns (SoC) between the API interface (the data that is returned) and its semantics for logic and security. Logic/security changes are defined on the underlying tables and automatically re-used over all defined over those tables.
For example, when you make updates through the resources you explicitly define,
CA Live API Creatorprovides automatic resource/object mapping to create logic-enabled row objects from request objects. So, for example, a resource you defined on Monday, without changes, enforces additional semantics on Tuesday, such as new validations. In effect, this separation enables the following teams to proceed in parallel:
- API consumers
- API creators - explicitly define resources.
- Logic developers - define logic and security.
For more information about resource/object mapping, including how to define multiple resources on the same underlying base table, see Logic Execution.
Logic Integration: Automatic Invocation, Ordering
Reactive logic automates watch/react processing. When you add or change rules,
CA Live API Creatorautomatically invokes new logic and executes the logic in an order that reflects the dependencies discovered through logic analysis.
For more information:
Versioned API Changes
You can maintain existing interfaces while introducing new ones by versioning the resources you explicitly define.
For more information about how to version resources, see API Versions.
Resources are Logic-Aware
All resources (unchanged resources, changed resources, new resource versions) share the common underlying logic and security. The sharing is automatic, so addresses logic changes that occur even after resources are created.
Services for Continuous Delivery (CD) can promote Change Management (CM), simplifying the ability to move a system from dev to test to production. The following are the key services:
API definitions are settings in API Server's admin database. There is no code generation and no deploy. New rules and resources are operational as soon as they are saved.
Test your system before going into production. You can verify your API by exporting and importing your API. Scripting is one of the methods you can use to export and import your API.
For more information about how to export and import your API using API Creator, see Import and Export APIs.