When it comes to Governance and Lifecycle Management, Adeptia provides multiple features as part of its solution for managing services and controlling the promotion of services from Development to QA to Production.
Let’s first discuss the features of Service Repository. Adeptia Solution comes with an embedded Service Repository that allows developers to implement services and store them as individual services or as a collection into the repository.
Service Repository also functions as a registry for developers to easily manage, view and share services in their ESB implementations initiatives or as part of a particular integration project.
– Individual Services
- Services: Developers can store individual services into the Adeptia Service Repository. These include Data Transformation Maps, Data dictionaries/layouts, Security services (encryption/decryption keys), Web Service Consumer services, Published APIs, Orchestration events, scheduled batch jobs, custom plugins, database and MQ endpoints, Service documentation, Service security policies and application connections etc.
– Collections
- Projects: Developers can group all the services into projects for easy management of resources and these can be stored into the repository.
- Groups: Group of developers can build services and group them into an overall Group entity. Group can have multiple projects and these can be stored into the repository.
Lifecycle Governance around service development and promotion consists of the following features.
– Service Versioning
- Developers can check-in all the Services into SVN and maintain multiple revisions and have the option to checkout an older revision.
- Each Service revision is tagged with date and timestamp and developer comments describing the revision.
– Service Promotion
- Adeptia provides a full-service promotion capability where developers can select the services that are tagged for QA or Production and easily promote these services into different environments. As an example, all the checked-in services into the SVN can be moved from the development environment to QA and Production through the Adeptia migration utility.
– Service Dependencies
- Managing service changes is also an important part of Lifecycle Governance where developers need to identify what other services would be impacted when a particular change is made to a service. Adeptia provides a Dependencies module in each service object that lists out all the dependent services that can be affected by the change. An example can be a data transformation service that is being used in multiple APIs or process orchestrations, or a data layout that is being used in multiple transformation maps and APIs or a database endpoint being used in the multiple integrations flows.
– Service Permissions
- One of the main features of Lifecycle Governance is the ability to control the use of service by other developers. As an Owner of the entity you have all the permissions to View, Edit, Execute a service and you can extend these rights to other developers. For example, an API can have a share permission of View and Execute that allows other developers in Adeptia to view the contents of your API configuration and use it in their own service development initiatives but without the ability to change any of the service configurations. If the owner provides View, Edit, Execute permissions then any user in the Group can use the service as well make changes to the service configuration.
– Service Documentation
- Key part of any service development is to document the service configuration and policies into a shareable document. Adeptia self-documents major service configurations automatically into PDFs. These include Data Mappings, Process Flows (Pipelines) and Process Models.
Adeptia Solution follows a zero-code approach for message mediation and enterprise integration. Adeptia’s runtime behavior is decided by its metadata services that are configured by developers at design-time. These metadata artifacts can be the entire process flows (pipelines) or they can be individual artifacts (micro-service) representing a map or a data schema layout, application connections, endpoints etc. As a result, a developer can keep separate metadata configurations for each service and manage these services as part of the service governance framework.