Home > Forum > User Voice > Fourth environment of WEBCON BPS

Fourth environment of WEBCON BPS NOT NOW
2

MVP

Coming from developing individual web applications, for large projects, it would be practical to have a fourth environment to run WEBCON BPS
Instead of having only DEV/TEST/PROD, we would like to have DEV/TEST/INTEGRATION/PROD. or similar.
DEV/TEST would be in-house to develop and test the applications, and INT/PROD would be on the client's Infrastructure.

This would make change management and testing much easier and closer to our internal development guidelines.

Are there others working on very large projects, where this setup would be beneficiary.

MVP

Hi Marcus

I also work in an environment with 4 instances of webcon
A minor problem is setting the fourth unique environment type, we have 2 times TEST.
The only problem is importing to this environment if the data sources, constants have a different configuration, connection, than the second TEST.
I added copies of the TEMP_WFDataConnections and TEMP_WFEnvironmentGlobalVariable tables.
Which I periodically feed with data if after migration any connections, constants are different for these 2 environments.
During the next migration of processes, the trigger set on the migration history column (which changes after migration) calls a job that overwrites the table with the correct data that I fed earlier.
it works quite well, you have to remember to stick to global constants so as not to overwrite local ones in the process (too much work with this), or instead of constants add business rules, etc. You also have to feed these local tables TEMP_WFDataConnections and TEMP_WFEnvironmentGlobalVariable from time to time if after migration new sources, constants, different in the context of configuration for TEST - TEST are added

Regrds

MVP
In reply to: Karol Częczek

Hi Marcus

I also work in an environment with 4 instances of webcon
A minor problem is setting the fourth unique environment type, we have 2 times TEST.
The only problem is importing to this environment if the data sources, constants have a different configuration, connection, than the second TEST.
I added copies of the TEMP_WFDataConnections and TEMP_WFEnvironmentGlobalVariable tables.
Which I periodically feed with data if after migration any connections, constants are different for these 2 environments.
During the next migration of processes, the trigger set on the migration history column (which changes after migration) calls a job that overwrites the table with the correct data that I fed earlier.
it works quite well, you have to remember to stick to global constants so as not to overwrite local ones in the process (too much work with this), or instead of constants add business rules, etc. You also have to feed these local tables TEMP_WFDataConnections and TEMP_WFEnvironmentGlobalVariable from time to time if after migration new sources, constants, different in the context of configuration for TEST - TEST are added

Regrds

Hi Karol,

that's an interesting approach. I never thought of it. :)

My approach was to create an "import" process which makes a snapshot of the data before the import and again one after the import. This way we can check what changed and correct elements if necessary.


With BPS 2024 we can integrate the import of the package into this process. :)
https://daniels-notes.de/posts/2024/importing-applications-using-an-application#displaying-the-changes

Regards,
Daniel