Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

RAP: Abstract Behavior Definition, Dynamical visibility

ojados
Discoverer

Hello community!

Was checking some documentation and discussions here in regards on how to achieve to enable/disable dynamically some fields in the abstract entity that one usually provides as an input parameter in a custom action in BDEF.

Don't ask me why but I ran into the SAP Help related to the BDEF syntax where it does exist the possibility to create a BDEF as abstract. However, given (if Im not wrong) we cannot use projections on top of abstract entities enabling also its exposition as part of a service I wonder about the functionality and use cases of this feature. Would be great to use it together with UI annotation in a projection to make a real flexible intermediate screens. 

Is anyone able to provide some input about the possibilities of an abstract BDEF? 

Also, what's the "standard" way to make a parameter-abstract entity dynamic in terms of visibility/enablement of its fields? Is there any way to create a more complex popups than the usual ones?

Many thanks for your inputs, more than welcome!

Regards,

Daniel

4 REPLIES 4

aldimitrov14
Explorer
0 Kudos

The Abstract entity will allow you to define what data the Action will accept when the action is called. You can define the Abstract entity with whatever fields you would like to have, so that's why the possibility of creating a projection on top of abstract is just not needed. 

ELI5 - imagine the Abstract entity as a structure created in SE11, with the difference being that this abstract entity can be used as a parameter while creating a Action in the RAP Framework. You can also use the abstract entity as a structure when defining data elements e.g. DATA field type <Abstract CDS View Name>. 

0 Kudos

Many thanks @aldimitrov14 for your response.

Yes, I fully get the basic structural purpose of the abstract entity. 

It's also that same nature the one limiting the possibilies of displaying a popup, meaning:

- How do you make invisible a field depending on the value of an own field in the entity, or more complex (not sure if even possible), depending on the triggering instance?

- How do you compute a field responsively based on any other field/value? 

That's the reason why to ask if abstract BDEF would allow some solution such as field features.

In the same direction (abstract BDEF possibilities) I would also ask about the use cases of defining an abstract entity with parameters, still not seeing its functionality.

Thx!!

0 Kudos

Hi @ojados sorry I've missed your point initially. What you want to accomplish is to dynamically determine whether a field should be visible or not for example. I cannot give you a exact example as I haven't done that for abstract entities but I can provide you some information regarding how you can make a field hide or show dynamically based on another field. I don't know if you've tried this solution here -https://sapui5.hana.ondemand.com/sdk/#/topic/ca00ee45fe344a73998f482cb2e669bb

It looks like if you use the @UI.Hidden: #(‘<fieldname>’) annotation you're able to dynimically hide or show the field based on that field ( taking into consideration that the <fieldname> is a boolean ). 

So something like this might be possible: 

 

define abstract entity ZABS_ENTITY
{

  key processor : bool;
  @UI.identification: [ { hidden: #('processor') } ]
  dynamic_field: char10;
}

 

 I haven't tested that, but you can give it a try. According to documentation pointed above, this should determine the visiblity of the field 'dynamic_field' based on the value of the field 'processor'.

Same thing should be possible for other types of annotations as well.

0 Kudos

Hi @aldimitrov14 , thanks again for your input.

I gave it a try and not working, actually even if it did wouldn't be enough, meaning, that field processor you pointed out should be populated with a value from the triggering instance(s). How would you default that processor field?

Thought that maybe giving a BDEF to the abstract entity I could handle it through field features, but not working neither. Btw, already got the point (at least partially) of abstract BDEF: they enable deep structures in the input/output parameters 🙂

Then I hit with Operation Defaulting which is exactly what I was looking for, however seems available ONLY in the Cloud flavour 😒

// Create operations (name can be omitted):
create { default function; }

// Create-by-association-operations:
association _Item { with draft; create { default function GetDefaultsForCBA external 'GetDefaultsForCreateByAssociation'; } }

//Actions:
action PlainAction parameter myPlainParameter { default function GetDefaultsForPlainAct; }

//Functions:
function DeepFunction deep parameter myDeepParameter result [0..*] MyEntity { default function GetDefaultsForDeepFct; }

Therefore I keep not finding the key to make this possible, neither the way to format properly the popup window given that UI facets are not working.