on 05-16-2014 2:03 AM
Experts,
I am trying to implement a helpful feature in an application that I'm creating. What I'd like to do is discover the ABAP structure and field name (if they are defined, of course) for an arbitrary entityset/property combination.
For example, a request is made for ABAP definition information for an entityset called PurchaseOrder and property DocType, and the properties are created in the model through the usage of importing a DDIC structure. Given the entityset and property, can I programmatically discover the ABAP structure and field that these are tied to?
I have found one possibility, but I'm having trouble. It seems like there are several /IWBEP/I_SB* tables that could assist in this process, but for the life of me I can't figure out how to determine the project name that the entityset/property belongs to. If I could determine the project name, then I could use information in /IWBEP/I_SBO_ET to know the ABAP structure and /IWBEP/I_SBO_PR to know the ABAP field.
Is anyone aware of anything that might help me in this endeavor?
Paul
Hi Paul,
I would not use Projects for this as they are what you may consider a pseudo-service - the actual service is generated from the definition in the project.
I'm pretty sure this information is contained in the runtime model object and should be reachable through the model object introspection. You could bind to structures prior to SEGW coming onto the scene.
On another note, I'm assuming that you client is another SAP system. I'd try and avoid coupling too much to the ABAP Dictionary. True it does expedite development, but OData is not meant to be an extension of the Dictionary, the Dictionary integration is more of a convenience than a necessity. Just wondering why you feel the need to do this?
Regards
Ron.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks Ron.
Using the runtime model I've been able to whip up a little demo of what I'm looking for - so I appreciate the suggestion. This is much better than the path I was on before, as the model can change from what SEGW stores in the backend and what gets generated when the MPC_EXT classes run.
And your point is well taken about OData not meant to be an extension of the dictionary. What I am trying to put together is a sort of F4-value-help-like utility for an application I'm building, and rather than developing against every possible field that could provide some value help I'm trying to be a little more generic about it. It's not going to give me 100% coverage, and some cases won't be feasible, but I want to provide what I can to my users.
Thanks for your help,
Paul
Paul,
You already found that '/IWBEP/I_SBO_ET' links Project Name with Entity Names. Are you looking to find Project Name from Entity name? Since an Entity with same name can exist in multiple Projects, Entity cannot distinguish itself without the Project Name.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
If you have a Service Name, then you can get the Project Name from this table.
/IWBEP/I_SBD_SV
Now you have Project Name as well as Entity Name, so go ahead and use /IWBEP/I_SBO_ET
User | Count |
---|---|
90 | |
10 | |
10 | |
10 | |
7 | |
7 | |
6 | |
5 | |
4 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.