Onboarding a Spring Boot based REST API Service
This guide is part of a series of guides to onboard a REST API service with the Zowe API Mediation Layer. As an API developer, you can onboard your REST API service built with the Spring Boot framework with the Zowe API Mediation Layer.
Note: Before API ML version 1.2, the API ML provided an integration enabler based on Spring Cloud Netflix components. From version 1.3 and later, the API ML uses a new implementation based on the Plain Java Enabler (PJE) that is not backwards compatible with the previous enabler versions. API ML core services (Discovery Service, Gateway, and API Catalog) support both the old and new enabler versions.
Tip: For more information about how to utilize another onboarding method, see:
- Onboard a REST API service with the Plain Java Enabler (PJE)
- Onboard a REST service directly calling eureka with xml configuration
- Onboard an existing REST API service without code changes
#
Outline of onboarding a REST service using Spring BootThe following steps outline the overall process to onboard a REST service with the API ML using a Spring Boot enabler. Each step is described in further detail in this article.
Configuring your Spring Boot based service to onboard with API ML
(Optional) Validating your API service discoverability
(Optional) Troubleshooting
#
Selecting a Spring Boot EnablerAdd a dependency on the Spring Enabler version to your project build configuration that corresponds to the Spring Boot version that you use for the whole project:
- onboarding-enabler-spring-v1
- onboarding-enabler-spring-v2
Note: The process of onboarding an API service is the same for both Spring Boot enabler versions.
#
Configuring your projectUse either Gradle or Maven as your build automation system to manage your project builds.
Note: You can download the selected enabler artifact from the Zowe Artifactory for latest stable versions.. Alternatively, if you decide to build the API ML from source, it is necessary to publish the enabler artifact to your Artifactory. Publish the enabler artifact by using the Gradle tasks provided in the source code.
#
Gradle build automation systemUse the following procedure to use Gradle as your build automation system.
Follow these steps:
Create a
gradle.properties
file in the root of your project if one does not already exist.In the
gradle.properties
file, set the URL of the specific Artifactory containing the SpringEnabler artifact.Add the following Gradle code block to the
repositories
section of yourbuild.gradle
file:In the same
build.gradle
file, add the necessary dependencies for your service. If you use the SpringEnabler from the Zowe Artifactory, add the following code block to yourbuild.gradle
script:Use the corresponding artifact according to the Spring version you are using.
For Spring boot version 2.1.1, use the following artifact:
For Spring boot version 1.5.9, use the following artifact:
Notes:
- You may need to add additional dependencies as required by your service implementation.
- The information provided in this file is valid for
ZoweApimlVersion 1.3.0
and above.
In your project home directory, run the
gradle clean build
command to build your project. Alternatively, you can rungradlew
to use the specific gradle version that is working with your project.
#
Maven build automation systemUse the following procedure if you use Maven as your build automation system.
Follow these steps:
Add the following XML tags within the newly created
pom.xml
file:Tip: If you want to use snapshot version, replace libs-release with libs-snapshot in the repository url and change snapshots->enabled to true.
Add the proper dependencies
2.1 For spring version 2.1.1, use the following artifact
2.2 For spring version 1.5.9, use the following artifact
In the directory of your project, run the
mvn clean package
command to build the project.
#
Configuring your Spring Boot based service to onboard with API MLTo configure a Spring Boot based service, it is useful to first understand how API ML enabled service Spring Boot based configuration relates to configuration using the Plain Java Enabler.
Spring Boot expects to find the default configuration of an application in an application.yml
file that is placed on the classpath. Typically application.yml
contains Spring Boot specific properties such as properties that are used to start a web application container including TLS security, different spring configuration profiles definitions, and other properties. This application.yml
must contain the Plain Java Enabler API ML service configuration under the apiml.service
prefix. The API ML configuration under this prefix is necessary to synchronize the configuration of apiml.service
with the spring server
configuration.
Configuration properties belong to two categories:
- Service related properties which include endpoints, relative paths, or API documentation definitions.
- Environment related properties which include host names, ports, context etc.
Execution environment related properties should be provided by additional configuration mechanisms that are specific to the target execution environment. Execution environment related properties for development deployments on a local machine differ with those properties on a mainframe system.
In a development environment, provide execution environment related properties in an additional
YAML
file with the system property in the following format:On the mainframe system, provide additional configuration properties and values for existing configuration properties through Java system properties.
Execution environments for local development deployments and mainframe deployment are described in detail later in this article.
Follow these steps:
Provide a configuration section for onboarding with API ML in the
application.yml
file.If you have already onboarded your service with API ML, copy and paste the contents of your existing API ML onboarding configuration file. The default of the API ML onboarding configuration file is the
service-configuration.yml
in theapplication.yml
file under theapiml.service
prefix.If you have not yet onboarded your REST service with API ML, use the Sample API Onboarding Configuration to get started.
If you are reusing your existing API ML onboarding configuration, modify the API ML related properties of the
application.yml
file.a) Remove certain properties under the
apiml.service
section, which must be externalized. Properties for removal are described in the following sample of API ML onboarding configuration.b) Provide the following additional properties under the
apiml
section:These additional properties are contained in the following sample.
#
Sample API ML Onboarding ConfigurationIn the following sample API ML onboarding configuration, properties prefixed with ###
(3 hashtags) indicate that their value must be provided as -Dsystem.property.key=PROPERTY_VALUE
defined in the mainframe execution environment.
The -Dsystem.property.key
must be the same as the flattened path of the YAML property which is commented out with ###
.
These properties must not be defined (uncommented) in your default service YAML configuration file.
Example:
In this example from the YAML configuration file, when the application service is run on the mainframe, provide your mainframe hostname value on the Java execution command line in the following format:
Since this value is provided in the Java execution command line, leave the property commented out in the application.yml
.
For development purposes, you can replace or add any property by providing the same configuration structure in an external YAML configuration file. When running your application, provide the name of the external/additional configuration file on the command line in the following format:
A property notation provided in the format -Dproperty.key=PROPERTY_VALUE
can be used for two purposes:
To provide a runtime value for any
YAML
property if${property.key}
is used as its value (after:
) in the YAML configuration file.Example:
To add a property to configuration if the property does not already exist.
Example:
Note: System properties provided with -D
notation on the command line will not replace properties defined
in any of the YAML configuration files.
#
API ML Onboarding Configuration SampleOptional metadata section
Tip: To determine if your configuration is complete, set the logging level to debug
and run your application. Setting the logging level to 'debug' enables you to troubleshoot issues with certificates for HTTPS and connections with other services.
- Provide the suitable parameter corresponding to your runtime environment:
For a local machine runtime environment, provide the following parameter on your command line:
At runtime, Spring will merge the two
YAML
configuration files, whereby the properties in the external file have higher priority.For a mainframe execution environment, provide environment specific configuration properties. Define these configuration properties and provide them using Java System Properties on the application execution command line.
Important! Ensure that the default configuration contains only properties which are not dependent on the deployment environment. Do not include security sensitive data in the default configuration.
Note: For details about the configuration properties, see Configuring your service in the article Onboarding a REST API service with the Plain Java Enabler (PJE).
#
Custom Metadata (Optional) Additional metadata can be added to the instance information that is registered in the Discovery Service through the customMetadata
section. This information is propagated from the Discovery Service to onboarded services (clients). In general, additional metadata do not change the behavior of the client. Some specific metadata can configure the functionality of the API Mediation Layer. Such metadata are generally prefixed with the apiml.
qualifier. It is recommended to define your own qualifier and group the metadata you wish to publish under this qualifier. The following parameter is an example of custom metadata.
#
Api Mediation Layer specific metadatacustomMetadata.apiml.enableUrlEncodedCharacters
When this parameter is set totrue
, encoded characters in a request URL are allowed to pass through the Gateway to the service. The default setting offalse
is the recommended setting. Change this setting totrue
only if you expect certain encoded characters in your application's requests. Important! When the expected encoded character is an encoded slash or backslash (%2F
,%5C
), make sure the Gateway is also configured to allow encoded slashes. For more info see Installing the Zowe runtime on z/OS.
#
Registering and unregistering your service with API MLOnboarding a REST service with API ML means registering the service with the API ML Discovery service. The registration is triggered automatically by Spring after the service application context is fully initialized by firing a ContextRefreshed
event.
To register your REST service with API ML using a Spring Boot enabler, annotate your application main
class with @EnableApiDiscovery
.
#
Unregistering your service with API MLUnregistering a service onboarded with API ML is done automatically at the end of the service application shutdown process in which Spring fires a ContextClosed
event. The Spring onboarding enabler listens for this event and issues an unregister
REST call to the API ML Discovery service.
#
Basic routingBasic routing is based on the service ID and API version that are used to identify the service. The specific instance is selected by the API Gateway. The response needs to be the same for all instances. This is the type of routing that is expected by Eureka and Zuul.
Gateway URL format:
Example:
The original URL of a resource exposed by a service
API Gateway URL of the resource
Note: The URL identifies the resource. It does not uniquely identify the instance of the same service when multiple instances are provided by the same service (i.e. service is running in HA mode). Services of the same product that provide different resources (e.g. SYSVIEW on one system and SYSVIEW in a different sysplex) cannot have the same service ID.
In addition to the basic Zuul routing, the Zowe API Gateway adds support of versioning where a major version can be specified. The Gateway routes request only to an instance that provides the specified major version of the API.
The /api/ prefix is used for REST APIs. The /ui/ prefix is used for web UIs, and /ws/ prefix for WebSockets.
#
Adding API documentationUse the following procedure to add Swagger API documentation to your project.
Follow these steps:
Add a SpringFox Swagger dependency.
For Gradle, add the following dependency in
build.gradle
:For Maven, add the following dependency in
pom.xml
:
Add a Spring configuration class to your project.
Example:
Customize this configuration according to your specifications. For more information about customization properties, see Springfox documentation.
#
Validating the discoverability of your API service by the Discovery ServiceOnce you build and start your service successfully, you can use the option of validating that your service is registered correctly with the API ML Discovery Service.
Validating your service registration can be done in the API ML Discovery Service and the API ML Catalog. If your service appears in the Discovery Service UI but is not visible in the API Catalog, check to make sure that your configuration settings are correct.
Specific addresses and user credentials for the individual API ML components depend on your target runtime environment.
Note: If you are working with local installation of API ML and you are using our dummy identity provider, enter user
for both username
and password
. If API ML was installed by system administrators, ask them to provide you
with actual addresses of API ML components and the respective user credentials.
Tip: Wait for the Discovery Service to fully register your service. This process may take a few minutes after your service was successfully started.
Follow these steps:
Use the Http
GET
method in the following format to query the Discovery Service for your service instance information:Check your service metadata.
Response example:
Check that your API service is displayed in the API Catalog and all information including API documentation is correct.
Check that you can access your API service endpoints through the Gateway.
(Optional) Check that you can access your API service endpoints directly outside of the Gateway.
#
Troubleshooting#
Log messages during registration problemsWhen an Enabler connects to the Discovery service and fails, an error message prints to the Enabler log. The default setting does not suppress these messages as they are useful to resolve problems during the Enabler registration. Possible reasons for failure include the location of Discovery service is not correct, the Discovery Service is down, or the TLS certificate is invalid. These messages continue to print to the Enabler log, while the Enabler retries to connect to the Discovery Service.
To fully suppress these messages in your logging framework, set the log levels to OFF
on the following loggers:
Some logging frameworks provide other tools to suppress repeated messages. Consult the documentation of the logging framework you use to find out what tools are available. The following example demonstrates how the Logback framework can be used to suppress repeated messages.
Example:
The Logback framework provides a filter tool, DuplicateMessageFilter.
Add the following code to your configuration file if you use XML configuration:
Note: For more information, see the full configuration used in the Core Services in GitHub.