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 and the resources that you define explicitly using API Creator.
The following image shows change management in
CA Live API Creator:
In this article:
APIs resolve onto database calls. Database changes can affect API users. The impact is different for schema resources as opposed to the resources that you explicitly define.
Schema Resources Reflect Schema Changes
Schema resources are endpoints that
CA Live API Creatorcreates from schema tables, views, and stored procedures when you create your API and connect to a database. Clients that are using schema resources see all schema changes. The tables/columns that you add might not affect applications, and renamed/deleted objects might or might not affect them, depending on whether they are referenced.
For more information about schema resources, see Customize your API.
Resources Affected Only by Changes to Referenced Objects
The resources that you explicitly define using API Creator provide a database abstraction layer, where you can choose and alias the data that you want to present and specify filters and joins. This database abstraction layer shields API users from the tables/columns that you add. These resources are not affected by the objects that you rename/delete and that the API does not reference.
For more information about these resources, see Customize your API.
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 you renamed/deleted an object, you can repair the resource by including the new column, and aliasing it to the previous name.
For more information about how to verify an API, see Database Administration.
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 that you define explicitly in API Creator,
CA Live API Creatorcreates logic-enabled row objects from request objects to provide automatic resource/object mapping. So, for example,
CA Live API Creatorenforces the addition of semantics, such as validation rules, that you add on Tuesday to a resource that you defined explicitly in API Creator on Monday, without changes. API users, API creators, and logic developers can proceed in parallel. API creators define the resources in API Creator and the 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 the logic and executes it 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 your resources.
For more information about how to version a resource, see Manage 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. This sharing addresses logic changes that occur even after you define resources.
Services for Continuous Delivery (CD) can promote Change Management (CM), simplifying the ability to move a system from development, to test, and then to production. You API definitions are settings in the admin repository. There is no code generation and no deploy. New rules and resources are operational as soon as you save them.
Test your system before going into production. Verify your API by exporting and importing your API. Scripting is a methods that you can use to export and import your API.
For more information: