The Build Manager handles the process of compiling the configured Integration flows into a .JAR file and packaging them into a TAR file or docker repository.
Symantec Version Controls are supported to ensure evolving GLU.Engine builds are traceable and properly version controlled and tagged. In addition, any built GLU.Engine that is for an Environment that is not flagged as the ‘Production’ environment will be tagged as a ‘SNAPSHOT’. If the built GLU.Engine is for Production deployment it will be tagged as ‘RELEASED’. The version control will then need to be incremented to make changes to a ‘RELEASED’ GLU.Engine.
The .JAR can be deployed into the Clients own Docker container or a .JAR file as a Springboot contained executable can be deployed to a server or VM.
The Test Cycle defined by the Release Manager will dictate the sequence of Environments that any particular build process will follow. The Build Manager tracks the SDLC sequence of each build doing so ensures that the applicable API / Connector environment HOST parameters are included in the build. This eliminates the need for a DevOps engineer to manually apply End-Point IP address / URL parameters to the deployed GLU.Engine. Rather all those parameters are natively included in the build by the Build Manager.
The built component can then be downloaded and deployed into the applicable server depending on the stage of the SDLC process for that particular build.
All builds going back in time are stored by GLU with full version history visible, older builds are securely archived into GLU’s long-term archive and can be retrieved via Support Desk Request.
The Build Manager has an ‘GLU.Engine Settings’ configuration panel that enables the definition of various configuration settings for any specific build to be included in that build. See the screenshot example below.
Logging related settings such as log levels, log file locations and log file names can be defined.
Java Management Extensions (JMX) properties are available through the GLU.Engine APIs. JMX provides a standard mechanism to monitor and manage applications. By default Spring Boot will expose management endpoints as JMX MBeans under the org.springframework.boot domain however since
If your application contains more than one Spring ApplicationContext you may find that names clash. To solve this you can set the endpoints.jmx.unique-names in the GLU ‘Application Settings’ property to ‘true’ so that MBean names are always unique.
If you don’t want to expose endpoints over JMX you can set the endpoints.jmx.enabled property to ‘false’.
Jolokia is a JMX-HTTP bridge giving an alternative method of accessing JMX beans. With Spring Boot you can use your application.properties, simply prefix the parameter with jolokia.config.debug property to ‘true’.
For additional detail on JMX monitoring see this resource.
Actuator endpoints allow you to monitor and interact with your GLU application. Spring Boot includes a number of built-in endpoints and you can also add your own. For example, the health endpoint provides basic application health information on your Application.
