The second point in the list (Cross Dictionary Customizations – An Insight) is Writing 3rd Party Triggers. Triggers are classified as 3rd Party triggers, if we use the keyword “ByName”. I hope all of us know what exactly is a trigger and how it is written, when we read this post.

The following are the Triggers available for writing triggers on 3rd Pary products:
1. Trigger_RegisterFormByName
2. Trigger_RegisterFocusByName
3. Trigger_RegisterProcedureByName
4. Trigger_RegisterFunctionByName
5. Trigger_RegisterDatabaseByName

Syntaxes and explanations are best provided in Dex Manual, which can be referred. But let me tell you some of the complications involved in this.

First and foremost: 3rd Party triggers are comparitively less reliable. Maintaining our code with respect to each and every version release of the Parent 3rd Party product is mandatory. This can be experienced best by writing Procedure Triggers. For some reason, if the procedure is either amended with Parameters or worst case its been scrapped, our life will become miserable. That’s the sole reason, always, the dependency towards a 3rd Party product should be minimal.

We won’t be having any kind of release notes for the resources that are being either amended or removed or added. It is our QA’s responsibility to test our customization against each version release of the parent 3rd party and fix our customization, if needed.

Using #1 and #2 (SanScript Code & 3rd Party Triggers), we can achieve almost all kinds of requirements from the customers.

Customizing a UI resource (Form, Report, etc) will be the worst way of customizing. At any cost, we should try avoid doing such customizations, as this would cost us too much at the time of maintenance. I had faced this in one of my projects. I had to customize a 3rd party product’s screen to some extent and after all efforts put in and maintained it for number of version releases, one fine day, that screen was scrapped from the parent product itself, leaving me to grudge in frustration. I cannot keep this form, as the core dependency of that particular form is no more available in the parent product. I cannot scrap this functionality from my customization as it is somewhat critical to the client. The only way out for me then, was to redesign that form in my customization and establish all the missing dependencies. By then, we had skipped several deadlines.

One more thing, which is interesting as well as challenging, is the access of Table Buffers of the Parent Product from our customizations. You may want to access the Table Buffers for various reasons, such as Creating Records from your product, Retrieving records which may form a basis for your product, Populating records in a lookup designed by you specifically for your requirements, etc.

Among all these reasons, the most tricky scope of accessing buffers is, any Process-Oriented access. For instance, if a Sales Invoice is posted from the Parent Product and a subsequent GL Journal is created from that product, and if your customization require this new piece of information, then you will have to be very very careful in placing your code so that you get the correct table buffer values. Most of the Cross Dictionary customizations face issues on accessing the table buffers and almost always when they try to access in between a critical process.

More to come…

Vaidy