Seeing the different states in the SRM Framework and in the Bookings module in Cube might be confusing.
There’s a distinction between the booking stages in the core software and the booking life cycle when the SRM framework has been deployed, but is there a complete list of the booking states in the core software?
SRM Framework
Cube Bookings Module
Hi Jan-Klaas,
I have created a list of the different core software states below. As this information is missing from the ‘booking stages’ documentation page you linked, we will update that page to include such an overview.
- Pending: Bookings with this state will reserve the assigned resources, but will not execute any scripts or actions.
- Confirmed: Bookings with this state will reserve their resources and orchestration will be executed at the configured times.
- Ongoing: The Resource Manager will move bookings from the ‘Confirmed’ state to the ‘Ongoing’ state after running the start actions. It is not possible to assign this state to a booking yourself, the Resource Manager will always convert it to the ‘Confirmed’ state when trying to do so. More info about the start actions can be found in the documentation page.
- Ended: The Resource Manager will move bookings from the ‘Ongoing’ state to the ‘Ended’ state after running the end actions. Like with the ‘Ongoing’ state, it is not possible to assign it to a booking yourself. More info about the end actions can be found in the documentation page.
- Interrupted: If a booking misses their start, stop or any orchestration event because the hosting agent was down, the Resource Manager will move the booking to this state. The documentation page also contains some information about this.
- Canceled: The resources assigned to the booking are free to be used by other bookings, and orchestration will not be executed. The Resource Manager will never automatically assign this state, the booking must be updated from a script or similar to go to the canceled state.
Hope this helps.
Hi Jonas. I understand the confusion. To give you a quick summary:
The core software provides APIs for the creation and management of resources and bookings. The SRM framework uses these APIs and adds some features on top of them. For example, the 'lifecycle state' of a booking in the SRM solution is a custom property on the underlying core booking, and the transition between those states is done by attaching event scripts to that core booking.
I will see if there is anything we can do to make the distinction more clear in the docs and how these concepts are related. I definitely agree that there is not enough clarity at the moment as to which feature set is "core" and which are extensions that are provided by the SRM framework.
Hi Seppe, thanks. However, for me, for someone who never used SRM it is also not very clear from the documentation what the relation is between the core bookings and SRM bookings. From the documentation, it seems to be one and the same thing (everything is under "Service & Resource Management framework") which causes confusion for me. Some additional information on the architecture and how those two concept relate might help as well (at least for me).