[Suggestion] Let the configuration values in the Data Managements tab of the Process properties be an expression

Suggestion: I'd like to suggest you update this tab values to an expression, so we can set constant values instead of literal values

All of the other tabs already have their values as expressions.

Reason: I'm having a 'corno job' changing more than 300 processes by hand. If I could change this to a constant, it would be easily changed by the next unfortunate one that needs to update this by just changing one constant.

  Discussion posts and replies are publicly visible

  • Another suggestion, there's no way for these processes variables to be updated in batch?

  • 0
    Certified Lead Developer

    Agreed, it would be neat to at least be able to set that value to a constant, or an expression that spits out different values per different input priority levels, PV states, etc.  I'm not 100% sure how feasible it is to implement from an Appian Engine perspective (there might be severe limitations into what data could possibly be taken into account), but that doesn't prevent it from being a significant quality-of-life issue.

    For your specific case, if it's critical to bulk change in hundreds of process models at once, I'd consider perhaps editing the XML files directly in an exported application package, and re-importing.  This is an extremely unsupported method, and would need to be done very carefully, but I'd consider it worth the extra effort in exchange for saving 5 or 10 hours of manual labor.

  • I've always been thinking this is more of a safeguard, since changing the process model archive settings will take immediate effect on all process instances in the system for that process model, also preventing us from setting these values dynamically for different instances, with the current platform.  I learned this early on in the Portal days, where process instances in-memory were necessary for reporting.  Lowering the process model archive settings immediately archived completed process instances, removing them from those portal reports.

    For "updating process variables", are you attempting to add/remove PVs in running instances or just update theri values?  For bulk updates to pv values, I've always scripted that through 1 process which loops the Set External PVs service of the Get and Set External Process Variables plugin, based on process instance IDs retrieved from queryProcessAnalytics.

  • 0
    Certified Lead Developer
    in reply to Chris
    For "updating process variables", are you attempting to add/remove PVs in running instances or just update theri values? 

    I assumed Arthur wasn't referring to "PV" process variables but rather the archival days values, i.e. where there are several hundred process models all hardcoded to 7 days and the customer decides that value should be updated to 10 days etc...  though I guess I could be reading it wrong(?)

  • I wasn't sure on that either..

    Additionally this may be a time for consideration of changing these processes to use the System Default, then update that default as necessary, depending if this is the majority or minority of process models.

  • No, for me if I can do cons!app_configurationForDeletingProcessInDays is enough.

    I was not considering PVs in this, and I think that considering PVs may lead to some difficulties if this change is not an out-of-the-box one to use the expression fields that are already being used inside other fields inside the system.

  • 0
    Certified Lead Developer
    in reply to Chris

    Yeah.  I actually didn't know the trick about the archival setting immediately changing the same for all current instances.  I might be able to use that in the future and *also* it's probably the reason my original answer isn't feasible, lol.

    Alternatively I think maybe there shouldn't be just 1 "system default".  Maybe "high/medium/low" settings?  You could set one to 0 - 2 days, one to 5 - 7, and one to 10 - 20, for example.

  • What I want in the bulk change it's not to change the PVs, but the Process properties themselves, not the variables.

    For example, for whom will trigger an alert if this fails?
    Today I need to change that field one by one. Usually, we have a default group that every error should be reported to them, we rarely specify a different group for each process.