How to solve simple requirement with RAP, Fiori Elements and FPM

[pfoehn]

Dear RAP / Fiori Elements / FPM Developers

I am lost, please help me find a solution or clues how i can develop this simple App lined out to you below with Standard Tools like RAP, Fiori Elements and FPM.

The essence of the app is: A List-Object App where the List displays a table of Employees and the Object Page shows the Documents for a selected Employee. Documents can be uploaded, changed, deleted. Employees can NOT be created, updated or deleted.

Leading Entity: CDS_LIST_OF_EMPLOYEES
No Behaviour Definition, it is not allowed to change or create Employees. Data from multiple Standard SAP Tables PAxxxx

Composition: CDS_LIST_OF_DOCUMENTS  (1 Employee has * Documents)
With Behaviour Definition: Upload Document, Delete and Change allowed. Data is in a Z-Table.

Sounds simple? 
I tried out now so many ways, always within the boundaries of RAP, Fiori Elements and FPM (Flexible Programming Model). I went from a pure Fiori Elements App to a Custom Page and Building Blocks from FPM....to no avail. It always felt like I scratched the boundaries of these technologies...with this simple requirement!

For me the best guiding tutorial was from Marius Freitag / Devtoberfest:
https://www.youtube.com/watch?v=SMc1ZzKAWW4 

Yet I couldn't get my app running after hours of "translating" the offered solutions in this video to my specific requirements.

Also glad if you could share your experience with these technologies in REAL LIFE environment (within SAP Modules) and not these vanilla cases of the tutorials.

Thanks so much for your input.
Kind Regards
Paul

[pfoehn]

Dear Patrick

Thank you for taking the time to answer to my post. I appreciate it.

Review of your solution:

Acutally my first attempt was a lot like yours with pure Fiori Elements and Preview in ADT, only I used V4 GUI (wonder why you used V2?). 

I also used "fake" internal create, update, delete operations on a "fake" Employee Table (in your case zpw_empl) in the behaviour defintion, as it is a must that the root entity (Employee) is defined in the behaviour definiton. 

What I miss in your solution is the business requirement to have a list of employees first  from a HCM System (Tables PAxxxx, SAP delivered or Custom CDS does not matter), where you can filter and select an EXISTING employee and only then the object page with a list of uploaded documents for that selected employee. Instead you display just a list of uploaded documents with associated emplyoee data from a table/cds (zpw_empl) that does not exist in HCM. Thus in your solution there will be no entry in the list, if the employee has no documents. 

Please see my attached screenshot (Fiori Elements with ADT Preview of RAP with V4 GUI).  And then the odyssey began!

I will of course try out your V2 solution (with my specific requirements) and let you know how this worked out.

Kind regards
Paul

PS:
To complete this real life business case I have to 2 more requirements (among others)
which give me a headache with RAP, Fiori Elements and FPM:

1) I need a value help on the field "LZ" in the List (see attachement) which will
    display a "hierarchy" (there are many hierarchies in FI und HCM).
    If the End User selects a "father" Node (LZ) of this hierarchy, the list of employees
    must show all employees of the father node (if any) including those who belong to a
    "child" Nodes. 
2) Depending on the user starting up the App the list of employees will always be
    filtered according to this "structural" Authorization (hint: in HCM HRP1001),
    this is again a Hierarchy. If the user is defined as "HR Document Administrator" to a      node, he is able to add, delete, create document for users belonging to that node
    (and child  nodes). Can't be solved with standard access control.

[patrick_winkler]

OData V4 is fine, of course. I just wanted to spare the draft handling for the demo.

"Thus in your solution there will be no entry in the list, if the employee has no documents. " => No, it will also show employees with no documents

[patrick_winkler]

(2) Can't help with the Access Control Definition for the read access. But for "add, delete, create" you can define instance authorization checks where in the implementation you can decide on instance level which operations are allowed

[pfoehn]

I can't see how your solution is covering this requirement:

[pfoehn]

Can't see this in your solution: No, it will also show employees with no documents