How to resolve the error BSP_WD_TOOLS304: Subobject type &1 is not valid for object type &2
Sometimes when we create/copy a configuration, we may encounter error: BSP_WD_TOOLS 304 Subobject type &1 is not valid for object type &2 like following.
Actually, The Object Sub Types that are regarded to be allowed for a certain UI-Object Type are determined by a Call Back Class, that is defined in the customizing for UI-Object Types and which implements IF_BSP_DLC_OBJ_TYPE_CALLBACK with method GET_OBJECT_SUB_TYPES( ).You can run T-code： bsp_dlc_sdesign to display the “UI Object type” settings to understand which call back class is used for standard UI Object types.
When you encounter the error “BSP_WD_TOOLS 304 Subobject type &1 is not valid for object type &2”, the reason could be:
1.You are using a customer z-Object type ZPRD_Z001 does not have a Callback Class defined, which implies that no other Object SubTypes are allowed than <DEFAULT>.
2.The standard call back class doesn’t allow your customer subobject type.
For above cause 1, the solution is following:
Please create a z-callback class for your z object type to retrieve your object subtype. For this you must create a call back class that is a Z class which must implement IF_BSP_DLC_OBJ_TYPE_CALLBACK with method GET_OBJECT_SUB_TYPES(), then implement method GET_OBJECT_SUB_TYPES() according to your requirement. You can refer to the standard call back class in T-code： bsp_dlc_sdesign。
Then go to following customizing and customize your call back class. [T-code: SPRO -> Customer Relationship Management -> UI Framework ->UI Framework Definition -> Define UI Object Types.]
For above cause 2, you can use the same solution I mentioned above for point 1 to create your own call back class.
Or you can debug in the standard call back class to find and understand why standard logic doesn’t allow your z subobject type. If you find any setting problem, you can correct them to resolve the error.
Here I provide you following two examples.
Example Problem 1 for view: ICCMP_BTSHEAD/BTSHeader:
1. In T-code： bsp_dlc_sdesign, we can see the Callback Class for Object Type BT126_INR(see above screenshot) is CL_CRM_UIU_BT_OBJTYPE_CALLBACK. Then we set breakpoint at method IF_BSP_DLC_OBJ_TYPE_CALLBACK~GET_OBJECT_SUB_TYPES of this class.
2.When debugging at following FM, we can see the cause is that the sub object type is not read into lt_pr_type which is for on-line transaction types.
3.Then we check transaction type ZLJI(sub object type) customizing, we find we set it as “Y Blocked for online Maintenance”. The standard logic will not load any “X inactive” or “Y Blocked for online Maintenance” entries. As webUI is for online processes.
4.After we blank this field “Inactive”, the error is resolved.
Example Problem 2 for view: SRQM_INCIDENT_H/IncidentHeaderEF:
1. In T-code： bsp_dlc_sdesign, we can see the Callback Class for above Object Type CRM_SRQM_INCIDENT is CL_CRM_UIU_BT_OBJTYPE_CALLBACK. Then we set breakpoint at method IF_BSP_DLC_OBJ_TYPE_CALLBACK~GET_OBJECT_SUB_TYPES of this class.
2.When debugging at following FM, we can see the cause is that the template type is not initial.
3.Then we check transaction type ZRQT(sub object type) customizing, we find we set template type as D.
4.After we blank this field “Template Type”, the error is resolved.
Please note that inappropriate callback method and entries in customizing table BSPC_DLC_OBJ_TYP will cause errors. So you need to involve your abaper to create method IF_BSP_DLC_OBJ_TYPE_CALLBACK~GET_OBJECT_SUB_TYPES of your z call back class correctly and test it thoroughly. If you encounter any problem due to your call back class, then you can refer to following KBA, to change it back to a standard one as a workaround.
1908034 – Error message “Entity could not be determined” and “Entity cannot be determined” on WebUI