Custom Plug-in Overview
A custom plug-in is customizable functionality that is defined by an interface. When an interface is defined, third party solution providers can develop custom plug-in implementations and bundle them as part of a SuiteApp. After the SuiteApp is installed within an account, a solution implementer can define one or more alternate implementations. These implementations allow the solution implementer to customize the custom plug-in’s logic to suit specific business needs.
The object-oriented interface is central to the plug-in model. To be more exact, a plug-in is an interface. Plug-ins do not act as APIs. In other words, a plug-in does not expose a class’s functions or objects. It allows a third party to override the logic defined within it’s default implementation.
A custom plug-in interface defines the function names, their parameters, and return types. Interfaces can be called within any third party server-side SuiteScript, with the exception of Mass Update SuiteScripts.
Functions referenced in a custom plug-in interface can only be called within the custom plug-in implementation by the solution provider.
The solution provider defines a custom plug-in’s default logic in a default implementation. If applicable, the solution provider may define one or more alternate implementations.
Alternate implementations must be associated with a plug-in implementation type, a standard record type in NetSuite. When a solution provider releases a custom plug-in with alternate implementations, these alternate implementations cannot be edited by solution implementers.
When the custom plug-in’s implementations are installed or defined within the users account, the end-user’s NetSuite administrator activates the implementation or implementations available to each account, and is then able to select which implementation to use. Whether a custom plug-in can use a single or multiple implementations at one time is dependent upon the design of the custom plug-in. When an implementation is active, function calls made within the custom plug-in script execute that implementation’s logic.
Sample Use Case
Consider a SuiteApp that includes logic for calculating asset depreciation. The solution provider turns this functionality into a custom plug-in. The solution implementer then overrides the default functionality with one or more alternate implementations based on the specific accounting principles and business requirements of the end-user.
In an alternative scenario, the solution provider releases the custom plug-in with multiple implementations, by-passing the solution implementer role. The end-user’s NetSuite administrator chooses (activates) which one to run based on the end-user’s needs.
Custom Plug-in Types
A custom plug-in type is a record type within NetSuite used to encapsulate a custom plug-in’s implementations and any supporting library files. The name of a custom plug-in type is used to distinguish its implementations from the implementations of any other custom plug-in installed on an account.
The custom plug-in type is used in the following ways:
Solution Providers
-
After a solution provider defines an interface’s default implementation, they must create a custom plug-in type record for it.
-
After a solution provider defines an alternate implementation, they must specify which custom plug-in type the alternate implementation belongs to. They do this by creating a new plug-in implementation record. The new plug-in implementation record is a child record to the custom plug-in type record created for the default implementation.
Solution Implementers
-
After a solution implementer defines an alternate implementation, they must specify which custom plug-in type the alternate implementation belongs to. They do this by creating a new plug-in implementation record. The new plug-in implementation record is a child record to the custom plug-in type record created for the default implementation.
Administrators
-
The Manage Plug-In Implementations page is used by administrators to manage all plug-ins installed on an account. Administrators use the custom plug-in type name to distinguish a plug-in’s implementations from the implementations of other custom plug-ins installed on an account. For more information, see Managing Plug-ins.