Thx that seems like the route i wanted to take. But one of the issues I ran into going that way is how to properly manage your policy files when you have separate values for different integration servers. Since the database policy has to be included in your default policy projects you cannot duplicate the policy and store it in separate policy projects. Combine this with the fact that you sometimes have to remove all your resources if you update a given policy file so where do you store the different values for each environment? You could create separate bar files for each environment, but then there is no way to tell what the configuration of a given bar file is without loading the actual file.
------------------------------
Pieter van de Braak
------------------------------
Original Message:
Sent: Tue August 17, 2021 04:06 AM
From: Martin Boag
Subject: Best practice for using the database mapping in a DTAP environment
Hi
I would assume that the database server in your dev, test and production environments is a clone. As such you should not have to alter your flow, just configure the Integration Server to connect to the relevant server, which can be done via the JDBC Providers policy. There should be no need to rerun the database discovery in the Toolkit to update the Mapping.
For the Mapping node, the name of your JDBC Providers policy must match the database name that is used by the database transforms in your Graphical Data Map, this is determined by the database definition (.dbm file) in the Data Design project that was used to create the map. So in each environment you can provide the same named JDBC Providers policy, but each will set the relevant "serverName", "databaseName" etc values.
HTH
------------------------------
Martin Boag
Software Developer
IBM
Original Message:
Sent: Mon August 16, 2021 04:03 PM
From: Pieter van de Braak
Subject: Best practice for using the database mapping in a DTAP environment
We are currently facing an issue where we are using a mapping inside a REST API that enriches the messages with the response of a stored procedure and then returns those value. The way that we set this up is that we imported the database and call the stored procedure in the graphical mapping. However now when we want to deploy this from our Test environment to our Acceptance environment we need to change the selected database in the mapping as we have a separate database for each environment.
I have two problems with this approach.
1) This means that you have to do a change to your flow, which would theoretically mean a new version which then has to be tested again.
2) This means that it becomes harder to automate as some manual labour is required when moving your version from T to A
So what is the best approach to this?
------------------------------
Pieter van de Braak
------------------------------