Workflow via Code – Part 2

In part 1, we looked into the basic setup of a workflow via code. While not overwhelmingly exciting on the results side, it gave us the basic framework to build on. In part 2, we will work with actions. Actions may be defined as a PXAction in the graph or in a pure workflow manner in the workflow’s graph extension. We will look see how to define an action in the workflow and how to add both types to the menu in controlled ways.

When an action is defined in the base graph, our workflow will refer to it typically via LINQ syntax of g => g.myActionName. When our action is defined in the workflow, we refer simply to the name, i.e. myActionName.

Defining an Action (2021 R1)

To define an action, we first will define a constant for the display name of the action. Then for each action, we create it as a new ActionDefinition, assign a folder to place it on the menu if desired, and assign what action it should follow in the menu structure.

In the following gist, note how a constant is created for Remove Hold and Put On Hold. Next notice the variable created for each action. Remove Hold is placed in the Actions menu folder and follows the Last record navigation button. Put on Hold is created similarly and defined to be placed after the Remove Hold action.

View this gist on GitHub

Defining an Action (2021 R2)

In 2021 R2, the menu system changed to a categorize panel. Therefore, we must define categories and assign the actions to categories instead of folder. In the gist below, notice the definition of processingCategory and then the assignment to .WithCategory(processingCategory) on lines 14 and 19. Otherwise, we continue to define the action the same as previously.

View this gist on GitHub

Placing the Action on the Menu

Now the the action is defined, we need to attach the action to the menu. We do this by use of .WithActions which we attach to our ongoing screen definition.

View this gist on GitHub

Notice that we defined removeHold and putOnHold as actions within the workflow, so they are specified directly. However, the action for schedule was defined within the graph, so we must specify the graph instance via LINQ syntax with g => g.schedule where g stands for “from the graph“. Note: If the action was defined in a graph extension, we would use the syntax action.Add<graphExtensionName>(g => g.myAction); Also note that we specified the category for the schedule action here, unlike when we were able to specify it in the variable where the putOnHold and removeHold actions were defined.

Now the actions have been added to the menu. In 2021 R2, the ellipses contain the drop-down menu panel with a single group… the Processing Category. All three actions are listed, in the order defined in the workflow per PlaceAfter. For now, we have Remove Hold and Hold both enabled, but we will want to set them to be enabled only under certain conditions, which will be handled in a later post in the series.

The complete code at this point is shown in the following gist.

View this gist on GitHub

Summary

In this post, we added actions to the workflow and to the menu. For actions defined in the workflow, they don’t do anything… yet. In part 3 of this series, we will associate actions to the state in which we want the action to be enabled and create field assignments to set values when the action is clicked by the user.

Happy coding!

Leave a Reply