For those interested in linking custom tables to the BOL model BT(Business Transactions), here's an update. This is a follow up of the already published wiki Extend BOL model BT with custom tabe type relationship . As of now, the steps involved in the wiki involves enhancing some standard classes. The good news is that this can be entirely avoided. For those who are feeling adventurous here's the way to do it. The basics remain the same and can be read up in the wiki. I will list down the differences.

For implementing the handler classes, try to follow the BOL object runtime classes  "CL_CRM_STATUSSET_RUN_BTIL" for the header set (static read only relation) and "CL_CRM_STATUS_RUN_BTIL" for the actual item type relations. You should think of your own way of supplying the API data. The API data for the standard CRM objects is supplied by the ORDER READ function modules. You should replace it with your own methodology and take care to supply data according to the scenario. For example, you should be able to determine whether it is necessary to read(initial read) from database or from  the buffer(under processing).

Next you should register certain function modules to be called during the course of standard ORDER events for various scenarios. Here's another good thing. If your extensions are valid only for a particular business object type, do this. Specify your own ORDER object in CRMC_ONJECTS. Next, specify this as a sub-object of a business object type by maintaining entry in "CRMV_OBJECT_ASSI". Next, when you are maintaining BOL objects in the IMG activity "Extend Model for Business Transactions with New Nodes", use this value under column "Object Type".

Now you should register your callback function modules to be called during the CRM ORDER events. To find the appropriate places where you need to insert your own FMs, analyze the order of events for different scenarios. Set user parameter "CRM_EVENT_TRACE" to "X". Do some order processing stuff and look what events were fired in transaction "CRMD_EVENT_TRACE". This will give you a general idea. In general, you will need to register events for initialization, save, delete and copy. First maintain the callback FMs in CRMV_FUNC_ASSIGN. Then, create entries in the event handler table. This activity is available in IMG activity "Transactions->Basic Functions->Edit Event Handler Table". This is for customer specific entries. To see the standard event handler entries, use transaction "CRMV_EVENT". Though you can maintain entries here, I'm not sure if this is recommended.

Be sure to use your custom CRM object type for the init and save events. This way, the initialization will be triggered when the order being initialized is of the relevant business object type. For the save to be triggered, you must register for saving when you detect a change scenario in your API. Use the FM CRM_EVENT_PUBLISH_OW to publish the change. This will register your custom CRM objects for save. You can probably put this in the maintain method of your "runtime" class.

*     event AFTER_CHANGE
      CALL FUNCTION 'CRM_EVENT_PUBLISH_OW'
        EXPORTING
          iv_obj_name   = 'ZCUST_I'
          iv_guid_hi    = lv_header_guid
          iv_kind_hi    = 'A'"gc_object_kind-orderadm_h
          iv_event      = gc_event-after_change.

This will trigger the callback FM registered for the save event(of your custom order object) when the order is saved.

The deletion should probably depend on the general order(BUS2001), event "After Delete". For copy and follow-up events, check out the "After Create with Reference" events.

That's it for now. I will update the wiki some time soon, hopefully with some more details. Hope you have fun exploring :)

      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!

Actions

Filter Blog

By author:
By date:
By tag: