With our team, we are looking deeper in our SAP processes, which are a mess.
So we are migrating them into EasyMorph, for a better comprehension, better management, and more.
In SAP, there are a big amount of tables, and some processes have a lot of rules and use a lot of tables.
We know that we can make multiple projects, like one per process, and organize a task on the server to make it run in the proper order.
But the processes are linked with each others, and it is way more efficient to search something inside one big project well organized than in 30 other projects.
In EasyMorph Desktop, our module list will be consequent, but our problem is inside a module : having a lot of tabs is a mess.
So we have questions, and maybe a feature request.
The first idea is to ask you to make a folder system for tabs (and also, if we can scroll faster in the tab list...).
Like inside a module you can create any tabs, it will be inside a module you can create any folders with any tabs inside. And of course move tabs from a folder to an other.
What are your recommendations when we need to use a lot of tabs and modules ?
Is one big project like that is something correct, and great if well organized ?
Or is it better to make a "parent" project calling multiple "childs" projects, each maybe calling others "childs" projects ?
Hi,
I generally have a rule that the vast majority of "best practice" is dependant upon the scenario. Put another way, it is only really best practice if it saves time. This can be your time developing and maintaining a solution. Or it could be time for a solution to execute.
For example, if building a solution a specific way is technically more efficient and will execute faster, that's probably worth doing if I am going to push billions of rows of data through it as it may run in 5 minutes instead of an hour. But if my data volumes are low, the difference may be only milliseconds, and so if doing it the "best practice" way will take me 10 times as long but I get no noticeable benefit in return, it shouldn't be considered "best practice".
In your scenario, there is unlikely to be any noticeable difference in doing it in one huge project vs separating it out into smaller projects. So it just comes down to which method works best for yourself and anyone else who might need to pick it up and modify it later. For me, I'd probably find a single monstrous project a nightmare, especially if more than one person may want to maintain different parts of the solution at the same time. A hundred tiny projects would also probably mean I'd waste time trying to find the right one and switching between them. Somewhere in the middle would be the sweet spot.
EasyMorph has some really great little helping features for working with solutions that span more than one project file. Actions which call another module or project files have links allowing me to quickly find and open them.
Of course we already use the action "call anorther module/project", and it's amazing
I think we will just need to take some time to look at how we can build the project, because yes you are true, each part need to be readable for any future worker.
I was asking if there is any recommendation in the usage of EasyMorph Desktop, because some tools can be a mess depending on how you build a project.
But with my experience and your answer, I think any solution could be good.
