Method event version type "Version 2" - where do we find more samples and guidelines?
Hi community,
does anyone of know how to use the "Version 2" type for ItemType Server Methods?
Let´s assume we use an onAfterAdd/Update event in the Part BOM ItemType. With Event Version 1 the event is fired for each single row. Which version 2 it would be executed on the complete item group.
From my POV version 2 is useful to improve performance for certain tasks. But there is not much information out there that describe how to use this version type.
The context item in version 2 is empty by default. So "this" simply contains nothing when we execute a Method with "Version 2". I assume that we have to extract the information of the affected items from the "eventData" parameter in the background.
I found some minor code samples in the code used for Effectivity and Derived Relationships. But they are to specific for being used in other contexts.
Does anyone know more about using "Version 2"? Thanks for any tip!!!
So far I haven't been able to learn anything new about this. But I still think Version 2 Methods are useful for "something".
I made some checks in legacy documents, cause they often cover these "forgotten" features. "Event version" was introduced in Innovator 11. It´s described in the dev and programmers guide, but there aren´t any samples.
My only wish is to have actions be able to use the version 2 configuration as well. I have a relationship that I want users to be able to highlight numerous relationship records to right click action >. Unfortunately, the execution as of now is very slow as I suppose it is rerunning the method each time per record as opposed to running with all in one context.
Also the method saves the Item's changes, which takes time as well. Which if there was a way to store changes in the frontend to render on the frontend, and letting the user click save later would likely be ideal
Vielen Dank für die Unterstützung dieses Beitrags!
Methoden der Version 2 sind für serverseitige Operationen gedacht. In meinem Fall möchte ich sie verwenden, um einige Flags und Zähler automatisch zu aktualisieren. Mit Version 1 würde diese Methode für jede einzelne Beziehungszeile ausgelöst. Das ist meistens kein Problem. Aber ich möchte die Geschwindigkeit mehrstufiger Operationen verbessern, die von ECOs mit Hunderten von Elementen ausgelöst werden. Sie sind nicht super langsam, aber aus meiner Sicht bieten die Methoden der Version 2 viel Potenzial.
Für Ihren Anwendungsfall: Warum nicht CUI verwenden? Dies ist die Auswirkungsmatrix einer benutzerdefinierten Änderungsbestellung, die ich verwende:
Der Benutzer kann mehrere Beziehungen gleichzeitig auswählen. Die ausgewählte CUI-Schaltfläche aktualisiert die Eigenschaften „Aktion ändern“ und „Neues Dokument nach Änderung“ auf der rechten Seite. Die Methode wird nur einmal ausgelöst.
You are correct in your original post that the information needs to be extracted from the eventData variable. It seems that there is usually at least a TypeId and an IdList property on this variable though it does change a bit depending on the event type.
Current result: TypeId works, but I only get one item id. I checked the eventData object. It looks like it only contains the first ID of my three new 'Part Document' items.
---
My use case would be all kind of indicators and something related to ECO Affected Items.
Typically I use onAfterAdd/onAfterDelete server events to update the tab counters and an unicode "has BOM" indicator in the grid. Solution is loosely based on the PE files flag concept.
Let´s assume user import a BOM via batch loader with 429 elements. The same Method would be triggered 429 times. This is currently no problem. Systems runs smooth and fast since years.
Occasionally, I refactor legacy code to enhance long-term maintainability and stability. The current solution to update these indicators with version 1 events just feels super wrong and inefficient.
With the above code at least the BOM indicator would work with version 2 events, as I don´t need to count the elements for this use case. But without the amount of relationships it will not work for the tab indicators.
I'm right now questioning whether this approach can actually work, or if V2 events were designed for a completely different purpose.
----------
Some side notes to the use case.
Eli once helped me to get the tab indicator idea running. End users would start a riot if I remove the feature.[emoticon:0f36700dfeb3494fa10d47dd9e1f90a1] But I still rate the concept as too experimental to promote it on a larger scale.
I have a rough concept to improve the overall feature with CUI in I14. Unfortunately I still use 12SP7. For my idea I need a few of the new CUI features, especially relationship accordions.
The current solution use a combination of server methods and a Form onLoad event. I want to get rid of both to achieve the ultimate fast and efficient tab indicator solution. It´s not as revolutionary as "something with AI", but I still believe it adds value.[emoticon:44a8a53ad3364ea78a16c5a3229f75bb]
