Look…

I am grateful for all the blogs, but most of ’em do full stack development, and I’m just a poor backend developer. If you’ve seen how I dress, you’ll understand why I’m not allowed near a UI.

Here’s one I did earlier.

But…

Being an ‘umble backend developer, I just want to get the job done. I don’t want to understand the framework. I want the minimum possible to get the functionality the worshipful business analysts desire. ‘yer ‘onours.

So…

This is what I did.

I’ve got this application that works great in sapgui, but now the boss wanted it all “Fiorified”. He even got a some kid in to do the front end. (See here).

I’d tell you what the app is, but … it’s commercial, innit, so I can’t tell you. It’s a sort of Fire Fighter app. Anyway, three things needed

1. The config
2. Choices to choose from
3. Chosen

1 and 2 are the starting point of the Fiori app. It needs this information to decide what to show.

So I create three structures for each of ’em.

Then – just as a precaution, like – I give myself SAPALL and head off to SEGW.

Think up a decent name for the project then right click on Data Model. Import from DDIC. If you’re in the mood, you can change labels and give semantics. Don’t know why. Some kind of front-end thing I guess. I’ll leave it until the UI designer starts screaming at me.

You get one entity type per structure. If you’ve got any of those substructures – and I recommend you do – it’ll create complex types. Which is weird if you think about. Because they’re simpler types than the entities. That’s SAP for you. What can you do?

And that’s it. You click on Generate, and (if your auths are up to it – hence SAPALL) you get a lovely set of classes generated!

It’s quite clever really, ‘cos you can change your Data Model, regenerate, and anything you’ve created in the class that really matters (That’s the one ending in _DPC_EXT) doesn’t get overwritten. Goodness knows what the other classes are for. Don’t care. I’m just a developer. And so very very ‘umble.

The only methods you really need to care about is the _GET_ENTITYSET methods. They can be used for anything! OK, in my app, I want to use create, delete, update (that’s in Entity Sets in SEGW) – but I’ll figure that out later. Maybe another blog. At the moment, I’m only using _GET_ENTITYSET.

And…

It’s really easy. Go to that _DPC_EXT class. Override the _GET_ENTITYSET method and start coding. The parameter IT_FILTER_SELECT_OPTIONS contain anything someone put into a filter into the URI in a nice ABAPpy familiar format. So, query that to restrict the returned data and bung it in ET_ENTITYSET. Now, you could, if you were a bad programmer, put all the logic in the _DPC_EXT class, but I really really strongly recommend putting it into a separate class per Entity. It makes life so much easy. And I love an easy life.

URI? Say whut?

Sorry. Mea cupla and all that. Once you’ve created your classes and data model, you have to go to the intuitively named transaction /IWFND/MAINT_SERVICE. Click on Add Selected Services. Select your newly created service (it should be there – if not… well, I dunno. Just an ‘umble developer me) and add it. Now you can select it from the service catalog, and click on SAP Gateway Client, in the ICF Nodes window.

And now you can enter a URI. It’s like a URL, but it does more. Apparently. I don’t see the point of a different name myself, but internet nerds can bite… Click on EntitySets and choose one of your sets and hit execute. It’ll run that old _GET_ENTITYSET method without any filter! You can set an external breakpoint to verifiy it!

If you want to add a filter – and I know I do – it’s like this. Put something like $filter user eq ‘MATT’ after that /sap/opu/…EntitySet

If you’ve done it right, you’ll get all of that XML malarky. It’s ok to read, so you should be able to work out whether you’re in the right ball park. If not, just put an external debug point in and check the output.

Hint: every field in the filter must appear in the entity set.

OK – that’s it. Enjoy.