Importing and Exporting Applications

0

HI,
In the perfect world, you should do all development on DEV environment, and only use Import mechanism on TEST/PROD environments.

When you import an application to an environment Webcon defaults in in its settings to display a message, that you are modifying process, that have been imported.
This is a way to warn and protect user before making changes which might lead to unpredictable errors. I once felt the pain, and I'm now always thinking twice, when changing something on TEST/PROD manually.

TLDR;
1. Webcon will mark process as imported, and will prompt you every time you will try to save it, that it is a import/export process. You still can allow it, but on each save there will be a message to confirm.
2. It's only a checkbox marked, you can uncheck it (Miscellaneous group: https://docs.webcon.com/docs/2024R1/Studio/Process/Process_Configuration/Process_Settings)
3. As in pt. 2 :)

@Update, below example is wrong, I'm leaving it here, to maintain the discussion, in later comments there is an update in this regard.

An example, let's say you are developing an application, that is already on DEV/TEST/PROD.

Monday:
There is a feature request, to add a new field, you are making that change on DEV environment and inside database a new column is being used, lets say WFD_AttText5.

Tuesday:
A CEO comes into your office screaming, that there should be a new text field on a PROD right now, and you have to do it today (a little exaggerated example).
You jump in to work, and create a new field directly on PROD, and it gets also WFD_AttText5, as changes you've made on DEV and reserved this column are not yet on PROD.
Of course you also add this field on DEV, so it's there for next update, and will not get lost, and on DEV it will get WFD_AttText6 column.

Wednesday:
You want to deploy new release, it hit's prod.

Field you've added on Tuesday in prod gets deleted - it has different GUID internally, so webcon doesn't know it's the same you've later configured on prod.
The new field is added, and you end up with new field on WFD_AttText6, and all data filled before on WFD_AttText5 stays there, so all forms seems empty for this specific field.
You'll have to manually update database to make it work again, and you've lost WFD_AttText5 column.

Also your environments DEV/PROD are now divergent - on DEV field is using WFD_AttText5, and on prod the same field uses WFD_AttText6.
In case of any complex reports that require column names you'll have remeber at every single update, that you have to manually update that report. Not cool :)

Hi Maks,

did you test this or did you run into issues with this?
__
Also your environments DEV/PROD are now divergent - on DEV field is using WFD_AttText5, and on prod the same field uses WFD_AttText6.
In case of any complex reports that require column names you'll have remember at every single update, that you have to manually update that report. Not cool :)
__

I'm quite sure that they will both have the same column name.

@S Blue
Except this example I can confirm Maks response.
If you import a new version to a target environment or database in this regard, every element in a process is removed in the target environment if it's GUID does not exist in the import package.
There's maybe on exception. If a workflow instance is in a step which was deleted in a new version, there's either an error, or the the step remains in the system. I'm not to sure about it.
I have in mind that you can delete steps, if no workflow instance is currently assigned to it, but I'm not sure. The history would look strange. :)

Best regards,
Daniel

That's an issue we've faced on our environments in one application, I'll try to replicate it though and will update with results :)

I'm back with results, and it seems my memory tricked me, or something changed, thanks for catching it Daniel :)
I'm sure that we had divergent environments, and we had to manually update columns in reports, but it might have been a different reason.
In attachments you can find screenshots, of the process.

In the end, environments won't be divergent, but due to changing the columns data that have been stored in 'Job Title' on test under WFD_AttText3, will stay in that column after update, and on forms will be visible under 'E-mail' column, as it's now using WFD_AttText3.