Designing Rampiva Workflows that Scale

Where to Begin 

As with most things, workflow design benefits from upfront planning. Having a concrete understanding of the network storage locations and user input items are a must. When designing a workflow, a major goal of the designer is to limit unnecessary complexity while also limiting opportunities for user error. A simple workflow might have the user input all of the values in the workflow such as case, source and export locations. These workflows of course run and are likely to provide significant improvements versus executing the same workflow operations manually. However, the approach is not optimized for scale or automation, and of course introduces significant opportunities for user error. To balance this, consider exploring the scale components built right into Rampiva Automate. 

Execution Profiles 

Rampiva Automate has numerous components that assist designers when building scalable workflows. The primary mechanisms are Parameters and Execution Profiles. Check out our “Guide to Using Rampiva Parameters” to learn more about the types of Parameters and when to use them. Both mechanisms are critical to building a workflow that will run on any machine in your environment. The Execution Profile is designed to be an area where global values for the system and workflows are set. It has many scale components, but we think a few stand out: 

Log Location 

This setting allows you to globally redirect your logs to a central location. Rampiva Automate does assist with log collection but having all of the logs in a central location helps with retrieval if the Rampiva Automate service is not available. It also helps when pruning and cleaning-up of stale historical logs is needed to recover space on the system. 

Workflow Parameters 

Many of the workflow operations that you will include in your workflow benefit from chaining parameters together to create a complete location. An example of this is the Use Case Operation. In order for a workflow to run, a Case Location must be defined on this operation. There are two ways that you can set this value. One being a single user input parameter, such as {nuix_case_location}. This is a User Parameter, and when the workflow runs, the user will be prompted to input a full path to the Nuix case location.  

However, a better way would be to combine User Parameters with System Parameters to define the Nuix case location. An example looks like {base_case_folder}\{client_name}\{matter_name}. The User Parameter in this example is {base_case_location}, and {client_name} and {matter_name} are System Parameters. This method lets you take advantage of the System Parameters that align with the Clients and Matters created in Rampiva Automate.  

Now that we’ve established how we want to define the Case Location on the Use Case operation, we need to decide how we will map the User Parameter. One way to do that is to set the parameter value on a Configuration operation: 

This is a viable approach, but now the value is stored in the workflow itself. This will work great for environments with a single server or where this value does not ever change. However, if you are designing workflows that need to run in multiple environments like on premise and Cloud, this approach will be problematic. 

Instead of setting the value on the workflow Configuration operation, consider setting the value on the Execution Profile. Then, make an Execution Profile for each environment. An example of setting a User Parameter value on the Execution Profile looks like this: 

Once you’ve set this value on the Execution Profile you can either remove the Parameter entirely from the Configuration operation, OR just remove its value so that you don’t have conflicting inputs. We recommend leaving the Parameter on the Configuration operation, but removing the value: 

File Libraries & Nuix Profiles 

When designing workflows, several operations allow designers to prescribe which Nuix Profile(s) should be used for that operation. For example, on the Legal Export operation, designers can prescribe the Metadata, Imaging, and Production Profiles. Once defined, each Nuix server that runs this workflow will also need to have access to each profile. If the server does not have a copy of the Nuix profile defined in the workflow, the workflow will fail to run.  

The Execution Profile helps you manage these profiles. Starting in Rampiva Automate 5.5, Nuix Profiles will be stored in File Libraries. File Libraries give you the ability to manage all of the Nuix Profiles in a single location, while also making those profiles available to each Execution Profile in your environment. File Libraries also help manage profile versions. Nuix uses the profile name to locate the profile when processing. But, if changes are made to a profile by the designer, that profile will then need to be redeployed on each machine that will run the workflow. 

Upon workflow execution and when profiles are stored on the Execution Profile, these profiles will be copied to the Nuix Case location automatically. This gives the workflow access to the profiles that are prescribed in each of the workflow operations. 

Notification Rules 

Along with helping Nuix users define global settings via the Execution Profile, Notification types can also be set. Rampiva Automate supports Email and Webhook notification types. Each notification type can be customized to notify specific groups or users and also trigger on specific events when the workflow executes. For Example, a system administrator can create two Email notifications. One email notification triggers on failure system events like Job failures and sends a notification to an Operations Manager. With a second email notification designed to trigger on successful events like Job Completion, with notifications sent to the Project Manager assigned to the Job. 

Both are prescribed on the Execution Profile to help relay pertinent information to the proper task owners. 

Workflow Operations 

Dos and Don’ts 

  • Do: Use Parameters in operations to define locations for Exports, Reports, Source, and Case locations. 
  • Don’t: Use single parameters to define complex locations when a series of User and System Parameters can be used.  
  • Do: Mix static path locations with Parameters to build locations that will be created only when the workflow runs. Example: Export Folder Location: {case_folder}\Export\Export_{date}\{export_production_set_name} 
  • Don’t: Use full UNC or Local paths. Example: \\Servername\Nuix Source\Source Data 
  • Do: Use workflow operation helpers when defining scope criteria. Example: batch-load-guid:{last_batch_load_guid}  
  • Don’t: Use exact queries when defining scope criteria. Example: batch-load-guid:acb75381ef264227a156e5a73747825a 
Comments are closed.