GRC Access Control have many feature which requires to collect information or change/provision information in your plugin systems. To do so, you need to implement an additional functionality to them what we call Plugin component. Depends on the type of the plugin system, it can be a standard ABAP based Add-on (GRCPINW) with additional features for ERP systems (GRCPIERP), or it can be a solution for HANA Database (HCOGRCPI). The other plugins are mostly handled by the main GRC system using the appropriate API of the plugin. To have a stable and reliable landscape you need to regularly update these components with corrections and based on our basic suggestion you should upgrade them at least once a year. You also need to ensure that your plugins are compatible with the main GRC system. But what compatibility means? Is it just the Service pack level what Note 1352498 or Note 2487192 suggests, or there is something else?
In a simple way what the Notes describes are true. Service Packs will always be compatible to each other, and if you just implement or upgrade your system it gives an easy way to achieve the compatibility. On the other hand the real criteria of the compatibility is not the number of the SP, it is what we call codebase equivalency. During a usage of a functionality the main GRC system and the plugin codes are often communicating with each other and what we need to ensure is the communication works the same way using the same signs and codes. In reality no matter what Service Pack are implemented to you plugin system, if this set of communication rules are the same. Compatibility can be reached by implementing the same set of Notes as well, however determining the right ones are much harder then simply implementing the same Service Pack.
Lets see an example of what we call code base equivalency and why the compatibility is important. With SP 21 the Firefighter Session management changed and a more secure and reliable option is introduced. Part of these changes a completely new locking mechanism was required which not allows to use the same Firefighter IDs by different Firefighter Users at the same time. The initial version of this process used already existing objects and tables to lock the Firefighter ID. This worked properly, unless the database containsed remnants of old and inconsistent data. To resolve it Note 3408121 was introduced which provided a new locking interface and dedicated tables to ensure proper locking. This Note is part of SP 24 and it contains coding changes in both GRCDND_A and GRCPINW as well. If you use just only Centralized Firefighter, then you need to implement it only on your main GRC system, if you use Decentralized Firefighter, then you need to have in both the main GRC system and in your plugins as well to have the compatibility. Why? Because it changes the way how the locking works and this need to be the same both the Centralized environment and in the Decentralized one as well. If you just implement it on your main GRC system you will see inconsistent behavior in the Decentralized Firefighter Logon Pad and vice versa if you just implement it on the plugin. This is an example of the code base equivalency.
Now upgrade your main GRC system to SP24 (which already contains the coding changes of the above Note), and lets just implement this Note to your plugin system. Now an older SP level of your plugin will also be code base compatible with the main GRC system, even if the SP levels are different. (Of course by implementing just this single Note will not made it fully compatible for every functionality, however this particular locking mechanism will be compatible with each other.) If you would just update your plugin system to SP24 and leave the main GRC system on a lower SP level but implement the Note to your main GRC system then the compatibility would be also achieved (with the same limitation as in the previous case).
The compatibility is not (necessary) means that you need to have the same Service Pack level and you can have even a higher SP levels on your plugin system as well, if and only if, the compatible set of Notes are implemented to the lower-leveled system as well.
Implementing the same Service Pack level fulfill the requirement for compatibility without any extra effort. It is the easiest way to have it, however it is not the only one, and you don't need to be on the same Service Pack level to have the same code base and have compatibility.
