How complex are your OData models? Need your Feedback !
Dear community,
today I am asking for your help to find out more about the nature of OData services you are working with. We are currently defining the Ux specification for tools that should visualize OData models.
We need to understand what is the most common case for customers in terms of size of OData Models you as a customer work with.
- How many entity types typically customers work with in one service?
- How many entity sets typically customers work with in one service?
- How many complex types customer generally use in on model?
- How many function imports?
- What would be number of properties in each entity set customer would be using?
If you can provide some inputs based on the scenarios you have face, it would be helpful for us.
You can either post a comment to this message or you can contact me directly.
Best Regards,
Andre
Hi Andre
I'll start the ball rolling.
I am currently focusing on Fiori like apps, slightly different use case than typical Gateway developments. Fiori has a 1 service per app design pattern, which basically means you build fit for purpose, built from the screen, self contained services and don't necessarily focus on reuse or have a database like Entity design. Having worked a bit on UI5 desktop and Mobile developments you probably wouldn't apply the same design considerations.
hth
jsp
1. How many entity types typically customers work with in one service? -
Around 6 regular entities,
Another 10 Search help entities
2. How many entity sets typically customers work with in one service?
Same as entities. May be one or two more at max.
3. How many complex types customer generally use in on model?
1 to 2
4. How many function imports?
1 to 2
5. What would be number of properties in each entity set customer would be using?
In case of normal entities: 10 to 15
In case of search Help entities: 3 to 4
Regards
Krishna
Regards,
JK
Hi Andre,
OData services for our mobile applications usually consist of
I found that things that were designed as a function import later weren't needed anymore as the import properties were moved into the entity.
Best,
Marcus
Hi Marcus,
Could you please explain what you mean by "import properties were moved into the entity"?
Regards,
Binson
Hi Binson,
I meant that the parameters of the function import turned out to be properties of the entity in the end so that I could use $filter instead of having function imports. Also great if you use RFC mapping because of code generation (you can't map function imports).
Best,
Marcus
Hi Andre, For our mobile application we usually have the below scenarios.
> 35
2.How many entity sets typically customers work with in one service?
>35
3.How many complex types customer generally use in on model?
4-5
4.How many function imports?
3-5
5. What would be number of properties in each entity set customer would be using?
>5-20
Is there any problem for the service if we have more than 30-40 Entity Types??
Thanks
Uday.
Hi Andre,
To add to Krishna's comments from our team above, the UX for building oData services and the visual representation itself would be much better if it suggested and/or automated input help filters and related data types. E.g. when working with business partner details suggest some common filters for name/address/city/etc so that they don't each need to be created manually. Search help consumes quite a bit of time.
Also important in the UX would be testing accelerators to help the oData service testing go more quickly. Even something as simple as a quick display of results returned to validate, perhaps even including option to display in a dropdown or interact with it via a suggested ui5 element. E.g. list of document types, quick button to open the endpoint in a dropdown to help the developer see what they're working on in real time to see if they're getting what they need. ... I'll save the rest for a conversation later.
Just a few thoughts since the question mentioned UX 🙂
Cheers
Shaun
Hi Andre,
I am working on couple of scenarios where I have case study to access Netweaver Odata services from Salesforce. Salesforce wants to access the Orders, Invoices etc and I have created some real time demo scenarios and it is working good. Need to add some complex scenarios where I want to do complex relationship data search from Salesforce and see the performance.
Regards
RJ
Hi RJ,
thank you for your feedback and I hope everything will run smoothly. 😉
Would it be possible for you also to share numbers for my colleagues?
Hi Andre,
Regards,
Ekansh
Hi Andre,
Number of associations (or navigation properties) can be also one of the criteria which will determine how complex OData model is.
Regards,
Chandra
Hi Andre
I agree with Chandra,
Complex is a little loaded given "Complex Types" aren't in terms of implementation complex.
Is quite broad, does it relate to SEGW, Eclipse etc.
It may help to define "complex" and the motivations are behind the questions?
JSP
Hi Andre,
Regards
Prabaharan Asokan
Hi everyone,
In our company we are currently developing a healthcare solution in which Netweaver Gateway is involved. At this very moment the results are the following:
Regards,
Juan Alfonso Campo.
SIT-Matters.
Hi,
UI5- and Fiori-UX-like app development here, averaging from ~10 projects throughout the last year:
Still kind of hard to make generalizations here with OData design depending on project scope, FE target audience and BE requirements (see John's post).
+1 for Marcus with "function import later weren't needed anymore as the import properties were moved into the entity",
just my .02€, v.
Hi Andre,
here are our numbers:
Like others stated before, it varies depending on scope.
Hi Andre,
As per my experience every time it depends on requirement but I preferred below numbers -
1. How many entity types typically customers work with in one service? 5 - 8 ( 1 - 2 extra for more search help )
2. How many entity sets typically customers work with in one service ? same as entity type
3. How many complex types customer generally use in on model ? 1 - 2
4. How many function imports? Preferably none
5. What would be number of properties in each entity set customer would be using? 5 - 10
BR
Ashish
Hi Andre,
Changes with every requirements :
When RFC : 10-20, When code based : 6-10 and thus the entity types increases.
Regards,
Tejas
Hi Andre,
We have done GW development in current project providing below numbers for every SAP ERP Modules PP/PM/IM/WM/QM.
Thanks,
Syam
Hi Andre,
We had done some gateway development having below range normally found :
Regards
Vivek