ALV IDA and CX_SALV_IDA_CONTRACT_VIOLATION
At the moment I am working with the SAP List Viewer with Integrated Data Access (ALV with IDA) in connection with Core Data Services ABAP (CDS ABAP). Since I’m still a beginner in both topics, I recently run into an error situation, unfortunately made by myself. Below are the situation and the solution described, so you hopefully don’t “shipwreck” too 😉 Here is the story.
The ALV IDA can be used with “classic” database tables or with an CDS ABAP view. Because I also wanted to learn something about CDS, that was a nice chance. So I built two “basic views”. The basic views were used to build a “combined view” which in my example also served as a “consumption view” (nested views). At first glance the data preview in Eclipse was fine. If I only had looked at it more closely.
I handed over the consumption view to the method CREATE_FOR_CDS_VIEW of class CL_SALV_GUI_TABLE_IDA. Then I tried different features of ALV IDA such as text search, handling of select options and also the double-click function together with a readout of the clicked row content (method GET_ROW_DATA).
While testing the double-click function, exception CX_SALV_IDA_CONTRACT_VIOLATION was raised. And then it became a little bit exciting because I didn’t immediately realize what I had done wrong. By exception, I had violated the “contract”. After some analysis and reflection, the cause of the error happily revealed itself.
First of all, even if you have little time to experiment, you should not give up rudimentary error handling. Maybe you know that too, that you focus on your actual goal, in my case on the double-click function, but less on the error handling. What should go wrong with a double-click including row reading? 🙂
After analyzing the error object, I still had no idea how to solve the problem. Due to years of experience with the “classic” ALV my thoughts revolved around an error cause in my ABAP source code. But thanks to the use of an CDS view we follow the principle “Code to Data”.
As a result, we need less source code because no selects from database tables and no enriching the output data for example by one or more LOOP statements are needed. On the other hand, the provision of the output data is “only” relocated, namely in the consumption view (and its subordinate views).
After some debugging of the application logic and some misconceptions, I finally found the cause.The key specification was incomplete in my consumption view. I had forgotten to mark a field as part of the key. However, the ALV IDA was really “unhappy” by the fact that the data was not “unique”. But to read out the content of a row via method GET_ROW_DATA, there must be a unique key.
What did I learn from this? The journey regarding ALV IDA and CDS ABAP has only just started and in my mind new thinking patterns have to be established regarding this technology 🙂
In that sense, don’t make the same mistake and save your time for something more meaningful.
Best regards and thanks for reading
Oh.. thanks for the hint. I ran into this error several times while developing Odata-Services... The first and second time took some time.. after that I remember this as first or at least second point to check...
So tomorrow I will use the ALV IDA and hopefully do not get a exception from the contract.. even if I select data from Wcocoh 🙂
Nice pun about table WCOCOH. If your development is for a customer: Pay attention to the contract 😉 I wish you success!
Oh, Wcocoh and get back to vbak and forward to vbrk and back to some rseg lines... sometimes it's a lot of fun and on one hand good to see what we can do with cds.. on the other hand a little bit disapointed that a cds is not smart enough to do a self-cast from numc5 to numc6. To be more precise to make a innerjoin with kposn and ebelp.
Had to create a helper-cds with a concat function to get it back on track... It's something to fix for the vendor:-)
But would say, till now I'm on track and no need to go without the alv ida