Rework Path for Parallel Activity

Hi,

I have a Workflow with automatic activity that enables 5 parallel activity. If one activity assignee select Rework path, how can I restrict other activity assignee to vote ? 

In other words, out of that 5 parallel activity, if one goes to rework then remaining all should go to rework path. I tried override path but seems it is applicable only for 1 activity with multiple approvers.

Thanks,

GK

  • Where you already possible to solve this one? It´s an interesting use case, but not easy to answer.

    Do you have created own rework paths or do you use the "Can Refuse" option? It´s maybe possible, to add a Method to the rework path, that rolls back the other activities to the previous Activity.

  • Hi

    I added my own rework paths.

  • Hey Gopikrishnan,
    Have you tried containing it in a subflow? We've done this with our workflows and seems to work well.

    To accomplish this you will need to have an activity step on your main workflow with a workflow in the subflow area that contains your parallel activity steps and end steps for each possible path from the subflow with a method that assigns the path name to a property on you Item that the workflow is running on (this is the way I do it there may be a better way). When leaving the subflow it will need an automatic activity that has all the possible paths and a method that assigns the path it needs to go down. When the subflow closes it will close your parallel steps and go to the rework step.

    Steps:

    1. Create a workflow with your parallel steps in it.
      1. The start activity on the workflow will need to have default paths to all the first parallel steps.
      2. The workflow will also need end activities with methods that can choose the paths you need to take on the way out.
        1. I have mine setup so that the method gets the name of the end activity which matches the name of the path that needs to be taken and sets it on the item the workflow is running on as a property called "wfbranch".
          1. examples:
            1. End Activities in Subflow:
              1. Complete
              2. Cancel
              3. Rework
            2. Paths from Auto Activity outside of subslow:
              1. Complete
              2. Cancel
              3. Rework
        2. Your forward moving end activity will need to be a wait for all inputs. This is so all the parallel activities can finish before closing the subflow.
        3. Rework steps will just need to be end steps.
    2. Add an activity to your main workflow and assign the workflow you created as the subflow. 
    3. Add an automatic activity after your subflow activity.
    4. Add a single path from your subflow activity to the automatic activity and make it the default.
    5. Add all possible paths that can be taken to the automatic activity and add a method to it that will determine which path to take based on the property that was set on the end steps.

    Note: We are currently trying to do this with 2 subflows that need to move in parallel and are having an issue where one of the subflows stays open. Outside of that scenario this works like a charm.

    Methods you will need:

    C# method sets the wfBranch on End Activity of subflow:

    Innovator inn = this.getInnovator();

    Item itm = this.apply("GetControlledItem");

    string wfBranch = "";

    wfBranch = this.getProperty("keyed_name");

    itm.setAction("edit");

    itm.setProperty("wfbranch", wfBranch);

    itm.apply();

    return this;

    if you don't have the GetControlledItem method you can find it here....

    https://gist.github.com/YoannArasLab/817184c84b7dec9e0dd3105c9d456632

    C# Method that tells Automatic activity which path to take:

    Innovator inn = this.getInnovator();

    Aras.Server.Security.Identity plmIdentity_New = Aras.Server.Security.Identity.GetByName("Aras PLM");
    bool PermissionWasSet_New = Aras.Server.Security.Permissions.GrantIdentity(plmIdentity_New);

    Item itm = this.apply("GetControlledItem");
    string branch = itm.getProperty("wfbranch");

    Item itmActivityPaths = this.newItem("Workflow Process Path", "get");
    itmActivityPaths.setProperty("source_id", this.getID());
    itmActivityPaths.setProperty("is_default", "1");
    itmActivityPaths.setAttribute("select", "id");
    Item itmUpdateActivityPaths = itmActivityPaths.apply();

    if(itmUpdateActivityPaths.getItemCount() > 0){
        itmUpdateActivityPaths.setAction("edit");
        itmUpdateActivityPaths.setProperty("is_default", "0");
        itmUpdateActivityPaths = itmUpdateActivityPaths.apply();
        
        if (itmUpdateActivityPaths.isError())
        {
            return inn.newError("WFBranchChk: 1. Error updating default path: "+ itmUpdateActivityPaths.getErrorDetail());
        }

    }

    Item itmAssignDefaultPath = this.newItem("Workflow Process Path", "get");
    itmAssignDefaultPath.setAttribute("select", "id");
    itmAssignDefaultPath.setProperty("source_id", this.getID());
    itmAssignDefaultPath.setProperty("name", branch);
    Item itmSetDefaultPath = itmAssignDefaultPath.apply();

    itmSetDefaultPath.setAction("edit");
    itmSetDefaultPath.setProperty("is_default", "1");
    itmSetDefaultPath = itmSetDefaultPath.apply();

    if (itmSetDefaultPath.isError())
    {
        return inn.newError("WFBranchChk : 2. Error setting default path: "+ itmSetDefaultPath.getErrorDetail());
    }

    if (PermissionWasSet_New)
    Aras.Server.Security.Permissions.RevokeIdentity(plmIdentity_New);

    return this;

  • Hi Phinnix

    It works but still I can see the subflow has the active task n In Basket with activity Delegate and Refuse (actual subflow is already closed but task from subflow is still active). How to make it disappear from user In Basket

    Thank You

    Gopikrishnan

  • Hey Gopikrishnan,
    Sorry about the delay in the response. I'm not sure why that step would have stayed open the only time we've experienced this issue is when we have two subworkflows running parallel within a subworkflow of a main workflow. If you are trying to run your parallel paths like this you will need a separate solution. I currently have a user testing a solution for the above scenario and if it works I'll link to my forums post where I'll post the solution to this. outside of this being the case I have a few questions.
    Is this Rework step the autostep that you are assigning your path from in prep for exiting the subworkflow?
    If it is. Is it also the an end step of the subworkflow?
    If it's not it might need to be.
    Where does it go once it leaves your subworkflow?

    Also screenshots of the workflow would help so I can see where and what is getting stuck.

  • Hi Phinnix

    Main Workflow

    In Review has Parallel Activity (Automatic Activity)

    Sub Workflow

    Complete is Automatic Activity and Wait for all inputs is selected and End Activity

    Rework is not Automatic Activity and Wait for all inputs is not selected and End Activity

    Server Events is attached to Complete and Rework Activity

    Any help will be much appreciated

  • Hey Gopikrishnan
    So based on your In Basket and your workflow this is what I think is happening. I think it is making it to the Rework on the main workflow but appears to be in the subflow because the activities are the same name. Can you rename the Rework on the main workflow to Rework1 just to test this hypothesis?
    If the Activity in the In Basket is Rework1 then it's at the correct step if not then it's not making it there this can be changed back after we determine which step it is at.

    Also another reason I think it's getting to the correct step is the Rework step on the main workflow doesn't have any paths off of it so in that case it would only offer to delegate or refuse. I suggest adding a path back to In Review so that after the Rework on the Main workflow is complete it can be reviewed again. adding this path would be another good test to see if everything is working as you would then have the voting options delegate, refuse, and in the below example Ready for Review.

    Lastly the path coming off of New Activity and going to Released needs to be the same name as the step that would send it there so for the method to work you will need to change the path from Released to Complete or the Activity in the subflow would need to be changed from Complete to Released. If the path and the end activity don't match you will get the "Not a single Item" error.

    Main workflow changes:

    Please note changing a workflow map will not effect workflow processes that have already been started you will need to start a new workflow process to see these changes.

  • Kudos to you. It works like a charm. As you guessed, active task is based on the main workflow. One more question, Can you provide the exact event where I need to add these 2 methods as per your previous reply.

  • Awesome!

    To answer your question both methods events should be set to On Activate.

    Unless you mean in what scenario should I use these methods. Then the answer is these methods are designed to be used when a subworkflow can go to any number of activities on close. In your example these steps are Rework and Released. This has the added benefit of closing parallel activities when a rework step is needed.