Hello James, hello Narenda,
at runtime, the node category must be defined by one of the following options
- It is handed over by the help of io_modify while creating the instance in the implementing class of an action/ determination/validation
- The standard node category is taken
- The node class is implemented (allows to define a method to dynamically select a suitable node category for a certain instance)
To sumarize, the setting the node category for a certain instance is only possible during the creation modification of the instance by the options (1)-(3). Later on, the node category of an instance can't be changed again. In addition this is an ordered list of options: So only if (1) is not provided, (2) is automatically chosen, if (2) is not provided, option (3) is chosen.
As described by Bjorn, you can define what kind of behavior shall be executable for instances belonging to a certain node category. For instance, a property determination may be configured for instances of category A and a different property determination may be configured to category B. However it would be possible via io_read->retrieve (ET_NODE_CAT) get the instances and their node categories to implement the property behavior in just a single determination for both categories A and B.
To also make one thing clear: Node categories are only BO internal, that means you can read them via IO_READ and you can assign an instance via IO_MODIFY however the consumer outside can't neither see or set them via the service manager.
Attention:
If you don't have already consumed node categories in your business object, I would not recommend to introduce them. At the moment (and there is no change in the near future) they are not supported in the new BOPF development environments like BOBX or BOPF in Eclipse anymore.
Regarding real word examples: Node categories are sometimes used in cases where you would use inheritance in the OO world. That means use cases you have very similar objects that however have a slightly differentbehavior, for instance having additonal actions. A real world example is a node that is called ACTIVITY and it manages different kind of activities - depending on the kind of activity, different actions are allowed to be executed.
Best regards
Tilmann