Technical information regarding migration to GCP

We sometimes refer to the term "signature" or "customer signature". In our old environment, a full customer signature is in the format <tld>_<id>, where <tld> is a top-level domain that corresponds to the organization's country affiliation and the id is a self-chosen name for the organization. An example is se_chalmers, where se is the <tld> and chalmers is the <id>. The URL to e.g. the client would then be https: //<tld><id>.
In order to distinguish the old environment from the new one in our systems and in the URLs, all installations will get new customer signatures. These have the same format as before, but <tld> becomes cloud for all customers, regardless of country (e.g. cloud_chalmers).
Installations and databases
In the old environment, we had support for an installation to have multiple databases. We have chosen to remove this feature and instead set up multiple installations for those customers who have such a need. Among the production installations there is no one with multiple databases, but the reference to the database has still existed in some URLs, which will now disappear.
Forwarding of HTTP
In connection with the move, we will change the URLs of our web services. We will use another subdomain (cloud instead of country-based as before), and we will also change the location of the application name in the URL's path.
The old URLs will be automatically forwarded to the new URLs. However, problems may occur in non-GET HTTP calls, which almost exclusively mean means POST calls in our systems. To handle these, we will forward such calls with HTTP status 307 (
With the move, our servers will be behind a load balancer at Google, which is our new supplier. If you currently have firewalls that only allow connections to certain specified IP addresses, then these need updating.
Our web-based services go through port 443 (TLS) while our old Java client communicates on a customer-specific port. What address and port that applies to your organization can be found after the migration by visiting<id>/client/connect.txt in a browser, where <id> should be replace with your installation id.
The Java client connects to the IP address and the web services to However, note that this could change in the future.
As mentioned, in order to control traffic to the new environment, we use new URLs for all services. The old URLs will send HTTP questions to the new environment, where the URL will be in the format <id>.
Depending on how an integration is developed, it might continue to work as usual if it can handle the forwarded traffic. It is also possible that, for example, restarting the service to load a new WSDL file is enough, but other integrations will need to manually change the URLs used.
Single Sign-On
The move may affect some types of SSO logins. For LDAP solutions, it may be due to firewall settings (see section above). For SAML2-based logins, forwarding should work for most services, but if you're still having trouble, please contact our support and we'll update the SSO configuration.
Was this article helpful?
0 out of 0 found this helpful



Article is closed for comments.