How to work with OPZ

Working with OPZ decouples the API’s startup from the OpenLegacy HUB, allowing the user to deploy the API without connecting to the OL Hub. This reduces one possible fail point for the API, but it comes with the cost of maintaining the OPZ.

Things you should always take into consideration when using OPZ:

• OPZ is static, unlike the HUB; when you generate an OPZ, it will contain a snapshot of the API’s metadata, and further changes made to the project will require the user to export the OPZ again.
• OPZ is not backward compatible. It’s important to note that when working with the OL Hub, you don’t need to worry about versioning when upgrading the project or the CLI because the Openlegacy HUB API is backward compatible. This means that when working with OPZ you should also consider the OpenLegacy API Core version, which you can view in Openlegacy Hub Compatibility. When you export the OPZ you can specify the target API version.

  ol export project --compatability-ver <OL CORE VERSION> --connection  <PROJECT NAME>
  

• Make sure the API can access the OPZ file. The OpenLegacy API needs to be configured to work with OPZ. You must modify or generate the application YAML file with OPZ to do so.
  1. Generate with OPZ:

     # Gradle build tool
     ol generate --project cics-demo --generator spring-java-rest --provider opz --license --connection
     # Maven build tool
     ol generate --project cics-demo --generator spring-java-rest --build-tool maven --provider opz --license --connection
     

  2. Update the API Application YAML (/build/resources/main/application.yml)
     • If the OPZ is inside the compiled project, you can use the following:

       ol:
         flow:
           source-provider: OL_PROJECT_ZIP
           ol-project-zip:
             path: /ol/metadata.opz # path to opz inside the project
       

     • If the OPZ is external, you can use the following:

       ol:
         flow:
           source-provider: OL_PROJECT_ZIP
           ol-project-zip:
             path: file:<path to opz in the filesystem> 
       

       If you are containerizing the API, then you should either compile the API with OPZ, and then it will collect the OPZ from the classpath, or you can choose the second option and mount the OPZ into the container either by copying it inside the container when creating the image or by using a volume.