Some time ago, I had to develop a custom BOL object for maintaining some custom tables. These were a set of tables linked by relationships. The model implementation came out ok. Since these tables were to be used in the sales environments and the views were to be integrated in the sales BSP components(BT*), I added the BOL model to the BT BOL component set. We went ahead and used it to create the BSP component. It proved to be quite a bit re-usable and we created three more BSP components using this model over the next few months. Everything was moved to production system, things were stable and as time went by, we thought no more of it. After some time, the client wanted to make use of the survey components and another team worked on it. When they included the survey work center for certain user roles and started testing it, things went wrong. Clicking on the survey work center links resulted in error and the error information pointed to the custom BOL object. When we removed the custom BOL object from the IMG customizing, the survey components worked fine. Now, the survey BOL component(SVY) was totally separate from the sales component set(BT and ONEORDER). Then, what could be the problem?
Well, the problem lay in the fact that I had used an identical name(Item) for a particular BOL object within my model. This was due to the impression that since I had used a Z-name space for my model(component and component set), I was free to name objects within it as I chose. I was satisfied with the fact that the object name was unique within the sales model(BT & ONEORDER). Obviously, that was not enough. When the user session is created, the BOL models are loaded when the users access various work centers and the models, once initialized, stay put for the rest of the session. When the model is loaded, the BOL object information is loaded and the objects are not, as one might think, protected within their respective component sets. It is the objects themselves which make up the BOL environment, meaning that they act like a "key" in the BOL environment. The component and component set are not part of this "Key". My problem was that the users had access to both sales and survey work centers. Irrespective of which component is loaded first, the next would end up in error as the BOL object name is supposed to be unique in the BOL environment. If you are interested, only the object name and object id(the table key) act as the key to the business entities. When the business entities need processing, the model is decided based on the object name and the respective implementation class will be called. In my case, the system wouldn't know which model to call. So, it will simply not allow same object names even though they belong to different models.
Now, what was I to do? These are exactly the times when you wish you had followed the "good" programming practices. Throughout the BOL implementation class, the names were hard coded. This time, I decided to do better. I started with the tables in which I had maintained the model information and changed the names. The implementation classes were next. This was the hardest part as I had to go through literally each and every method changing the hard coded values. The next were the BSP components using the models. Fortunately, I was fully involved in all the developments and I knew the places where the names were used. These were only a few, where we created the root object or called the search object. The next were of course the model nodes. I had to visit all the component, custom, window and view controllers and change the values in the attribute BASE_ENTITY in all the models. Though it was tedious, I didn't mind. I had learned one more "what not to do"! So, here I'm again working on another model and this time you can bet there will be a Z leading all my object names!
