Need a good general strategy for updating components that use non built-in Application parameters so that they can be shared

[Anon Anon]

We have several components that currently use non built-in application parameters that we want to convert into shared components. The number and use of non built-in application parameters being used is fairly high. I'm looking for an efficient strategy for converting the components over to using component parameters. Application parameters were originally used because their scope being broad enough to use the same parameter in multiple components, processes and steps without having to duplicate them and find ways to repeatedly set their values over and over again.

 

Does anyone have any good suggestions? I assume we are not the first to run into this problem.

[Michael Gebhardt]

no, you're not the first, we had the same issue, as we started our first designs with application parameters and then wanted to share them, only to see, that we can't do it

 

so, you do have a lot of work ahead of you and sadly, there is no real "efficient" way to do it, at least we didn't found one

 

things to do:

- I think there is an option, that you can move paramaters from application to component level

- you need to update your "roc - update parameter" actions for the changed path and also the server type now needs to be in it. this was the most annoying part for us, as we have a very generic approach on our design, so we needed to get all those out of parameters, luckely we had them already in some places, so it was just a bit reorganising.

- watch out for parameters, that might need to be set multiple times now, e.g. if you need a parameter in deployment steps and in the post-deployment

 

but yeah, we aslo needed to duplicate some parameters while moving to shared components, so there might be no way around that part as well

[Anon Anon]

Thanks for the feedback Michael. I've been wondering if it would be possible to create a component specifically to export and import other component level parameters at the beginning and end of each process as a method of persisting parameter values across processes/deployment steps. I haven't tried anything or done any real digging yet, so I don't know if the idea is even feasible.

[Chip Rabinowitz]

I’ve done something similar to that before, Mark…….

 

Lots of hand manipulation, and I can show you some techniques……basically a lot of copy and paste ☺

 

But it really works well when you have a lot of common component-level parms and actions…..

 

Chip Rabinowitz

Senior Enterprise DevOps Architect

A&I Solutions

702-443-7520

[Anon Anon]

Chip, I'm going to need those techniques you mentioned.

 

I have come up empty with respect to a useful approach for exporting and importing all component parameters to pass them from one process to another. The "ROC - Get All Parameters" action does not work the way it's name, or even documentation suggests (ROC - Get All Parameters retrieves nothing ). Also, there are no API calls to allow us to get component level parameters without already knowing what they are.

[Michael Gebhardt]

we're currently implementing a new approach where we use a config file with a key-value pair list and using that in the predeployment to update all parameters for the components used for the deployment steps. we have the feeling, that it is really flexible but it does include a lot of strictly sticking to naming conventions regarding the component, server type and deployment step names.

 

don't know though, if this helps you in any way.

 

in the end, you will need to have those user input parameters somewhere, that you update from the predeployment or you're doing the config in the deployment steps themselfs, so that every component/step knows from where or how to grab needed parameters. we prefer the first one, that everything is configured within the predeployment