Services

The Central Server Service is used to collate measurement data collected by the Central Server solution.
This tool enables business-critical services to be shown in the context of IT services.

Services are defined in the Master Data web app because they are used by various Central Server web applications such as Reporting, Dashboard, Alerting, etc.
As a result, users are able to manage all service-relevant attributes from a single, central point and to use them throughout the Central Server solution.

This means that different Data Sources can be combined in a single Service.
It is also possible to determine which Locations the Service should take into account (i.e. where the data comes from).
Contractual terms can be entered such as service times or planned downtime for maintenance work.

A Central Server Service specifies the following attributes for this purpose:

• Name
• Description
• Time Zone
• Locations
• Service Times (Location-based)
• Holidays (Location-based)
• Planned and Unplanned Down Times (Service-based)
• Data Sources (timers, checkpoints, etc.)
• Service Log
• Excluded Measurements (Location-based)

Users can create any number of Central Server Services, each with different attributes, for the measurement data collected.
Different target groups can therefore be provided with the information and views that are relevant to them – without adjustments for one target group having an effect on the way that information is displayed to other target groups.

An overview of the Central Server Services set up in the System can be found in the Master Data web app in the Services section:

Multitenancy

Services are created in the context of the Customer currently selected.
Standard users can only see Services for the Customer they are associated with.

System users may freely select any Customer.
After selecting a Customer using the Customer Switch, work carried out by the System User is performed in the context of that Customer.
New Services created by system users are then associated with the selected Customer for use by that Customer's users.

Menu

The Services section contains the following menu items:

Service

Clicking on the name of a Service in the list takes users to the detailed view for that Service:

Various Service attributes and parameters can be adjusted here:

Locations

All measurement data collected by Central Server comes from a uniquely identifiable Location.
Selecting Locations in the Service determines which Locations should be taken into account within the Service as data suppliers.
Data that comes from Locations that are not part of the Service will therefore not be displayed in views based on that Service.

Each Location is associated with a distinct time zone. The time zone stored in each case can be adjusted for individual Locations in the Master Data section of the Master Data web app.

Because Locations can differ from each other as to whether certain public holidays apply there or not, each Location can be linked to a holiday calendar.
These holiday calendars are set up and managed in the Holidays section of the Master Data web app. It is possible for one holiday calendar to be used in multiple Locations.
Equally, one Location can also use more than one holiday calendar. In this way, public holidays that are the same across multiple regions can be managed in a central holiday calendar, which is then supplemented by region-specific calendars relevant only to specific Locations.

Menu

The Locations section within a Service contains the following menu items:

Service Times

Provision of IT Services often only has to be guaranteed during certain contractually agreed times.
Where necessary, however, Central Server collects measurement data around the clock. This enables a complete picture of IT Service performance to be created.
For a report that is intended to reflect the contractual situation according to a Service Level Agreement (SLA), however,
only the measurement data that falls within the period of guaranteed IT Service availability is of interest.
In order to be able to show this within the Central Server Service, Service Times are defined.

Using continuous (24/7) measurement data

If you want to make use of measurement data collected around the clock, seven days a week, then simply select Default Service Time "All day - Daily", which is set up automatically when creating a new Service.
You may have to adjust the start date if measurement data has already been collected before the Service was created and needs to be included for analysis.

Simple method to limit measurement data collected using Default Service Times

If there are contractually agreed Service times or if you want to limit the collected measurement data used in evaluations based on time periods, then the easiest way is if all users of the IT Service have the exact same working hours.
If this is the case, then it is sufficient to define these times in the Default Service Time section.

Example
Contractually, the IT Service measured using Central Server must be available from Monday to Friday from 8 am–7 pm and on Saturdays from 9 am–1 pm.
All the Locations where the Service is used are in Germany and therefore have the same time zone. In order to show this, make the following entries under Default Service Time:


• For the Service time Monday to Friday from 8 am–7 pm, select the start date from when this is valid, in our example August 4.
• As the Service time does not cover the whole day, uncheck the option "All day".
• You can now specify the start and end of the Service time.
• As this Service time will recur regularly, select the "Repeat" option.
• For Monday to Friday, this involves a period that repeats on a weekly basis. Therefore select "Weekly" as the repeat cycle.
• The repeat function is expected to apply every week, so "Repeat every: X weeks" must be set to 1.
• Use the check boxes to define the weekdays on which the repeat function should apply.
• Lastly, you can define an end date for the repeat function. This may also be done later. If there is a contractual change, you can retain the Service time periods used for historical measurement data, and set up new ones for the measurement data collected from this point in time.
  Please note, that an end date specified in the field Ends On is excluded from and does not belong to the Service Time.



Repeat this process for the Service time on Saturday, but instead select the times 9 am–1 pm and limit the weekly repeat to Saturday.

There is no need to select a specific Saturday from the calendar.
The System automatically calculates which Saturday comes next after the start date you selected and takes this as the starting point.

Measurement data from Locations with different Service times

If you measure your IT Service from multiple Locations where Service times differ,
then it is no longer sufficient to use the Default Service Time to show this.
In this case other Service Time Calendars must be set up.

Use the + icon at the upper right in the Service Times section for this purpose. This opens a wizard that helps you with configuration.




• Because Service times relate to Locations, as the first step please select to which Locations the Service times should be applied.
  If the desired Location is not shown here, then a Service Time Calendar may already exist for this Location, or is not yet part of the Service.



Note: So that using Service times does not get too complex, at this point we recommend only selecting Locations that are in the same time zone!


• A Service Time Calendar can only exist if it contains at least one Service Time.
  The wizard therefore next asks you to add a Service time.
  This can be done exactly as described above in the Default Service Time example.
  




• Add more Service times as required and end the wizard by clicking "Next" and then the "Finish" button.



• In addition to the Default Service Time, you should now have another Service Time Calendar.
  For Locations that have their own Service Time Calendar, only the dedicated calendar is used.
  For Locations that do not have their own Service Time Calendar, the Default Service Time is used.





• Repeat the set-up process for new Service Time Calendars until every Location included in the Service has the required Service times.

Service times for Locations that are in different time zones

Some of the IT Services measured by Central Server are used from different countries.
In such cases, it may be that the measurement data comes from multiple Robots that are in different time zones.
The working hours of the users at different Locations may differ.
It is therefore necessary for the IT Service to be provided at different times in the different Locations.

In order to be able to show this in the Central Server Service, please set up different Service Time Calendars as described in the previous example.
You can then define the Service times applicable to the Location(s) in these Service Time Calendars.
When doing so, please bear in mind that these Service times are automatically defined in the time zone of the Location(s) to which they apply!
This means that you can specify the Service time directly as it applies locally without having to convert it.

Example
At your company, the email IT Service is used at four Locations (Berlin, Darmstadt, New York, and Sydney) and monitored by Central Server.
In this respect, utilization of the email IT Service must only be contractually guaranteed during local working hours.
People work in Berlin and Darmstadt every day from 9 am–6 pm, in New York from 6 am–4 pm, and in Sydney from 8 am–5 pm.


In order to show this, three more Service Time Calendars are needed in addition to the Default Service Time Calendar. These include one for New York and another for Sydney.
Because Berlin and Darmstadt are in the same time zone and the same Service Times are expected to apply,
it is recommended to set up a shared Service Time Calendar for these two Locations.

If you are not sure whether Locations are in the same time zone and whether it therefore makes sense to combine them,
please refer to the list of Service Locations. The time zone is shown here explicitly for each Location.

At this stage it should be pointed out again that the same Location may only be allocated to one Service Time Calendar.
Locations can also only be allocated to Service Time Calendars that already form part of the Central Server Service.

Different time zones in a Service Time Calendar

In theory you also have the option of setting up a Service Time Calendar that is valid for Locations in different time zones.
In our experience, however, this tends to lead to lack of clarity when it comes to evaluating measurement data.
The reason for this is that the Service times defined in the Service Time Calendar relate to the time zone valid in the Location.

Example
Let us assume that people work every day from 7 am–7 pm in the four Locations of Berlin, Darmstadt, New York, and Sydney.
It would then be sufficient to allocate these four Locations to a shared Service Time Calendar.





These Locations are in three different time zones, however.



You must bear in mind here that one entry in the Service Time Calendar effectively results in four Service times being applied:


• 8:00–19:00 (GMT +01:00) in Berlin
• 8:00–19:00 (GMT +01:00) in Darmstadt
• 8:00–19:00 (GMT  -05:00) in New York
• 8:00–19:00 (GMT +10:00) in Sydney

To put it another way, although it looks like the same time range is given,
due to the time difference the Service time in New York starts six hours later than in Berlin.
At the same time, the Service Time in Sydney is almost finished when users in Berlin and Darmstadt start work.

Even if you feel confident dealing with time zones yourself, please bear in mind that it must also be clear to a recipient of
a report as to why measurement data that comes from a particular Location is part of the report in one case and not in another.
This will determine whether the measurement data is within the Service time or outside it.
This is much easier to understand if you can explicitly see that a Service time uses a single time zone.
That is why we recommend only using one and the same Service Time Calendar jointly for multiple Locations if these are in the same time zone.

Special case: All employees worldwide work at the same time

Some companies that operate worldwide have experienced that the time difference between the company Locations has a negative effect.
They have therefore decided that all employees worldwide should orientate themselves around a single time zone.
This is normally the time zone of the company headquarters. If this is in New York, for example, then all employees conform to the working hours that apply there.
Let us assume that works starts at 8 am in New York, so employees in Berlin, for example, therefore start work at 2 pm local time.

In order to show this concept in Central Server, it is recommended to award all Locations the same time zone when setting up the Locations in the Master Data web app.
This enables users to use the Default Service Time in the Central Server Service to set up the agreed times,
without having to set up another Service Time Calendar or take the time difference into account.

Menu

Planned Down Times

Planned Down Times describe a time window during which it is known that an IT Service cannot be used.
Such time windows are usually agreed in order to be able to carry out maintenance work on IT infrastructure.
These may be isolated cases, such as updating to a new release.
They can also involve regularly recurring events, however, for instance to carry out larger data processing operations.

Because such downtime is contractually regulated and approved, measurement data that is collected
during this time should not be taken into account in evaluations.
This can be shown in the Central Server solution by means of Planned Down Times.

A feature of downtime is that the whole Service is unavailable, which is the case in all Locations where it is used.
When downtime is set up, the time zone that the Service uses or that was allocated to the Service is applied accordingly.

Menu

Unplanned Down Times

Unplanned downtime refers to unforeseeable events that have an effect on the availability of the IT service.
Unlike downtime for which the service provider is responsible, however, here it is a case of third-party responsibility or force majeure.
These instances of downtime are therefore not contractually relevant, and measurement data that has been collected during such downtime should not be taken into account in evaluations.

This can be shown in the Central Server solution using Unplanned Down Times.
Technically speaking, these work in exactly the same way as Planned Down Times.
The division between the two types is a purely organizational one, so that it is easy to distinguish
in evaluations between downtime approved in advance and instances subsequently filtered out.

Even in the case of Unplanned Down Times, it is true that an instance of downtime relates to the whole Service, namely in all Locations where it is used.
When Unplanned Down Time is set up, the time zone that the Service uses or that was allocated to the Service is applied accordingly.

As unplanned downtime cannot be foreseen, no repeat process can be set up for such an event either.

Menu

Data Sources

The term Data Sources covers all elements of a Workflow that are responsible for collecting measurement data, i.e. timers, checkpoints, pings, etc.
Data Sources are registered in the System by the ServiceTrace Workflow Studio whilst a Workflow revision is being uploaded.
A Service can contain any number of Data Sources already registered in the system.
This means that users are able to incorporate all Data Sources that are relevant for the IT service being depicted.

In order to be better able to identify Data Sources, these are embedded in the Master Data hierarchy.
At the top level, the Master Data distinguishes the different Customers set up in Central Server.
Each Customer can have any number of systems that are monitored by Central Server.
Depending on the system, this can be used by one or more Applications.
The Data Sources are associated with these Applications.

The Data Sources specified by the respective Service are shown in a list.
For each Data Source, the following information is shown separated by commas.

• System / Application
• Name
• Type (timer, checkpoint, etc.)
• Measurement unit

Each Data Source can be integrated into any number of different Services.
That means that a Data Source that is already integrated into one Service can continue to be integrated into other Services.

Menu

Service Log

The Service log is for reliably documenting changes to the relevant Service.
Users can create manual entries here, but the Service log also contains entries that have been generated automatically.
These automatic entries always relate to the corresponding Service or its use.
An entry is generated, for example, if a new Workflow revision is deployed, which supplies measurement data for Data Sources that are used in the Service.

For each log entry, users can decide whether this should be used in the Reporting system
or, to put it more precisely, whether the respective log entry should appear in a report.

Manually created entries can be changed here by any user with the appropriate privilege.
Entries generated automatically by the system, however, cannot be changed
except for the setting for whether the log entry should appear in a report or not.

The log entries included in the respective Service contain the following information separated by commas:

• Time to which the entry relates
• Time stamp of the creation or last change
• Author of the last change
• Location
• Description
• Flag showing whether the respective entry was created manually or automatically
• Flag showing whether the respective entry should appear in the report

In order to determine whether a log entry is displayed in a report,
a time is filed relating to each entry.
A report in turn defines a period from which the displayed measurement results come.
If a log entry falls within the selected report period, and if its "Show in Report" option is enabled,
then it is listed in the "Service Log" section of the report.

The Author of a log entry is always the user who is logged in.
That applies both when creating an entry and modifying it.
The author cannot be changed manually.

The Location of a log entry specifies the Location to which the respective entry relates.
This has a special feature here: the wildcard "*" can also be specified for the Location.
That means the respective log entry relates to all the Locations for the relevant Service.

All log entries take the form of text only. That means they are not linked to the Locations or to the author.
As a result, they still exist if the Location used or the author are deleted from Central Server.
This is noticeable, for example, when selecting the Locations to which the log entry relates.
When a new log entry is created, the Location must be selected from a list of available Locations.
When modifying an existing entry, the Location can only be edited textually.
If the corresponding Location is later removed, then the respective log entry continues to save its name.
In this way, the history remains consistent.

Menu

Excluded Measurements

As all components involved are taken into account with end-to-end measurements, in rare cases it may occur
that measurement data coming from a particular measurement computer or a certain Location reports
errors in the measured Application, the cause of which does not lie with the provision of the IT Service being monitored.

For example, it may happen that the measurement computer no longer has enough free memory,
and therefore the Application cannot successfully perform all transactions at the measurement's runtime.
Another case may be that the connection for an entire Location was interrupted,
but this does not fall within the Service provider's remit.

In both cases it is desirable to remove the measurement data affected by the fault from the contractually relevant reports.
This can be shown in the Central Server solution using Excluded Measurements.

Besides the usual parameters for events such as name, start and end date, description, etc.,
Excluded Measurements also include the details for Location and Station.
The wildcard "*" can also be used here as a Station. It can thus be specified whether the measurement data from
an individual Station, or the entire Location, are to be taken out of the Reporting process.

As described in the Service Times section, Excluded Measurements make use of the Location's time zone to which they
relate when defining the time range.
In order to make this clear for users, the time zone is therefore shown when setting up an Excluded Measurement,
as soon as the Location has been selected to which it is intended to apply.

Menu

Time Zones

As discussed in previous sections, multiple time zones may be involved when it comes to defining and processing a Service.
If this is the case with the measurements you are responsible for, please bear in mind the information about the time zone used.
Especially when defining time ranges, this is extremely important for selecting the correct period.

As far as possible, the Central Server System specifies the time zone used when time ranges are defined.
This is possible in the vast majority of cases, namely precisely when the defined time range correlates exactly to one time zone.

In order to simplify the specification of time zones and not always have to take time differences into account,
the time zones are meaningfully linked to various elements of the Central Server system.

Service:	Each Service specifies its own time zone. This relates to the Location of the Service provider or to the site of the data center from which the monitored IT Service is provided. The time zone of a Service is used for Planned and Unplanned Down Times because these relate to the whole Service.
Location:	The Master Data Location parameter also specifies a time zone. This relates to the Location of the Central Server Robot that collects the measurement data on-site. A Location's time zone is used for Service Times and Excluded Measurements. Of course the measured values themselves also use the time zone of the Location from which they come.
User:	A time zone is also stored for the user. This can be selected in the relevant profile settings. All measurement results collected are shown according to the time zone specified here. This prevents unnecessarily complicated conversions. Unless specified otherwise, all times on the user interface for the Central Server solution are in the time zone pertaining to the relevant user. Within the Service, the user's time zone is used when creating Service Log entries.