1 – The web-based interface tends to become ‘forgetful’ after a few hours of use; edits can be lost unless saved/activated immediately, or modifying the layout of graphical views becomes a problem.
Although the browser-based interface seems perfectly functional to me, after using it for several hours, it starts forgetting your edits, so you need to save frequently.
For example, when editing a graphical view, you change a formula; you go out of the formula without saving; go back into the formula, your change has not been remembered; or if you change the layout of a graphical view, it starts dragging objects you didn’t select. Annoying.
But the fix is quite simple: save your work frequently (probably good practice in any content-creating software 😊), and simply close your browser session and start a new one when these problems occur.
2 – The formatting of views changes when inserting a new object, and there’s no automatic way to readjust the layout.
From my perspective, the default layout in the graphic view leaves room for improvement. Our team tends to favour a more square and orderly arrangement. However, there’s a hiccup: whenever we add or delete an object, the layout stubbornly reverts to its default state. Unfortunately, there’s no automatic adjustment feature available.
For views of any size, this translates to extra manual work in reorganizing the layout—a less-than-ideal situation
3 – No Transporting between Spaces
Change Control is something that all SAP products do really well, and whilst there is a formal Transport between Datapshere tenants, there is no way to transport between Spaces within one tenant. Why would you need to do this?
Many customers will only purchase a 2-tier Datapshere landscape, i.e. Production and Non-Production, yet still want to emulate a 3-tier development lifecycle, i.e., Dev, Test and Prod. This is simply achieved in the Non-Production tenant by having Spaces dedicated to Development and Spaces (where objects are duplicated) dedicated to testing – hence the need for a transport mechanism from a Development Space to a Test Space.
The only way to do this at present is to:-
- export a JSON file
- adjust it manually for any views or tables that should be pointed at different Spaces
- import into the target Space.
A bit error-prone and time consuming. Not ideal.
4 – Error handling in task chains
The ability to continue after an error has occurred or add an action like email would be very handy and should be introduced.
5 – Some Standard SAP ERP data types don’t appear to map to a useful data type in Datapshere, and there is no function for Conversion
Long Text data types spring to mind here. Raw data fields such as STXB-CLUSTD don’t appear to map to a datatype or have an appropriate function for conversion.