Home Blog Using Modular Graph Extensions to Avoid “Mega” Graphs

Using Modular Graph Extensions to Avoid “Mega” Graphs

Samvel Petrosov | May 28, 2020

One of the main challenges we face here at Information Integration Group (IIG) in our development of Acumatica ERP customization packages, is the ongoing increase of our Graph extensions’ size with the addition of any new features we develop and add to our packages.
In my post today, I want to show you a very simple technique which a developer can avoid  in creating so-called “mega” graphs by simply dividing them into modular graph extensions.

Let’s assume that we have a Sales Order page customization we want to add to our customization package and in doing so, we add some very complex features to the page.  Further suppose that they are not much related, so that you can definitely partition the code involved for these features into separate methods. In this case, the simplest solution is to make the code more readable, simple, and separate the features into separate Graph Extensions.

In the following simplified example, we have a Sales Order Graph Extension:

Moreover, assume that a PrintOrder and a RedirectToRecord are doing rather complex operations.  In this scenario, it is very easy to separate these to actions into two separate Graph Extensions as shown in the code below:

And:

Here, this part is taken care of rather easily. Now we have two Graph Extensions and, if we need to work with one feature, we always know where it is and the changes in it will not affect the other features we have developed.  Another thing that we need to think about is – do we really need both of these Graph Extensions to be loaded and always running? Likely not.

From the “Conditionally Activate Extensions” blog-post by Sergey Marenich, we learn that we have an option to disable the Graph Extension from loading, if we don’t need it. Therefore, we need to add the IsActive property to our Graph Extension and somehow check the condition for disabling the Graph Extension.

I will use Acumatica’s Database Slots for reading the data value for any conditions we have. More information regarding Database Slots can be found in “Cache Data in Memory using Database Slots” blog-post by Sergey Marenich – as well as in Acumatica’s Help Database. In our example, let us assume that our complex features must work depending on some check-boxes in Sales Preferences. Below is the Database Slot implementation for reading values of the check-boxes that we need.

Next, we need to add the condition into the IsActive properties of the Graph Extensions and do some tricky stuff with Sales Preferences page:

And:

Here’s the tricky part in Sales Preferences which requires to be reset the Slots and Pages Cache on changes to any of the flags:

As a result, we get two Graph Extensions, which are separated in the code and are loaded only in case we need them to work going forward.

Summary

In this post, we reviewed two important features of the Acumatica Framework: 

  1. Activation of the Graph Extension on demand, using the IsActive property, and
  2. Database Slots, using the IPrefetchable interface

and how we can use them in practice. 

I hope this article provides you abetter understanding on how a developer can manage his code in multiple PXGraph Extensions and get more readable and less coupled code.

The source code can be found here: sampetrosov/Acumatica-CodeRefactoring.

Related topics you might find useful:

Samvel Petrosov

Software Architect – Information Integration Group, Inc.

Categories: Developers, Platform

Subscribe to our bi-weekly newsletter