Best Practice for Deploying Patches

Certified Senior Developer

We have several process models in our Production environment that list an individual user as the process owner. We've changed our practice since they were initially deployed, using only a service account (i.e., Appian.Aministrator) for deployments but the process owner value has not changed even when patches were deployed that modified these process models. Do we need to export the processes using the Appian.Administrator account and then re-import them in order to change the process owner? Please advise. I don't want to risk having these processes fail if the listed process owner account becomes deactivated.

  Discussion posts and replies are publicly visible

Parents
  • Hi Judy, By "Process Owner" you mean the process initiator ??
  • 0
    Certified Senior Developer
    in reply to mohamedt808
    No - I'm referring to the individual who is the owner / creator of the process. The security on the process will dictate who initiates it, which is typically someone other than the person who created the process (i.e., the end user who starts an action). However, if the process is started by the person who created it - then we could have a problem if the creator is a developer or system administrator whose account has been deactivated. I assumed that if we used the Appian.Administrator account to deploy updates - it would change the process owner for the process model, but evidently, it doesn't.
  • 0
    Certified Lead Developer
    in reply to judym598
    I think this is what you are referring to. You can export your app and re-import using this notation in a customization file to force the update of the object owner to match your deployment user:
    docs.appian.com/.../Managing_Import_Customization_Files.html
  • 0
    Certified Senior Developer
    in reply to Tim
    I'm thinking that is the best option Tim - I will have our administrator export the application and then re-import it using the administrator account. We haven't used the customization file in the past but I will look into that as well.

    Thank you all for your suggestions!
  • 0
    Certified Lead Developer
    in reply to judym598
    The deployment guidelines linked previously were for v17.1 and are horribly out of date. I think it was 17.3 that Appian amended the import procedure to not update objects that had not changed by default. Assuming you are cloud then you will have this functionality.
  • 0
    Certified Senior Developer
    in reply to Tim
    I just looked at the 18.2 version and it basically says the same thing:

    "On import, process models are published as a new version.
    If you are reimporting an existing process model, draft versions you may be working on are overwritten when the imported process model is published.
    When importing process models (for the first time) that are linked recursively, the process models are published twice - resulting in two new versions.
    Subsequent imports (updates) publish the recursively linked process models one time per import, creating one new version.

    The user performing an import is listed as the creator of notes and attachments associated with the process model, as well as the owner of the process model."
  • 0
    Certified Lead Developer
    in reply to judym598
    That's true. Hopefully someone from Appian will see this and review.
    If you look at the section around "Reading the Import Log" you will see the "Not Changed" note that links through to the Import Package docs. Here it reads:
    "When you click Import Package, the object's definition will not be updated in the target environment because there are no updates to make. The Last Modified information will remain the same as it was pre-import and no change will be made to the designer of any process models with this status."
  • Please look into a plug-in called "Re-publish process model as user". Running this against any process models where the creator is not listed as your service account will allow you to set whatever user you like as the "last publisher", which in my experience is the main factor in process model security (regardless of whichever user originally imported the process model).

    In one of my projects the service account is a dummy only and developers can't log into it, so deployment is done via personal accounts and then we run a tool I wrote a few years ago that finds all process models not last modified by the service account, and re-publishes them under the authority of the service account.

Reply
  • Please look into a plug-in called "Re-publish process model as user". Running this against any process models where the creator is not listed as your service account will allow you to set whatever user you like as the "last publisher", which in my experience is the main factor in process model security (regardless of whichever user originally imported the process model).

    In one of my projects the service account is a dummy only and developers can't log into it, so deployment is done via personal accounts and then we run a tool I wrote a few years ago that finds all process models not last modified by the service account, and re-publishes them under the authority of the service account.

Children
  • 0
    Certified Senior Developer
    in reply to Mike Schmitt
    Thanks Mike! I think if we just export the application using our service account and then re-import it, we should be okay. I was trying to avoid doing that. I'm also working with the cloud team because I think the 'Owner' column displayed on the Process tab in 18.1 is not correct. The 'Created by' and 'Author' columns displayed elsewhere (i.e., in the /design view) all show the service account name (Appian Administrator). So - perhaps the 'owner' is correct - but Appian has a bug in the Process tab in the /designer view.
  • Yeah - it all gets a bit confusing particularly since Appian uses different terms for these things in different contexts. For instance in /design all we see for process models is "last modified", which is different from a process model's "creator", however when a process is set to "run as designer" (i.e. in a subprocess call) it actually uses the "last modified by" user, not the creator.

    When you say "Owner column", where exactly are you looking? The default view of the Process instances listing in legacy designer lists "Started By" but this isn't really the same as "Owner", though you could be referring to something different that I'm not thinking of.
  • 0
    Certified Senior Developer
    in reply to Mike Schmitt
    If you are in 18.1 or earlier and click on the Processes tab, then view Process Models - the default column headings include: Name, Description, 'Owner', Created, Last Modified. I will try to upload a screenshot.
  • I see it now - as far as I know, "Owner" there reflects the process model's creator, but (confusingly) not the Last Published By user, which is the more important thing.
  • Hello Mike,

    this is exactly our case you mentioned above. Our service account is a dummy only and we can't log into it,
    How did you manage to find all process models not last modified by the service account? Because I am struggling with a functionality of "Process model report - models last modified by user". When I define Report Context it is showing nonsense.

    Thank you
    Juraj Buc
  • 0
    Certified Senior Developer
    in reply to jurajb
    Juraj - Your service account should be linked to an email address. Can't you reset the password for that account? Also - if you can't - you may have to search for process models last modified by the service account and then look at the different versions associated with each to find the last one not modified by the service account.
  • Thank you for your reaction, Judy. In the end we managed to get a report with PMs not last published by the service account using the custom function getProcessModelDetailsByUUID.
  • This is close to what I was about to suggest. Using the process model details by UUID plug-in, I was able to design an automated process a few years ago (which i mentioned already earlier in this thread I notice), which checks every process model in the environment for the "last published by" user using this plug-in, and then uses the Republish Model As User smart service to republish any not last republished by the system account user. The main drawback to this is that the process model details by UUID custom function is slow, taking a few seconds per process model, so when running it in an environment with hundreds of process models, it requires several minutes to do the initial check-through.

  • Indeed, that's exactly what I want to achieve. In the beginning I was just little bit confused because in our case the getProcessModelDetailsByUUID function didn't return "Last Published By" but of course I found out we had an old version of the plugin deployed :)
    So now I have no other blocking issue ahead of me, so there will be no problem to complete this functionality.

    Thank you
  • If you're interested, I've created a generic export of my process model republisher app.  It requires the two plug-ins mentioned here, as well as the common Appian Common Objects rules (APN_isBlank, APN_isEmpty, APN_arrayLength, and APN_displayUser), but otherwise has no precedents.  I will attach it here so you can try it out.

    1362.Process Model Republisher - 2018-11-13.zip

    This also requires a .properties file - the generic value is as follows, and you would need to supply your own custom admin user username proor to import:

    ## Constant: PMR_ENVIRONMENT_ADMIN_USER
    ## Type: Text
    ##
    ## Text values will be displayed in Appian exactly as they are
    ## specified here. No spaces are trimmed. Values do not need to be
    ## encased in quotation marks.
    content._a-0000dab0-812b-8000-9ba2-011c48011c48_193261.VALUE=admin.username