Overview

Zervicepoint consists of a number of components which work together, they can all be deployed to the same server or be distributed on multiple servers.

  • Single-Server - All components installed on the same server (on-premises deployment)
  • Multi-Server - Components deployed on seperate nodes (Frontend/Backend) (on premises deployment)
  • Multi-Tenant - Hosting scenario (Central components hosted by hosting provider, store/worker setup for each tenant)

Components

These are the main components that make up a Zervicepoint installation. All are seperate components that are deployed through a bundled installer. This means that you can to install individual components on multiple nodes to support high-availability scenarios.

Note

ProcessSystem does not support high-availability scenario, and should instead be setup as a clustered service through Windows Failover Clustering.

Component Description Area
UserWeb The user web for Zervicepoint, end users go to this site. Frontend/Central
AdminWeb The admin web for Zervicepoint. Used to create services, pages, email-templates, order history and more. Frontend/Central
ApiWeb REST API endpoint for Zervicepoint. Almost everything (and more) that can be performed in AdminWeb can be done through our Management API Frontend/Central
ClientWebService A Web Service, used to fetch data in system X and present in forms in services. Frontend/Worker
ProcessSystemWeb ProvisioniongSystem connect to this endpoint for next job to execute. ProvisioningSystem and ProvisioningSystemInventory Inventory local plugins through this service. Frontend/Central
Database Zervicepoint database (MSSQL) Backend/Central
ProcessSystemService Picks orders from database and schedules them in workflow manager Backend/Central
ProvisoningSystem Executes powershell code in the workflow and sets inventory information process system web Backend/Worker
ApiPSModule PowerShell module for Zervicepoint Management API Any server from where you want to run ZP PS Cmdlets
Microsoft Service Bus Queue manager for messages Backend/Central
Microsoft Workflow Manager Runs workflows Backend/Central
WorkflowManagerExtensions Contains Zervicepoint WorkflowManager files. Backend/Central
  • Central refers to to component which are installed in the hosting provider environment
  • Worker refers to the server which will execute local ClientWebService requests and ProvisioninSystem activites. Installed on-premsies in a multi-tenant scenario

Zervicepoint topologies

On premise - Single Server setup

This is a simple setup for smaller deployments or "proof of concept" deployments.

The following components are installed on the same server.

  • UserWeb
  • AdminWeb
  • ApiWeb
  • ClientWebService
  • ProcessSystemWeb
  • Database
  • ProcessSystemService
  • ProvisoningSystem
  • ApiPSModule
  • Microsoft Service Bus
  • Microsoft Workflow Manager
  • WorkflowManagerExtensions

Note

For "proof of concept" deployments, the Microsoft SQL Server can be installed locally.

Layout

Example

Before you install

You should have prepared the following before setup

