In my last blog post, I discussed the basic functionality and configuration of Editable Grids, a new feature introduced in Aras Innovator V12sp16. I recommend reading the previous article before continuing if you have not already done so. Just to recap, users can now edit records directly in search and relationship grids. 

As an Aras Administrator or Developer, you may have been left wondering, “Can I just enable the grid editing feature? What are the potential impacts?” If you have these types of questions, then I will answer them for you. One of the potential impacts to enabling grid editing is where you have a method written that validates the entered data. Another impact is where the entry of data in one field impacts the data in another field. These situations are addressed with the new client events called Change and Validate that can be hooked on ItemType properties. These events are very useful.  In this article I will provide input on how they work and a few related caveats.  

In the Aras Innovator 12.0 Programmers Guide, the new events are referenced as Data Store Events. This could lead to some confusion for those who have been working with Aras for a while. The Data Store is used to sync data across the client environment regardless of the UI control used to expose the data. These new client events are executed on form fields, search grid cells, and relationship grid cells allowing the Administrator or Developer the ability to create a single method that executes when data is edited on any of these controls. This is paramount because if you enable grid editing on an ItemType, you will need to account for existing business logic where the impacted properties can be edited.

Consider an example where we want to enforce that the Change Coordinator cannot be the same as the Managed By user on an ECO. Without regard for grid editing, this validation would typically be handled with server events onBeforeAdd and onBeforeUpdate hooked on the ECO ItemType or with a client event hooked to the onChange event of the Change Coordinator and Managed By form properties. When considering grid editing, if the validation is implemented as a server event, then nothing needs to change as the server event is still triggered when the record is edited in the grid. However, if the onChange methodology is the implemented approach, you will have to make a change in the implementation as the onChange form property events will not execute when the record is edited in the grid. This is where the new Validate event comes in.  

The idea behind the Validate event is to hook a method to the Change Coordinator (owned_by_id) and Managed By (managed_by_id) properties on the ECO ItemType. The method performs the validation and prevents the Change Coordinator and Managed By users being the same regardless of how the record is edited (form or grid). This results in one method that performs the validation everywhere the property can be edited and allows you to remove the method from the form properties’ onChange event.

Below is an example of the Validate method for the above scenario.

Copy to Clipboard