This content has been marked as final. Show 3 replies
There are a couple problems with what you're trying to do. You hinted at the first problem yourself when you said that "nodeName here is the nodes which *will be* falling into the order lines." At the time your Configurator Extension is executing, on the postConfigSave Event, the configuration has been saved but Configurator has not yet terminated. It is not until after Configurator terminates that the Order Line from which Configurator was invoked gets updated with sub-lines. Therefore, the sub-lines you are querying do not yet exist.
The other problem is that even if you were trying to update a field on the top-level Order Line, which does already exist, the Order Line is locked at the database level for the duration of a Configurator session. It is therefore not possible to update the Line from a Configurator Extension.
Is the value you're trying to set for the Demand Class somehow dependent upon values captured or calculated in Configurator? Or is the value you need to specify unrelated to the details of the configuration itself?
Earlier we tried to update it by hard coding which nowhere relates configurator.
Then we tried to update with selected option in the OptionFeature of the configurator.
But both way we failed to do it through extension.
Is there any other solution through which we can achieve it.Please let me know.
I assume that the reason you are using Configurator to drive an update to Demand Class is because the Demand Class actually depends on the EXACT configuration. For example, the selection of certain options in the configurator will change the Demand Class. If this is not the case, then you could be better off using an OM Defaulting rule that sets the demand class based on the item / item category / dff, etc.
Now, if you really need this to be based off of configurator, then you will need to better handling the fact that the OM lines are not returned until the Config Session is completely finished. In addition, the model line is locked during the entire process. This was discussed by Eogan in his prior post. One option to consider is the use of Output attributes. Store the value of the Demand Class in CZ_CONFIG_ATTRIBUTES and retrieve this value after the session is completed. In the past, I have used DB Triggers on OE Order Lines to retrieve the value from CZ_CONFIG_ATTRIBUTES and update specific values in the OEL table. However, for this case, I was only updating the USER_ITEM_DESCRIPTION field (something that would have minimal to no impact to the application functionality). Attempting to directly update Demand Class on OEL might have negative consequences. Unless you are completely confident in the downstream impacts of this field, I would only feel safe updating this field by using the process order API.
NOTE: One reason I caution updating Demand Class is because I have run into cases where standard OM functionality would NOT allow you to update the demand class when the configured item is linked to the ATO model. This leads me to believe that this value is being transferred to other locations in the application (probably related to Planning Manager/planning engine). If you manually adjust these values at the wrong time, you might negatively impact some of these downstream functions.