Task Comment Example
Choose hostname This is the sitename (https://hostname/) selfservice.example.com
Request certificate In order to allow HTTPS traffic, a certificate must be issued from either a 3rd party CA or internal CA and imported to the server "CN=selfservice.example.com"
Create Service Accounts Service accounts are required for the application pool running the Zervicepoint websites and Zervicepoint services.
Choose Authentication Choose either ADFS or Azure AD as authentication for website access
Create DNS record Add a A/CNAME record for "selfservice.example.com" in either your internal/external DNS depending on if you want to publish Zervicepoint for external users or not. selfservice.example.com 10.0.0.1
MS SQL Instance MS SQL Instance for hosting Zervicepoint database sqlserver01.example.com/MSSQLSERVER
Database Permissions The account running the deployment of Zervicepoint need access to create databases in the target instance unless the database is pre-created. Service accounts need access to the created database post-deployment.
Enable required Windows Features Zervicepoint and ServiceBus/Workflow Manager requires several Windows Features to be enabled on the Server.
Setup Service Bus / Workflow Manager Setup Microsoft ServiceBus / Workflow Manager

Endpoints

URL Port Comment
https://selfservice.example.com 443 User Web
https://selfservice.example.com:8443/ProviderService.svc/CallProvider 8443 Client Web Service
https://selfservice.example.com:20000/Store 20000 Admin Web
https://selfservice.example.com:30000/Store 30000 WebApi
https://selfservice.example.com:9900/ProcessSystem/ProvisioningService.svc 9900 Process System Web

Depending on your environment, you may need to open traffic for 20000 (AdminWeb) and 8443 (ClientWebService)

On premise - Multi-Server setup

For on premise deployoment where high availability is important.

The following components should be installed on seperate servers:

Component Node Comment
UserWeb, AdminWeb, WebApi, ProcessSystemWeb WebServer1
UserWeb, AdminWeb, WebApi, ProcessSystemWeb WebServer2
ClientWebService, ProvisioningSystem, ProvisioningSystemInventory, ApiPSModule WorkerServer1
ClientWebService, ProvisioningSystem, ProvisioningSystemInventory, ApiPSModule WorkerServer2
ProcessSystemService, Microsoft Service Bus, Microsoft Workflow Manager BackendServer1
ProcessSystemService, Microsoft Service Bus, Microsoft Workflow Manager BackendServer2
ProcessSystemService, Microsoft Service Bus, Microsoft Workflow Manager BackendServer3
Database SqlServer1 High Availability Group/Failover Cluster
Database SqlServer2 High Availability Group/Failover Cluster

Note

ProcessSystemService can't be run on multiple nodes on the same time, so should instead be setup in a failover cluster.

Note

WebServer1+2 and WorkerServer1+2 can be collocated, but recommended to be seperated with there is a lot of ClientWebService requests.

Layout

Example

Before you install

You should have prepared the following before setup

Task Comment Example
Choose hostname This is the sitename (https://hostname/) selfservice.example.com
Choose hostname for ClientWebService Requests to ClientWebService for dynamic data in forms cws.example.com
Request certificate for hostname In order to allow HTTPS traffic, a certificate must be issued from either a 3rd party CA or internal CA and imported to the server "CN=selfservice.example.com"
Request certificate for ClientWebService In order to allow HTTPS traffic, a certificate must be issued from either a 3rd party CA or internal CA and imported to the server "CN=cws.example.com"
Create Service Accounts Service accounts are required for the application pool running the Zervicepoint websites and Zervicepoint services.
Choose Authentication Choose either ADFS or Azure AD as authentication for website access
Create DNS record Add a A/CNAME record for "selfservice.example.com" in either your internal/external DNS depending on if you want to publish Zervicepoint for external users or not. selfservice.example.com 10.0.0.1 , cws.example.com 10.0.0.2
MS SQL Instance MS SQL Instance for hosting Zervicepoint database sqlserver01.example.com/MSSQLSERVER
Database Permissions The account running the deployment of Zervicepoint need access to create databases in the target instance unless the database is pre-created. Service accounts need access to the created database post-deployment.
Enable required Windows Features Zervicepoint and ServiceBus/Workflow Manager requires several Windows Features to be enabled on the Server.
Setup Service Bus / Workflow Manager Setup Microsoft ServiceBus / Workflow Manager

Endpoints

URL Port Comment
https://selfservice.example.com 443 User Web
https://cws.example.com:443/ProviderService.svc/CallProvider 443 Client Web Service
https://selfservice.example.com:20000/Store 20000 Admin Web
https://selfservice.example.com:30000/Store 30000 WebApi
https://selfservice.example.com:9900/ProcessSystem/ProvisioningService.svc 9900 Process System Web

Note

A different hostname is needed for ClientWebService + Certificate and DNS record is needed if ClientWebService is not collocated with the other web components.

Multi-Tenant Setup

Zervicepoint supports multiple stores in one central installation. Each store has a unique URL and federation settings. Multi-tenant setup reduces the amount of time required to onboard a new customer to Zervicepoint and reduces the maintenance effort. Customers share the central parts of Zervicepoint. The information is logically seperated between the different stores.

Multi-Tenant

For a Multi-Tenant scenario, you would want a high-availability environment, but for "proof of concept"/test server you can still collocate components.

Component Node Comment Location
UserWeb, AdminWeb, WebApi, ProcessSystemWeb WebServer1 Central
UserWeb, AdminWeb, WebApi, ProcessSystemWeb WebServer2 Central
ClientWebService, ProvisioningSystem, ProvisioningSystemInventory, ApiPSModule CentralWorkerServer1 Central
ClientWebService, ProvisioningSystem, ProvisioningSystemInventory, ApiPSModule CentralWorkerServer2 Central
ProcessSystemService, Microsoft Service Bus, Microsoft Workflow Manager BackendServer1 Central
ProcessSystemService, Microsoft Service Bus, Microsoft Workflow Manager BackendServer2 Central
ProcessSystemService, Microsoft Service Bus, Microsoft Workflow Manager BackendServer3 Central
Database SqlServer1 High Availability Group/Failover Cluster Central
Database SqlServer2 High Availability Group/Failover Cluster Central
ClientWebService, ProvisioningSystem, ProvisioningSystemInventory, ApiPSModule Worker1 For each tenant/Store Customer environment

Note

In a multi-tenant scenario, it's optional to install ClientWebService and ProvisioningServer centrally. In order to run central data sources/activites they must be setup and data sources/activites are then delegated to tenants via the Zervicepoint Management API.

Before you install

You should have prepared the following before setup

Task Comment Example
Choose hostname This is the sitename (https://hostname/) selfservice.example.com
Choose hostname for ClientWebService Requests to ClientWebService for dynamic data in forms cws.example.com
Request certificate for hostname In order to allow HTTPS traffic, a certificate must be issued from either a 3rd party CA or internal CA and imported to the server "CN=selfservice.example.com"
Request certificate for ClientWebService In order to allow HTTPS traffic, a certificate must be issued from either a 3rd party CA or internal CA and imported to the server "CN=cws.example.com"
Create Service Accounts Service accounts are required for the application pool running the Zervicepoint websites and Zervicepoint services.
Choose Authentication Choose either ADFS or Azure AD as authentication for website access
Create DNS record Add a A/CNAME record for "selfservice.example.com" in either your internal/external DNS depending on if you want to publish Zervicepoint for external users or not. selfservice.example.com 10.0.0.1 , cws.example.com 10.0.0.2
MS SQL Instance MS SQL Instance for hosting Zervicepoint database sqlserver01.example.com/MSSQLSERVER
Database Permissions The account running the deployment of Zervicepoint need access to create databases in the target instance unless the database is pre-created. Service accounts need access to the created database post-deployment.
Enable required Windows Features Zervicepoint and ServiceBus/Workflow Manager requires several Windows Features to be enabled on the Server.
Setup Service Bus / Workflow Manager Setup Microsoft ServiceBus / Workflow Manager

Endpoints

URL Port Comment
https://portal.example.com 443 User Web
https://cws.example.com.com:443/ProviderService.svc/CallProvider 443 Central Client Web Service
https://portal.example.com:20000/Store 20000 Admin Web
https://portal.example.com:30000/Store 30000 WebApi
https://portal.example.com:9900/ProcessSystem/ProvisioningService.svc 9900 Process System Web
https://cws.customer1.com:443/ProviderService.svc/CallProvider 443 Client Web Service

Layout

Service Accounts

You can either use a single service account for all services, or split them.

  • Frontend Account (Account running the application pool for the IIS websites/ProvisioningSystemInventory)
  • Backend Account (Account running ProcessSystem/ProvisioningSystem)
  • ServiceBus/Workflow Manager Account (Account running Service Bus/Workflow Manager)
Component ServiceAccount Comment
UserWeb Frontend Runs the application pool for the IIS websites
AdminWeb Frontend Runs the application pool for the IIS websites
ApiWeb Frontend Runs the application pool for the IIS websites
ClientWebService Frontend/Worker Runs the application pool for the IIS websites, optionally use another one for ClientWebService
ProcessSystemWeb Frontend Runs the application pool for the IIS websites
Database Backend
ProcessSystemService Backend Run ProcessSystem Service
ProvisoningSystem Backend/Worker Runs Provisioning and ProvisioningInventory service
ProvisioningInventory Backend/Worker Runs Provisioning and ProvisioningInventory service
Microsoft Service Bus Backend/ServiceBus Use either same as for ProcessSystem or setup a unique one for ServiceBus/WorkflowManager
Microsoft Workflow Manager Backend/WorkflowManager Use either same as for ProcessSystem or setup a unique one for ServiceBus/WorkflowManager