Customizing using Plug & Play Methodology

Customizing the base JD Edwards objects without a proper methodology and control could finish in a nightmare, it's very important for your company to have a customization methodology well defined, without it, your system will be each day more complex and unstable, making it impossible to update or upgrade, you need to keep you change footprint as minimal as possible.

Making clones will not solve the problem, you will get as many copies of a program as customs you have making them impossible to get updated and you loss the Oracle support for that object.

Keep in mind, each developer or partner making changes in your system will do the things in their own way, having a methodology is critical to prevent that behavior.

The ideas on this post are complements for the JDE extensibility guide; please refer to that guide for more information.

The methodology:

1. You need to have a new Customs Activator Setup. This setup will enable to define a customization strategy, can identify what will be the parameters that enable your customs. Having the parameters you create a custom business logic associated with it, the parameters could be, among others, a set application/version, a set application/version/user role, application/version/Industry code/user id. This setup will be useful as customs inventory. The table must be in cache to improve performance.


2. The best place to hook you custom code should be the existing localization P&Ps, that will be your first choice. The P&P BSFN do not change so often as the base objects, so if the place is right and the parameters enough you can extend for instance the P4210 and apply later as many ESU you need without reapplying your hook.


3. If the there is no P&P in the place you need to add the logic or the existing P&P is not having the right conditions, create a new custom P&P similar to the localization P&P, but do not call the localization P&P, you could be adding unexpected behavior to the system.


4. The existing P&P or the new custom P&P should call a new object called Customs Server, it should be just a line calling it, in the existing P&P you will have the Country server call and the new Customs server call, in the New Customs P&P you will have just the Customs server call.


5. The Custom server DSTR should be similar to the P&P DSTR containing the same data Items but a different object. This data structures must contain the needed parameters to identify later the place the Custom Server was called, i.e. the application, the form, the event identifier


6. The Custom server call is the one that perform the logic to determinate what customs need to be executed, first will call a BSFN to retrieve the customs code, and having the customs code and the parameters that allows the custom server to know from where it was called, call the Custom code BSFN. In the custom server no other logic should be performed as table fetch or calculation.

In the next posts we will discuss the dos and don'ts, a few examples and the limitations

If you are interested in applying this methodology in your company, do not hesitate in contact us, we can help you. Additionally, If you find this post useful, please click in like and share, also any feedback will be appreciated.

Contact us at any moment you need help!