What are the *.config files for?

, ,
1

Hello,

since recently we use Designer 9.6 (after 8.2). Now, when developing a process model, we notice *.config files alongside the *.process files. The information in the config files is also present in .process files.

What are these *.config files for?

Thanks!

2

Refer “About the Navigator View” from XX_BPM_Process_Development_Help guide.

3

Mahesh, thank you for the reference. I looked into the docs, but there is no explanation about the *.config files other than the recommendation to handle them via the solutions view.

4

The .config file was added as a sibling file to the .process to contain information about the process that can be modified at runtime. This includes stage definitions (both the stage start/complete step and expected durations) and some Quality of Service settings that can be modified in the Monitor product (MWS Administration > Processes).

Since these settings can be edited both in Designer and in Monitor without affecting the actual sequence flow of the model, they have been separated into their own config file. And if they are modified at runtime, Designer provides a button to synchronize them, by clicking a button which fetches the values from the runtime database and stores them back to the .config file.

I hope this clarifies.

5

Hello Michael,

thank you very much for this good explanation! I still have some questions, would you mind answer them?

I still don’t understand why this information is stored both in .process and .config file. Which one is used when the process model is published to server (“build & upload”)? Which one is used when the process model is deployed via the deployer, in particular, using the repository based deployment? What files should be checked in in the repository?

6

There is no information that is in BOTH the .process and .config files. They are complementary, and should both be checked into source code control.

When you build and upload:

  • The “build” will use information from the .process file only to create runtime “fragments” to be used to orchestrate the runtime, as well as creating wrapper services and triggers.
  • The “upload” will do two things now:
    1. Upload process, step, transition, custom logging definitions to the metadata tables in the Process Audit database (WMPROCESSDEFINITION, WMSTEPDEFINITION, WMSTEPTRANSITIONDEFINITION, etc.). This information comes from the .process file, as it always has.
    2. Upload stage information and some QoS settings to other metadata tables in the database (WM STAGEDEFINITION, WMPROCESSDEFINITION). This information comes from the .config file.

Since the items in #2 are also editable at runtime in the Monitor interface (and will not affect the control flow of the process), they can get out of sync with the .config file in your Designer workspace and source code control. Hence, there is a button to synch Designer definitions to the latest in the database – which you’d then have to check back into source control again.

Deployer will perform a build and upload, so will populate these values from the config file again.

1 Like
7

Thank you again for this perfect explanation!

We use Designer 9.6, and I’ve seen the information from *.config in the *.process file as well (IIRC, this was the “easeofoperation” element), that’s why I’m asking.

What version is your statement based upon? Can it be that you use a later Designer version, and the duplication has been eliminated there? I.e. the information about the “resubmittable” property of the steps is now contained only in the .config file.

If my speculations are correct: That would mean that it’s not possible, based only on the data in the runtime (e.g. process audit DB etc.), to restore the “resubmittable” property for the steps back to its “design time” value, right? To restore it to its original values, one had to have the original .config file and then set the properties manually (Monitor > Administration). Is it possible to set just the QoS properties based on the .config file by somehow “uploading” it (i.e. without building and uploading the model)?

You see, I like asking :slight_smile:

Thank you again for the invaluable info about how it works.

8

Looking into the history a bit deeper, I now see that:

  • The element still exists in the .process file, but it is not populated.
  • There was a defect reported in 9.7 that using repository-based-deployment did not set the values right in the database, as it was not reading values from the .config file.
  • A deployer fix was issued (ABE_9.7_Fix4) to correct this, and have deployer pick up the values properly from the .config file.
  • This fix was ported to later versions, but it was not backported to 9.6.

But you are correct that there is no way to simply restore the values in the config file to the database without either a) manually setting them in MWS Monitor > Administration, or b) building and uploading the process again with the existing .config file in place. These are the options. There is no isolated way to sync from the file to the database – only the other way around.

I hope this helps.

1 Like
9

Thank you Michael! I now at least know what we’re at and that we’d rather watch out for unexpected things here. I’ve also polished up your star status :slight_smile:

Update

This is even more quirky. The “easeOfOperations” element is present, but its contents is not always updated when the .process file is saved. Same applies to the “qualityOfService” element. It’s just confusing.

10

Hi,

there is a possility to define some default settings for “Build&Upload”, which take effect on your DEV server.
Additionally you can specify how these settings should be handled when deploying to higher Environmenents like QA or Prod.

I.e.:
We use this to tell our DEV server that ALL steps can be resubmittable, but we dont want this on the other environments by default. Only some specific steps need to be resubmittable by default.

Regards,
Holger

11

Could you please describe it with more details? (Where is the setting made etc.)

We do it in a similar way. But we almost always set all steps to resubmittable when we put a new version on the server. When the things have settled, we restore the values to those in the original model. Hence the need to set the settings to the design time values.

12

Hi,

these settings are in process propeties section in Designer.

Click on the Background of the Model so that there is no step or lane or pool is selected.

Regards,
Holger