How to solve the Configurations’ mismatch between Build-Place and Use-Place using POSTMAN Flows in IFS Cloud

Background

Many customers are moving to IFS Cloud and many of them are focused on a fast rollout with tight deadlines and budget caps, without having the time and resources to focus on establishing good work practices like build place management etc.

This has led to customers having solutions version controlled anywhere and everywhere possible. For instance, in Azure DevOps, personal computers, SharePoint, Jira, and many more. As a result, the production environment will have the full solution, but the development environment will only have parts of it. This means developers will have an outdated baseline to work on, and consultants will not be able to set up data according to the agreed upon solution for the customer.

How do we fix this problem

#1 Let’s look at the damage and the idea behind the solution

The difference between the development environment and the production ditto is 940 configuration items, which means that establishing work practices will not be the immediate go-to solution.

IDEA – The ultimate goal is to restructure all of the configuration items into their relevant Application Configuration Packages (ACPs) according to the type. export it from production (PROD) and import it into the development environment (DEV).

Simple Solution, we just need to be smart about it 😉

#2 Clone of Configurations from Production to Development environment using POSTMAN Flows

Why POSTMAN Flows and not, Camunda Workflow, Custom events, or even a modification to the core to get this done? Well, we’ve tried it all.

Camunda Workflow – The tool would be great if there was a possibility to run it external to IFS Cloud. Using Camunda inside of IFS Cloud is a bit restricted in terms of debugging and the user experience. POSTMAN Flows if used effectively, then it could be used for data repairs as well.

Custom Events – The bad part about developing configurations for solutions like this is that you need to extend on the inside, which means you need to keep track of the solution in each of the environments after production clone. And not to forget, scaling the solution can be difficult.

Modifications – Well, modifications to IFS Core components are not possible anymore. Which strikes this out right away.

#3 Setting up the solution with POSTMAN Flows

• You will need to learn the basics of developing POSTMAN Flows. https://www.postman.com/postman/flows-snippets/flows-get-started
• A service user and IAM Client

#4 Executing the solution using a two-step approach

1. Run the POSTMAN Flow on the Production environment. To start with, you can try a development environment or UAT (User Acceptance Test) environment.
2. The Flow will restructure the Configuration Items into their relevant folders and make them ready for export.
3. Export and import them into the target development environment in the right sequence.
4. These can then be version controlled in GIT under the build or nobuild folder. Or, if you have purchased the Test Data Management Tool, import it into the QAS environment (where you store a Quality Assurance Snapshot of your data). Approve it, and thereafter every new DEV environment will have these configurations in place.

#5 Executing the solution using a one-step approach

1. Run the POSTMAN Flow on the Production environment. To start with, you can try a development environment or UAT. This time you connect one end to another. More like a data migration.

Hope you find this small teaser on how you should start building your POSTMAN Flow beneficial😉

Ready to Learn More?

Book a meeting with us today to delve deeper into these solutions and tailor them to your specific needs. Our team is here to provide insights, answer your questions, and help you implement these strategies and solutions effectively.

We look forward to helping you achieve seamless and secure IFS Cloud Application Management.