App Connect

 View Only
  • 1.  Policy project type vs policy bar file

    Posted Mon July 22, 2024 09:03 AM

    Has anyone used a bar file on openshift (or maybe ACEaaD) to deploy policies in stead of using the policy project type configuration resources?

    I'm wondering what the added benefit of the policy project type is.

    Policy project type

    You need to zip an entire policy project, base64 encode it, and add it to a configuration resource

    Policy bar file

    Build the policy project as a bar file and reference your application to include the bar file. When working from a build pipeline this seems to be way easier to do.

    Anyone have any experience with this?



    ------------------------------
    Regards
    Matthias Blomme
    ------------------------------


  • 2.  RE: Policy project type vs policy bar file

    Posted Tue July 23, 2024 01:58 AM

    I thought you'd just reference the policy project and it would be added to your bar file? Would that not work for your pipeline?



    ------------------------------
    Francois Brandelik
    ------------------------------



  • 3.  RE: Policy project type vs policy bar file

    Posted Tue July 23, 2024 02:05 AM

    Then you are referencing a policy project, not something you would do by default. Not me anyway.

    I don't like combining stuff in one bar file, if it's a shared policy project with mq connections or something, you might not want that.

    But my question stands, what is the benefit of the policyproject type?



    ------------------------------
    Regards
    Matthias Blomme
    ------------------------------



  • 4.  RE: Policy project type vs policy bar file

    Posted Tue July 23, 2024 07:39 AM

    One advantage is that it provides clearer decoupling of the integration logic in the BAR file from the configuration used by the integration. It enables you to keep the BAR file as a resource that you promote between environments (development -> test -> production) without modifying, and you can have the configuration separate that may be different in each environment - i.e. referencing test endpoints of credentials in lower environments and production system details for production.



    ------------------------------
    Martin Ross
    IBM
    ------------------------------



  • 5.  RE: Policy project type vs policy bar file

    Posted Fri August 23, 2024 04:01 AM

    This has my preference as well. Keeping code and config separate and working with a single artifact.

    But, if you have a buildpipeline where you also check the health of an application by spinning it up, you do need stuff like mq policies if you have mq nodes. In that case you would also need the policies inside your build pipeline and not just as cr's on openshift. From that point of view the bar file would be more interesting.

    Currently I'm using zips of policy projects to generate policy project cr's and I'm deploying those zip's in my pipeline as well, combine code and config in the test steps. After all, the only difference between bar and zip is the meta-inf dir :)



    ------------------------------
    Regards
    Matthias Blomme
    ------------------------------



  • 6.  RE: Policy project type vs policy bar file

    Posted Tue July 23, 2024 09:48 AM
    Hi Matthias,
    As described in the below image if you want to override policies without affecting the existing application bar file, then creating configuration for policy project is helpful.
    Policy Project Configuration Description
    Scenario 1:
    When you package your application and policy project into a single bar file, after the deployment both artifacts (application and policy project) are present in "run" folder (see below image).
    Scenario 2:
    When you package only the application in the bar file and create a policy project configuration in your pipeline, then the unzipped policy project with all of its content is present in "overrides" folder (see below image).
    As you have mentioned, one of the use case could be if there is common policy such as MQ/Kafka connection policy and if it is used by many applications then creating a single configuration for this policy project would suffice and all the dependent applications can refer this policy. If there is a change in the connection details, only policy project will be affected and all the dependent applications integration server pods are only required to be restarted to pick up the latest policy change, no bar file rebuild is required.


    ------------------------------
    uvaise odam
    ------------------------------



  • 7.  RE: Policy project type vs policy bar file

    Posted 10 days ago

    We used one MQ policy for multiple integration servers. hence any update on MQ policy value, we can manage by policy project.

    Also, if we use multiple bars for an integration server, then keeping the MQ policy separate should be better option.

    I think MQ policy configuration is not giving much benefit if we create one bar for one integration server. As, the change in MQ policy does not occur frequently.



    ------------------------------
    Somnath Ghosh
    ------------------------------