Designing bug free MI Applications
In my previous Weblog, I discussed about how debugging plays an important role in MI project life cycle. In this web log I will introduce how design and development guidelines can reduce the number of bugs that can be encountered in future, thus also reducing the total project life cycle time.
Guideline 1:- Do it yourself
A lot of errors come in MI applications because of memory leaks thus its imperative that memory management is being done through coding and should not be left for garbage collector to take care of. Garbage Collector will do its job but you should also flush after you are done 🙂
Assigning all objects to null will make them candidate for garbage collection. In case of MI client applications developed in AWT and Swings, a lot of objects are being made for GUI like buttons, textboxes and others. GUI objects are generally reusable over the entire application. Design a GUI pool , which manages all the GUI objects of the application. At the start of the application, GUI pool should be initialized with a minimum number of objects, then as and when required, application should request objects from the GUI pool and when they are done they should release it back to GUI pool, now GUI pool can assign them to other requesting screens or sub screen areas. This will make our program independent of Garbage Collector, as the program does not have to wait for it to release memory of unused objects.
Pseudo Code for GUI pool
------------------------
GUIPool guipool= GUIPoolManager.getGUIPoolInstance(properties);
InputField nameField=guipool.getInputField(propsForInputField);
------------------------
Use the input field in the GUI creation
------------------------
guipool.returnInputField(nameField);
//this will also reset its properties
------------------------
This sort of object pooling can be done in all the areas where memory is very costly; the GUI pool is only an example of that case. As per the application and technology, different objects and their usage patterns should be identified which then can become a candidate for an object pool.
Guideline 2:- Always Keep your diary with you
You should always maintain a bug list that you have encountered in your project and use it as a benchmark when designing and developing a new system. Here is the common smart sync checkpoint list: -
1.) Always look for the existing business objects and their associated BAPIs in BOR or BAPI Explorer. If the BAPI does not exist then write it using either the recording or accessing the tables. I generally prefer recording.
2.) Always keep the following guidelines with you while developing BAPI Wrappers: -
- Processing type of a function module must be remote-enabled module.
- One parameter in the export should refer to a parameter in import.
- Parameter named RETURN where the type is BAPIRET2 structure needs to be defined as either Export or Tables parameter.
- The Business Object should contain both header and items. The import parameters should contain a table for items that is even if the structure of BO contains only header, the entire structure should be in place for both header and items. Define the items as a table parameter.
- Commit Work and Wait needs to be executed in the update BAPI wrappers (Create/Change/Delete)
- Perform the mapping and BAPI wrapper Interface Check.
One should always make and follow the rules to save time from both design and run time errors. Here is a sample attached of SyncoBO Mapping screen.
3.) At the client side always use the generated classes for doing your work. You will always find the required functionality in those classes. Classes like SyncBO and SyncBO Manager will fulfill the requirements in most of the cases.
4.) For testing your application either you can change the application name in the constant file to the already deployed application or can deploy a new one to web console and then you can run it again and again without future deployments using NWDS.
Guideline 3:- Keep it simple and clean
- Even though Generic Sync is used in most of the applications for simpler mass uploads and downloads in cases where it is not required to calculate delta but try not mixing it with Smart Sync in that application.
- Always make an iterative approach and create checkpoints in your code for various modules.
- Try to avoid usage of third party APIs. Example: Use MI Client Logging APIs for logging and not the third party APIs.
