Working in different environments
One of the many strengths of ResRequest is that users can work both online and offline. There can be any number of offline instances of the system and they all synchronise with the web when a connection is available. The different installations of the system are known as ‘Environments’ and these may include multiple ResRequest servers, this concept is described fully in the ResRequest architecture tutorial.
This means that reservations staff and property front office staff can work on the same system and see the same data. Furthermore, the reservations staff may be in different locations, potentially each with their own ResRequest server. There may also be multiple properties, each with its own server.
The responsibilities of reservations staff and front office staff are normally quite distinct, so we have to ensure that each of these groups ‘owns’ its own data. We achieve this by classifying each environment as being either a Reservations environment (include both web and offline systems) or a Property environment (offline system only). A user on one environment cannot change data owned by another environment, e.g. someone at a property working on the Property server cannot change a charge that a reservationist has raised for an agent on the Reservations office server.
Working with Master status
When a server can edit data it is considered ‘Master’ and when a server can only read and create new data it is considered ‘Slave’. Servers forming a Reservations environment can be replicated, with one instance on the Internet and any number of offline instances. Thus, there can be multiple reservationist users working concurrently on separate, temporarily unconnected instances of the same system; either on the cloud or offline. This can give rise to conflicting data updates. To limit the possibility of updates the system applies a rule that allows only one Reservations server to have data editing rights at any particular time – this environment has ‘Master’ status.
When an server is set to Master, users on this server have freedom to create, edit and delete information (within the boundaries of their specified user access) while on a server set to the passive Slave status, users may read information and create new bookings or new code tables but cannot edit or delete any data. It’s easy to identify what status your server is in by reviewing the computer screen colour in the menu bar.
In order for your teams to all work on one system using these different servers concurrently, one server must be set to Master, e.g. the web environment is set to Master while the Reservations office offline environment is set to Slave.This reduces the risk of conflicts occurring when data is synchronised during data transfers.
A Property offline environment operates differently to the Reservations office environments – it is always master of its own data, but can never edit data that is owned by (or created on) a Reservations environment or another property environment. This is why certain restrictions are applied to Property offline environments only. See the Important things to know about your Property server and ResRequest Architecture tutorial to learn more about the restrictions and benefits.
Changing an environment to Master
It is recommended that changing the server status is always initiated from the offline reservation server. Initiating the change from the offline server will change itself to Slave / Master and automatically set the web environment to the opposite, e.g. if you claim Master status on the offline server (RS), the web server (WB) will automatically be forced to Slave. This ensures that there is only one master environment.
To change status navigate to Admin > Operations > Master change > Set to slave / Set to master.
If you do not have access to the offline server be very wary of changing the status from the web server. We recommend that you contact and coordinate with your central reservations team before making this change to prevent any data conflicts. Data conflicts may occur if you have two servers with master status, which can happen if you force the web environment to master while your offline has master status, as the offline will not change status automatically.
What happens if there are two master environments?
There is a high risk of data conflicts as bookings may be made over the same dates and information may be changed on the same booking. These conflicts will cause the updates from one side to be lost when you run data transfers.
A data transfer initiated from the offline environment will suspend when it detects two masters. This is a failsafe to stop data transfers running. An automated email is sent to the system administrator to advise them of the problem and request user intervention. User intervention is required to fix any data conflicts. Once data transfers are suspended the reservation’s offline environment will need to: ensure any data conflicts are resolved, set one of the environments to slave and re-enable data transfers.
Working with multiple environments
It is important to realise the visual and functional differences if you opt to work with multiple servers and environments. Take a look at the same booking from a different server. The example below shows the visual differences between the Reservations web server (WB), set as Master (green computer screen), compared to the Reservations office offline server (RS), set to Slave (grey computer screen).
Users in the system set to Master are able to edit the itinerary of this booking visible by the green highlight over the itinerary line. The users in an RS system, set to Slave, are not able to edit the current itinerary and the itinerary lines are greyed out.
When in a Property environment, the user may not edit information created in another environment such as the Reservations office environment, or another Property environment. Additionally, certain system administration functions, such as setting up rates and managing user access, are not available on a Property server at all and may only be managed from a Reservations environment.
There are still a number of items that may be added to the booking from the RS Slave system such as Payments, Extras and new Itinerary lines. These may also be added in a Property environment.
If the booking was created in the WB environment, a user on a Property environment may add an itinerary item / extra onto the reservation but a separate folio will be created which is owned and may only be edited by the Property environment. See the example below:
Certain data, such as Rooming configuration, Notes and Nationality, may be edited on any server, regardless of Master status or environment.
The ability to edit Notes is also defined by a setting in your system Defaults > System Administration.
Tracking changes from different environments
If there are multiple users all working in different servers environments, track their additions and edits on a reservation using the Audit Trail. The Audit Trail tracks changes made on the reservation and includes the server in which the changes were made.
User access permissions/restrictions
You may be working on the system and realise you can’t access certain reports or are unable to edit certain areas of a booking. This does not necessarily mean you are restricted by the environment you are working from and may just be a user access restriction. See the User access section for more information. Consult with your System Administrator and confirm which areas you have access to.
Visit our website
