My recent project had a very interesting requirement. Our customer wanted to use its own configurator for performing the item configurations. When the user is finished configuring the product, customer wanted the standard B2C to resume. Though it sounds quite simple, it had its own set of challenges. In this blog, let me share one of the major challenges that we faced in developing such a custom solution.
If you think of same implementation in B2B scenario, there are many exits available in CRM in which developers can easily replace the item’s external configuration. However this luxury is not available to E-commerce developers. When we tried to simply set the “external configuration” object returned from a custom configurator into the IPC item of the configuration, it just stopped working. Our external configuration set in the root item could never make it to the backend. The Standard B2C does not recognize this external configuration and replaces it with some default configuration that is available in the backend.
After long trials of various approaches, we reached the following solution approach:
- We created our own implementation of RfcIPCClientObjectFactory. This custom factory is extended to create instances of the custom IPC Item (Z_RfcDefaultIPCItem) and custom IPCItemProperties. And these custom objects were created based on a customer-specific parameter, let’s call it – configuratorType. This parameter is maintained in the master data for each configurable item in CRM.
- Next step was to create the custom Z_RfcDefaultIPCItem. For the creation of an IPC Item, an instance of the RfcDefaultIPCItemProperties is provided to the creator methods in the IPC factory. The custom implementation of the IPC item contained an instance variable, which holds the external configuration received from custom configurator. The received configuration is then used instead of the standard configuration.
- We also extended the RfcDefaultIPCItemProperties to contain the “configuratorType” attribute. If the specified attribute indicates that this item needs to be configured by custom configurator, then custom IPC Item i.e. an instance of Z_RfcDefaultIPCItem, is created.
Another task was to populate the value of “configuratorType” so that it is available when item is being created. This helped to decide as to which of the following IPCItem needs to be created: custom or standard. We implemented this logic in the customerExitSetIPCItemProperties() of the BasketDB class. This is a standard method that provides the possibility, to easily extend the item properties of a sales document, accordingly to special customer requirements.
By doing the above, we were able to handle the external configuration of the items that were custom – configured along with supporting the VMC-IPC configured items.
Hope you find the article interesting and helpful. Wishing you all a very Happy New Year!!!