Patterns

Primarily, you use Life Cycle Interceptors (LCI) to add extra validations. However, you should add minimum processing commands in the LCIs.

Your custom code directly impacts the following:

 

Performance Pattern

To improve performance of your LCIs, we recommend that, you:

One of the most common patterns that we have seen is the call to see if a unit has any active holds or required permissions.

 

Pattern: Make Extension Code Tolerant to Multiple Invocations

As mentioned above, a flush operation can trigger the call to the custom code multiple times. You can use the following code snippet to make your code tolerant of multiple invocations. The pattern relies on the fact that a unique transaction ID is generated. You can use the transaction's Unique ID to see if it is already logged.

  TransactionParms tp = TransactionParms.getBoundParms();

  if (tp == null)

   return;

  // the following call generates a new ID for the transaction if it is not already there.

  String transactionUniqueId = tp.getUniqueId().toString();

  String us = vvd.getVvFlexString08();

  if (transactionUniqueId.equals(us)) {

   return;

  } else {

   vvd.setVvFlexString08(transactionUniqueId);

  }

 

Pattern: Differentiate DataSources in the Life Cycle Interceptors (LCIs)

In N4, the entity updates can come from a variety of sources, such as SNX, EDI, ULC, Mobile, and WebServices; therefore, the LCIs can be called from any of these places. If you want to perform a particular action based on the datasource for the update, you can use code that is similar to the following code snippet:

// Following Code Validates Only UI Initiated Transactions:

           def dataSource = ContextHelper.threadDataSource

            if (dataSource == null)

                  return

            if (dataSource != DataSourceEnum.USER_LCL)

                  return

 

Pattern: Share and Centralize Groovy Plugins (Supported in N4 v. 2.0 and above)

Centralize the code for sharing and re-use. It is easy to export and import N4 Groovy plug-ins using SNX. The following graphic displays the recommended approach where the code in the Notice Request form simply delegates to the undelying Groovy plug-in: