Azure Installation¶

Prerequisite Steps¶

When communicating with Azure The IFS PSO Installer and PSO services need to be authenticated. Your deployment to Azure is secured using Azure Active Directory (AAD) as a broker for calls to Azure. There are two options available for authentication:

• Using a Service Principal - The installer and PSO services both use the Service Principal for authentication.
• Using an interactive login - The installer uses a logged-in user for installation. The PSO services use an Azure Managed Identity for authentication.

Setting up authentication using a Service Principal¶

If not using an interactive login, before you can use the IFS PSO Installer for Azure deployments you need to set up a Service Principal account in your AAD. PSO will use this Service Principal account (essentially an AAD account that applications can use) to make calls to Azure. See https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-create-service-principal-portal?view=azure-cli-latest for more details.

To create the Service Principal:

• In the Azure Portal, navigate to Azure Active Directory -> App Registrations -> New application registration
• Give the Service Principal a name (between 4 and 256 characters in length)
• Sign-on/reply url can be set to a placeholder url (e.g. https://example.org)
• Click 'Create'

The next step is to create a key. This can be done as follows:

• Click on the Service Principal you have just created
• Navigate to Manage -> Certificates & secrets
• Click 'New client secret'
• Enter a description and a duration
• Click 'Save', and you will be shown the application key. Copy the key at this point, as you will not have access to it again

You will need to give the Service Principal access to the subscription using RBAC configuration. This is done through the Azure Portal:

• Navigate to the chosen subscription and click on 'Access Control (IAM)'
• Click on 'Add role assignment'
• For the Role, Owner is required
• Under 'Select', search for the name of the Service Principal
• Click 'Save'

With the Service Principal set up, you need to provide four pieces of information that you must then provide to IFS so that a licence key can be generated, which you can then use with the Installer:

• Subscription ID
• Azure Active Directory Tenant ID: This can be found on the Azure Portal under Azure Active Directory > Properties > Directory ID
• Service Principal Application ID: This can be found on the Azure Portal by selecting the relevant Service Principal under Azure Active Directory > App Registrations, then using the value shown for Application (client) ID
• Service Principal Application Key: This can be generated in the Azure Portal. Note that this is only shown once, when it is first created.

The above details are encrypted into your licence key and used by both the IFS PSO Installer and the PSO services to authenticate calls to the Azure API with Oath 2 level compliance.

Using an interactive login¶

When using an interactive login a Service Principal does not need to be setup. You just need to provide your Subscription ID and the Tenant ID of your Azure Active Directory (sometimes referred to as Directory ID on the Azure Portal) to IFS so that a licence key can be generated, which you can then use with the Installer. The Subscription ID and Tenant ID are encrypted into your licence key.

The IFS PSO Installer will show an interactive login dialog for Azure and the installation will be done as the user you login with. As part of the installation the installer will automatically setup a managed identity in Azure. This managed identity will be used by the PSO services when they authenticate with Azure and is locked down to have role-based access control of only the deployment's resource group.

Setting up a Key Vault for HTTPS¶

If HTTPS is required for an installation, a Key Vault must be setup and configured prior to the install and an SSL certificate in pfx format needs to be uploaded as a Secret.

The required steps for setting up the Key Vault are as follows:

• In the Azure Portal, go to 'Key Vaults' and then select 'Add'
• Enter the name, resource group and location for the Key Vault
• Click on 'Access policies' and then on 'Click to show advanced access policies'

• Check 'Enable access to Azure Virtual Machines for deployment' and 'Enable access to Azure Resource Manager for template deployment'

  

  Note

  If using PowerShell to create a Key Vault, this step is equivalent to setting the 'EnabledForDeployment' flag to true.

• Still in the 'Access policies' window, click on 'Add new'

• If you previously setup a Service Principal click 'Select principal' and search for your Service Principal
• Under 'Secret permissions', ensure that at least 'Get', 'List', 'Set' and 'Delete' are selected
• Accept the changes you have made and click 'Create' to create the Key Vault

As the certificate management resides under the end-user's, or service provider's, responsibilities, they must create and manage the Key Vault. This is a straightforward procedure and extensive documentation can be found on the Azure website to aid with this step.

Once a Key Vault has been created the next step is to upload the SSL certificate as a Secret. A PowerShell script is provided in the Setup Files folder within a release distribution to aid with this ("Upload certificate to key vault.ps1").

To upload a certificate, run the upload script within PowerShell. The script takes the following parameters: subscription_id (your subscription id), vaultName (the name given to the key vault created above), secretName (a name for the secret), filename (the complete filepath to the certificate), certPassword (the certificate password) and AzureUSGovernment (whether the Key Vault resides in the AzureUSGovernment cloud). If not provided, the script will prompt for these values, with the exception of AzureUSGovernment which is an optional switch parameter, i.e. if present it is taken as true, if absent it means false.

Example¶

& '.\Upload certificate to key vault.ps1' -subscription_id "1234567890" -vaultName "examplevault" -secretName "examplesecret" -fileName "C:\xxxxx\xxxxxxxx\xxxxx.pfx" -certPassword "abcdef"

Once the certificate is uploaded you can retrieve the Key Vault Resource ID (visible in the Settings -> Properties section of the Key Vault on the Azure Portal) and the Secret Url (visible in Settings -> Secrets -> Select the secret you created in the upload step -> drill-down to the desired certificate version, e.g. the latest version, and you will see the Secret Identifier url). These are needed for setting up HTTPS when running the installer. The certificate thumbprint is also required when running the installer. You can retrieve this from your certificate with the PowerShell command "Get-PfxCertificate -FilePath "Certificate.pfx", where "Certificate.pfx" represents the filepath to your certificate.

Required Resource Providers for a Subscription¶

To enable Azure functionality to be used by an Azure subscription you must configure Resource Providers. This can be easily done using the Azure Portal by navigating to the Subscription that you are interested in and then selecting the Resource Providers blade. The Resource Providers required for PSO in Azure are as follows:

• Microsoft.Authentication
• Microsoft.Compute
• microsoft.insights
• Microsoft.KeyVault
• Microsoft.ManagedIdentity
• Microsoft.Network
• Microsoft.OperationalInsights
• Microsoft.Portal
• Microsoft.Resources
• Microsoft.Sql
• Microsoft.Storage

How do we deploy a scheduling system to Azure?¶

To deploy an IFS PSO system to the Microsoft Azure cloud follows very similar steps to a local installation. You use the IFS PSO Installer to define which software components you wish to install and then define the corresponding database connections, then the installer will perform the installations and any required configuration. When we deploy a scheduling system to Azure we have the additional factor that the software is to be installed on a virtual machine that has not been created yet, rather than on the local machine that the IFS PSO Installer is running on. To facilitate this process, the IFS PSO Installer uses a storage container in the Azure cloud to hold the software, a template of how the virtual machine should be configured, and a configuration file defining details of your deployment (e.g. which software components to install, how many machines to create, etc). When we create a deployment on Azure, the "role instance(s)" (essentially, virtual machines with a pre-configured Windows OS) downloads the information and software files that we have placed in our storage container and installs the software to our specification. We can then interact with the Azure service via the Scheduling Gateway service (to send scheduling input to the system and retrieve broadcast data) and via the Scheduling Workbench user-interface.

Deploying to Azure and PSO VM Roles¶

The IFS PSO Installer provides the ability to deploy an IFS PSO system to the Microsoft Azure cloud platform. When deploying PSO to Azure, the default configuration is to deploy instances of VM "roles" of type DSE and Interface; DSE machines primarily handle optimisation whereas Interface machines host the remaining services.

Default Role Configurations¶

The default application configuration for the DSE and Interface roles is as follows - please consult the Architecture and Sizing Guide for explanations of the service acronyms, e.g. DSE corresponds to Dynamic Scheduling Engine:

• DSE: ADM, DSE, SSM, SMM
• Interface: ABE, ADM, ARC, DSP, DST, GWY, PSW, RPL, SBM, SES, SIM, SMM, SQM, SRG, SSM, SWB, TRA

Auto-scaling¶

The PSO system can be configured to auto-scale the number of VMs and the database performance based on the current workload. This functionality can be switched on via the "AutoScale" parameter. But this requires Role Cache rules also to be set, which are best set up through the installer. Once enabled, the Scheduling Machine Manager (SMM) will monitor the workload on the system and provision/remove VMs as required. Additionally, the SQL Azure database will be monitored to ensure the performance tier is suitable for the current load (measured in DTUs) and used disk space.

Resilience to instance drop-outs with non-auto-scaling deployments¶

When deploying PSO to Azure the standard configuration separates the IFS PSO services across different machines. At the time of writing, Microsoft guarantee a 99.95% uptime SLA for instances in a deployment, hence at face-value one may assume that at least two instances of each role will be required to ensure 100% effective uptime. However, for non-auto-scaling deployments, the IFS PSO software performs background checks to ensure that all required services in a deployment are up and running across the available instances, meaning that a minimum of one instance of a role can be deployed (not two) and the services will compensate for any drop-outs as instances are recycled by Azure. In short, the IFS PSO software will stop/start the component services across the instances in your deployment to ensure the required deployment configuration, thus compensating for any downtime of a VM instance.

As an example, consider a non-auto-scaling deployment with two roles: DSE and Interface. The DSE role is responsible for scheduling, whereas the Interface role handles all other required services (Scheduling Input Manager, Scheduling Query Manager, etc). At some unknown time, Azure may take down the Interface instance to recycle the VM and/or install updates. At this point service resilience checks performed by the DSE role will notice that, for example, a Scheduling Input Manager (and any other required services) are missing and start up those services on the DSE role. When the Interface role is restarted and its services become active again, the DSE role will switch off any services that it has been running to cover the Interface role and the deployment.

Creating an Azure VM image to use with the IFS PSO Installer¶

The IFS PSO Installer can be used to create a VM image from which you can create deployments. The advantage of creating a re-usable image is that the majority of the time consuming configuration steps are performed just once when the image is created. Then, when the image is used to create a deployment, the VM will boot up considerably quicker. Note that this also applies to recovery from VM recycling by Microsoft. Therefore, using a pre-built image means less downtime and faster start-up.

Creating an image¶

An image is deployed in its own Resource Group along with a Storage Account that contains the required software and scripts to bootstrap the image. As such, when creating an image we will also need to create a Resource Group and Storage Account. Note that this is a separate Resource Group to any deployment(s) based on the fact that VM images have a different lifecycle to a PSO cloud deployment and also to ensure encapsulation. A detailed description of the pages in the IFS PSO Installer is given in the following section, therefore, this section will focus on the pages that relate to creating and deleting images.

To create a VM image:

• Select the "Create Image" option on the "Service Selection" page.
• On the "Resource Group" page, enter a valid name for the Resource Group and select the target location.
• On the "Storage Account" page, provide the name for the storage account.
• Set the image creation going by confirming on the "Actions" page.

Creating an image takes roughly 30 mins. Once complete, you will find a Resource Group in the targeted subscription containing an Azure Managed Image that can be used for PSO deployments - details of how to deploy using an existing image are given in the following section.

Deleting an image¶

When deleting a VM image you can either delete just the image (using the "Delete Image" option on the "Service Selection" page) or delete the entire Resource Group used in the image creation process (i.e. including the Storage Account). Both options are valid but the preferred approach is to delete the Resource Group as this cleans up all resources associated with the image that you wish to delete.

Deploying an Azure service using the IFS PSO Installer¶

Start Page¶

The process of deploying an IFS PSO system as an Azure service is very similar to that for a local installation as described in the "Standard Software Installation" section. From the start page of the IFS PSO Installer, select your licence file and then select "Azure" from the Install Mode option. Click "Next" to continue.

Licence Details¶

Provided you have a valid licence, you will be taken to the "Licence Details" page where you may review the software products covered by the selected licence. Clicking next to proceed with the installation.

Subscriptions¶

As discussed earlier in this section, you will require an Azure subscription to be able to deploy an IFS PSO system to Azure using the IFS PSO Installer and details of your Azure subscription will be encoded into your licence key. On the Subscription page you may select from the subscriptions that your licence is aware of. After selecting the desired subscription, click "Next" to proceed. If your licence key does not have the Service Principal details embedded you will be asked to login to Azure so the installation can progress as your user. At this point the installer will fetch information about your subscription from Azure: existing IFS PSO deployments, storage containers (primarily used to store software and configuration files during the install process), and Sql Azure databases.

Select Service Action¶

An IFS PSO System deployed to Azure is referred to as a Service. As such, to create a new IFS PSO system in the Azure cloud we select "Create New Service" and click "Next" to continue.

You will then need to step through several screens to populate details about how the new deployment should be created.

Storage Account¶

A storage account on Azure is used as a holding place for data relating to the service you wish to create. As such, the first step is to select the storage account that you will use. If you have no storage accounts, or you wish to create a new storage account for this deployment (which we recommend) then select "Create New Storage Account" and enter a valid storage account name. If you have an existing storage account that was previously created using the IFS PSO Installer that you wish to use you may also select it here using the "Select Existing Storage Account" option.

Resource Group¶

The resource group will form part of the URL that can be used to access the service when it has been deployed to the cloud.

The datacentre is the location of your Azure deployment.

Service Details¶

On the Service Details page you enter the machine size to use for your Azure deployment. The drop-down will show a list of all available standard D series machines, starting with the most recent family of machines. The details of the machine size option (number of cores and RAM) are shown - further details of the VM specification can be found on the Microsoft Azure web pages. If the list of available VM specs does not contain a specific machine size that you require, please contact IFS.

The policy for applying Windows VM upgrades can also be selected here:

• Automatic - VM Scale Set managed - OS Upgrades are automatically managed at the VM Scale Set level. This is the default option. A maintenance control configuration can be selected in the Azure portal after each installation to allow specifying a maintenance window.
• Automatic - VM Windows Update (Legacy) - OS Upgrades are automatically managed by Windows Update inside each VM. This option will be automatically selected when upgrading an existing system that never had a policy configured.
• Manual - OS Upgrades are manually managed at the VM Scale Set level.

Deployment selection¶

The deployment options are selected on the "Deployment" page:

• Configure VM: provision a Windows Azure and configure post-bootup.

• Use PSO Base Image: provision a pre-configured PSO Windows Azure VM. This is the recommended deployment option. Note that this option is only available if the user/service principal resides in the IFS Azure Active Directory, is a member of the PSO Azure AAD Group and the deployment is targeting one of the following regions:

  • East US
  • East US 2
  • Central US
  • West US
  • North Central US
  • South Central US
  • Canada Central
  • North Europe
  • West Europe
  • UK South
  • Japan East
  • Australia Southeast
  • South Africa North
  • UAE North
  • Central India
  • Australia East
  • Southeast Asia
  • Norway East
  • Switzerland North

• Use Existing Image: select a pre-built PSO image. Some minor configuration is required post-boot but VM startup times are considerably quicker than with the Configure VM option. Please see the earlier section "Creating an Azure image for use with the IFS PSO Installer" for more details.

Application selection¶

The next step is selecting the instance counts for the different roles in the deployment. The role configuration is pre-defined in the "Role Configuration" xml file in the Setup folder, containing a default list of roles and instance counts. Cache rules can be defined to dictate the minimum and maximum instances of roles and of systems (i.e. databases), effectively providing bounds for the automatic scaling in the deployment. The default cache rules are also specified in the Role Configuration file.

Database Servers¶

Database setup for an Azure deployment differs from when we perform a local installation. For a local installation we may have an on-premises database server which may be either a Sql Server or Oracle database. For an Azure deployment we instead adopt the Sql Azure database platform - this is the natural choice when deploying to the Azure cloud. As such, we are required to have a Sql Azure database server that can host the IFS PSO databases that are required by our deployment.

For a fresh install you will need to select "Create New Database Server" and provide a name for the database server. You may also opt for a custom database server password for the admin users.

Whereas if you have previously deployed a service using the IFS PSO Installer and you already have a compatible* Sql Azure database server, this can be chosen from the list of available servers, after selecting "Select Existing Database Server". In the case where the chosen database server uses a custom admin password, the same has to be provided.

*We define "compatible" to mean a Sql Azure database server that was created by the IFS PSO Installer.

Databases¶

Database configuration is split across two pages: System Database and Application Databases - screenshots shown above. The first concerns the database configuration for the System Database that underpins the installation. The second screen is for the Application Databases connection details, e.g. Scheduling, Resource Planning, etc. Both pages allow you to define the Azure Databases that will reside on the Azure Database Server selected on the previous page. You may add and remove databases and then in the "Databases" section you can assign a database for a specific PSO schema. Note that based on the PSO services that have been selected on the Modules page there will be required and optional PSO database schema. If a schema is required then it will be ticked and cannot be unticked, and therefore must have a database assigned to it. If the schema is optional then you may tick/untick as desired.

By default, all schemata except for the Archive schema will install to a database called "IFS Scheduling" on the database server. The archive schema will install into its own "IFS Archive" schema. The name of the database may be edited via the text box in the database list. Using a single database for all schemata is a cost advantage because the Microsoft Azure platform charges per database. However, you may use multiple databases if you see fit, i.e. one for Scheduling Database and one for Scheduling System Database, though this will incur extra cost.

Depending on the software components that you have selected, there will be required and optional databases. With the exception of the Hierarchical Travel Matrix, the database connection details for required and optional databases are handled by the IFS PSO Installer, you merely need to select which optional databases you require.

Hierarchical Travel Matrix Configuration¶

If you require, or optionally select, a Hierarchical Travel Matrix database, you must provide the connection string details. For an Azure deployment, the Hierarchical Travel Matrix database must reside in a Sql Azure database. You may select a HTM database either via entering the connection string, or, if you have installed a HTM using the IFS PSO Installer, you can choose to select a database from an existing database server within the currently selected subscription - see the screenshot below. For further details on how to create a Hierarchical Travel Matrix database in Sql Azure please consult the "Installing the Hierarchical Travel Matrix" section within this guide.

To configure a Hierarchical Travel Matrix (HTM), simply use the "Add HTM" button to add a HTM connection record and then fill in the details for that connection. Note that multiple HTM connections can be added, giving the scheduling system the possibility of using a different HTM for different datasets.

Import/Export¶

The Import/Export screen provides the option to import or export Resource Planning, Scheduling, Simulation and System data. This includes System Parameters, Workbench snapshots (PSO Workbench files) and WISE Data. See the Standard Software Installation - Import/Export section for details of this screen.

Admin Settings¶

The Admin Settings screen allows you to set administrator credentials.

Security¶

The security page in the IFS PSO Installer allows the RDP and HTTP/HTTPS settings to be configured. To switch RDP on/off simply use the checkbox under the Remote Desktop Connection header. You will then be required to provide login details for the RDP connection.

To access your deployment you can use the public domain url and ports 50001-50100, where port numbers map to instances in the deployment. For example, port 50001 maps to the first VM instance in the deployment. The public url for your deployment can be retrieved from the Azure Portal by examining the Public IP component, residing in a Resource Group with name matching your chosen service name.

For web applications you may configure either HTTP or HTTPS, or both. Configuring HTTPS also requires you to provide the details for an SSL certificate to authenticate the connection. The supported process for certificate management is to use an Azure Key Vault to store the certificate as a "Secret" that can then be injected into the VM when it is created. The details for how to set up the Azure Key Vault for HTTPS can be found in the 'Prerequisite Steps' section.

With the pre-requisites in place you can set up HTTPS by ticking the HTTPS option and providing the following details:

• Key Vault Resource ID: the endpoint url for the Key Vault (visible in the Settings -> Properties section of the Key Vault on the Azure Portal).
• Certificate Secret Url: the url for the secret on the Key Vault, including the target version. (Visible in Settings -> Secrets -> Select the secret you created in the upload step -> drill-down to the desired certificate version, e.g. the latest version, and you will see the Secret Identifier url)
• Certificate Thumbprint: the thumbprint of the SSL certificate. Note: This can easily be retrieved using the PowerShell command Get-PfxCertificate, with the only argument required being 'FilePath', the path to the certificate.
• Harden SSL: if checked, TLS 1.0 and TLS 1.1 are disabled and a reduced set of cipher suites are available. Older browsers may not be able to connect to a hardened SSL site.

Database Firewall¶

The Database Firewall page allows you to configure the permitted IP address ranges for connections to the Sql Azure database. It is straightforward to add and delete firewall rules. Note that any changes you make on the Database Firewall page will not be applied until actions are performed at the end of the installation process.

Network Security Group¶

The Network Security Group page allows you to set up a firewall for the deployment's virtual network, which restricts the permitted IP address ranges that can connect to any web-facing modules (such as the workbench). Individual IP addresses can be entered, or ranges can be provided using CIDR notation. Custom ports can be set if required, if not the default port values from the security group will be used - this includes the ports required to allow the services to run, e.g. port 80 for the PSW and/or port 8744 for the GWY. For further details of the default ports, please see the "Default Ports" section towards the beginning of this document.

Monitoring¶

Setting up Azure Monitoring allows you to monitor both the general health of the system - using metrics such as DTU usage.

A dashboard provides a screen in the Azure Portal containing graphs for various metrics and shortcuts to useful features for the deployment. The name provided acts as an id and as a display name when viewing and selecting dashboards in the Azure Portal, but the display name can be changed through the Azure Portal if desired.

For full details around how to use the dashboard, what alert rules are set up, and how to configure a deployment when not using an agent, please see the 'Azure Monitoring' section within this guide.

Actions summary¶

The Actions page summarizes the various steps to be performed when creating the deployment. Click "Start" to run the IFS PSO Installer against the actions. Once it has finished your new Azure deployment will be being created and you will need to allow some time before it comes online and can be used, typically in the order of 10-15 mins.

Updating an Azure deployment¶

Updating an Azure deployment involves uploading the newer software, plus any configuration changes, to Azure storage and then re-deploying the service. This in turn involves taking down the existing service running the old version of the software and deploying a new version, and also performing any required updates to the IFS PSO databases on the Sql Azure database server being used by the service.

To update an existing Azure deployment to a newer version of the IFS PSO software select "Update Existing Service" on the Select Service Action page, then select the desired service from the list and click "Next" to continue.

You will then be required to select the storage account that you wish to use for this deployment. You may either select an existing one (for example, the storage account that was used for the previous deployment of this service) or create a new one.

The Service Details page then shows the existing information for the cloud service. When updating a service you may also choose to change the machine size, for example, if you wanted to increase the number of cores and/or RAM when the service is redeployed. The VM upgrades policy can also be reconfigured.

Moving along, you may then set the number of role instances that you wish to include in your deployment in the Applications screen. In the Database Servers screen you can then select whether you want to create a new database server or use an existing database server.

Following that, the Databases pages allow the connection details to be edited. Again, you may add/remove optional database connections as desired.

The Import/Export page allows you to automatically export the data that is currently in the System, Scheduling and Resource Planning databases. The data is saved to xml files for safety, in case a later action fails. Further information can be found in the Standard Software Installation - Import/Export section.

Again, the actions page summarizes the necessary steps to upgrade the Azure deployment - the IFS PSO Installer will determine the required database scripts to run. Clicking "Next" begins the process. As with creating an Azure deployment, there will be a short delay between the IFS PSO Installer completing the necessary actions and the upgraded Azure deployment becoming available for usage.

Deleting an Azure service¶

To delete an Azure service you simply select "Remove Resource Group" on the Select Service Action page, then select the service(s) that you wish to delete. On clicking "Next" you will be taken to the Actions page where you may review your decision and click "Start" when you are happy to proceed and delete the service.

Deleting a Sql Azure database server¶

The IFS PSO Installer may also be used to delete existing Sql Azure database servers. To delete a database server, on the "Select Service Action" page, select "Remove Database Server" and then select the database server(s) that you wish to delete. On clicking "Next" you will be taken to the "Actions" page where clicking "Start" will delete the server.

Deleting a Sql Azure database¶

Sql Azure databases can also be deleted using the Installer. To delete a database, on the "Select Service Action" page, select "Remove Database" and then select the database(s) that you wish to delete. On clicking "Next" you will be taken to the "Actions" page where clicking "Start" will delete the database.

Deleting an Azure storage account¶

To delete an Azure storage account, select "Remove storage account" on the Service Selection page, then select the storage account you wish to delete and proceed to the actions page.

Testing an Azure Deployment¶

After the installer has completed the Azure installation, it is important to perform a number of initial "smoke tests" to establish whether the deployment was successful and that the scheduling system is working as intended.

Accessing the Scheduling Workbench¶

Navigate to the Scheduling Workbench and login to the administrative user account. This will confirm that login is possible, that UI client-server communications are functioning correctly, and that the server-side of the UI is correctly connected to the database.

Workbench URL

HTTPS://[service-name].[data-centre].cloudapp.azure.com/IFSPSOWorkbench/

Verifying the Scheduling System¶

Once logged on to the Scheduling Workbench locate the Administration Workspace, click on the System Diagram tab to show your complete Azure system. This is important as it shows all the services and databases that are related to this deployment. At this point it is worthwhile checking that all of these components are as expected based on the configuration during installation. Note that the "Role Configuration" XML file (bundled in the Setup folder with the release) defines what services should be installed during the installation process.

While still in the Administration Workspace click on the System tab and locate Events. This provides a real time event log from each of the services, showing error, fatal, information and warnings events. From here any errors will be reported, for example if a service is unable to connect to a database.

After establishing that the Azure system contains all of the required services and that there are no critical errors, the next process is to send in scheduling input data.

Sending input data to an Azure Deployment¶

Data is sent through the RESTful Gateway to an Azure Deployment. The RESTful gateway allows an API client to interact with PSO, and it can be used to send or retrieve data.

Before sending scheduling input data through the RESTful Gateway a session token is required to authorize the client. This can be retrieved via sending a POST request to the session endpoint. Parameters for the accountId, userName and password will be required. If the POST was successful a session token is returned.

HTTPS://[service-name].[data-centre].cloudapp.azure.com/IFSSchedulingRESTfulGateway/api/v1/scheduling/session?
    accountId=Default&
    userName=administrator&
    password=password

Bearer authentication uses the session token to authenticate the client. Scheduling input data can now be sent through the RESTful gateway. This can be done via sending a POST request to the data endpoint. A parameter for the dataType will be required. For scheduling input data the dataType is SCHEDULE. The scheduling input XML data will be sent in the body of the request.

HTTPS://[service-name].[data-centre].cloudapp.azure.com/IFSSchedulingRESTfulGateway/api/v1/scheduling/data?
    dataType=SCHEDULE