Development can be implemented in a different number of ways and depending on this your debugging can be more or less complex. Having rules will make it possible for all team members to easily identify the components of the development.
One good example is the addition of a new feature in a custom module, reading code that does not comply with best practices can make the task of understanding its reason and behaviour more difficult. Also, the work as a team can be blocked by that. For example, suppose you have a project where 4 players work in the same module, the development of a component can influence resource locking in Sage X3 (i.e. source).
The rules below are just some rules that I use within my team to take leverage of clean and organised code:
- Create a new activity code for every new customisation;
- Use the activity code in the codification of all new dev entities;
- Make use of switch processes;
- Create actions for all field actions;
- Do not load standard process at the folder level, make use of the entry points;
- Code everything using the approach of micro-processes. Reusability principles.
Let me explain with a real example, imagine that we need to create a new field to track the status of stock on Sales Orders using an API (runs on modification and creation of orders and also in batch mode):
As a Sage Partner, I will start my activity code by the letter Y (you can use X for verticals and Z for client customisations).
- My new activity code will be YST01 – Stock status API;
- A new field on Sales Orders table (SORDER) to save the status YST01STOSTA – Stock status;
- A new field on Sales Order screen (SOH1) to have the field visible YST01STOSTA – Stock status;
- Switch process pointing the MODIF and CREATION SOH object actions to a custom source YST01SPESOH;
- This will not lock the SPESOH for other elements of the team, and also will not provoke any issues while patching. The patching of this new source can be delivered as normal and the switch process managed manually;
- New funprog with the API call GET_STOCK_STATUS(YST01WSOHNUM) on the source YST01SPESOH;
- The use of funprogs instead of procedural code will make the reuse of code possible and also the testing easier because you can test micro-processes instead of a unique full process; Also this will make the process future proof for new adjustments since we can easily replace the API and the rest will not require adjustment;
- Using local variables codified with YSTW* to make sure you are not using the same variable in another process; How many times you used YSTATUS in multiple processes? And if you need to connect both processes? You get the idea 🙂
- You can even create a forced field action for the screen SOH1 field YST01STOSTA to update the status;
- Do not create the field action using the SPE. Instead of that, create a new action YST01STOSTA pointing to source YST01SPESOH subprogram UPDATE where you call the micro-process YST01SPESOH.GET_STOCK_STATUS.
- Add the call of YST01SPESOH.GET_STOCK_STATUS micro-process in the MODIF/CREATION YST01SPESOH process;
- Create a recurring task YST01STOSTA to run every day at 5 pm and update the list of open orders;
- Again, reuse the YST01SPESOH.GET_STOCK_STATUS micro-process.
Now if any other developer goes to the code he can see that the codification used is linked to the activity code YST01 (Stock status API) and can easily search by Activity Code and get the dependencies/entities of the development.
Hope this helps you organise and lose less time debugging & testing your developments, and give me a shout if you think I’m missing something 🙂