Post-Installation Steps for ThingWorx Flow
This applies to all installation scenarios.
Before you begin using ThingWorx Flow, complete the following post-installation steps:
1. For Linux, give required permission to current admin user
While installing ThingWorx Flow, if you have not entered the administrator name that runs the ThingWorx Flow installer in the Enter the installation configuration username field, then add the <actual_admin_user> to the twxflow group that was created during the installation.
2. Configure the host (NGINX server) with a CA-signed certificate
By default, the installer generates a self-signed SSL certificate for the host. To change the certificate to a signed trusted third-party SSL certificate issued by a trusted Certification Authority (a CA-signed certificate), replace the content in orchestration.crt, extra.crt, orchestration.key, and nginx-keyfile files.
◦ If you have a dedicated private key and a certificate (crt) file with public key, follow the steps here.
For more information on making ThingWorx Flow work properly with connected applications using a self-signed certificate, see Make ThingWorx Flow work properly when self-signed certificate is used for connected applications.
3. Storing the ThingWorx Flow Secret Keys in the ThingWorx Foundation KeyStore
In case ThingWorx Foundation is installed manually without using installer, after installing ThingWorx Flow save the ThingWorx Flow secret keys in the ThingWorx Foundation KeyStore to establish secure communication between ThingWorx Flow and ThingWorx Foundation. Detailed steps for performing this task are available here.
4. Ensure SSO settings are done correctly
If you install ThingWorx Flow on a different machine or if the version is less than 9.1, you must complete the dedicated instructions only for the installation of ThingWorx Flow mentioned in Configure the sso-settings.json file.
5. Configure PingFederate
If you are using PingFederate, then add the OAuth redirect URI (https://<ThingWorx Flow Nginx host-name>:<ThingWorx Flow Nginx port-number>/Thingworx/oauth2_authorization_code_redirect) to the ThingWorx OAuth PingFederate client that acts as the service provider.
If ThingWorx Flow is using an OAuth connector, and you are using PingFederate then you must also provide the OAuth redirect URI to ThingWorx Flow OAuth PingFederate that act as a service provider. For example, if you are using Windchill as a resource server, provide the OAuth redirect URI as https://<ThingWorx Flow Nginx host-name>:<ThingWorx Flow Nginx port-number>/Thingworx/Oauths/oauth/return.
6. Scale ThingWorx Flow
To scale ThingWorx Flow, you need to modify the following settings, as per your operating system:
 |
Before you make any changes, review the software running on your system.
|
◦ Set the ephemeral ports for services on your operating system between 5000 and 65535.
For information about ephemeral ports and its range, see The Ephemeral Port Range.
◦ Reduce TIME_WAIT on sockets to 30 seconds.
For more information, see Windows: Time Wait setting or Linux: Time Wait setting.
7. To implement custom connectors, use the ThingWorx Flow SDK. For more information, see Deploying Connectors.
8. To make ThingWorx Flow work properly when self-signed certificate is used for connected applications, follow the steps below.
Starting from ThingWorx Flow 9.2.0, and later versions, for any application, either third party applications or other PTC applications that are connected to ThingWorx Flow and configured with a self-signed certificate, the self-signed certificate must be appended to extra.crt file. Follow the steps below to append extra.crt file.
These connected application could be connected to ThingWorx Flow as: ThingWorx Flow connectors (that is Windchill, Integrity, SAP), or as CAS/IDP (that is PingFederate, ADFS, Azure AD) that is used for OAuth communication, or as Load Balancer that is used for HA architecture.
|
|
If the connected application is configured with a single CA-signed certificate, then skip the steps described below. Users will be able to use ThingWorx Flow properly.
However, if the CA-signed certificate has certificate chains and one of its intermediate certificates is a self-signed certificate, follow the steps below for the intermediate self-signed certificate.
|
|
|
For Linux, self-signed certificates must be 2048 bit length.
|
To append the certificate, follow these steps:
a. Stop the ThingWorx Flow service.
For Linux, run the following command:
sudo systemctl stop ThingWorx-Flow.service
b. Navigate to <ThingWorx Flow Installation directory>\SSL and edit extra.crt file.
This file includes the content for all connected applications self-signed certificates.
c. Save the self-signed certificate content in PEM format.
|
|
You can use the Chrome browser to get the self-signed certificate in PEM format (Base 64 encoded), by exporting the self-signed certificate.
|
d. Copy the self-signed certificate content to extra.crt file.
e. Repeat steps b to d for every connected application’s self-signed certificate.
f. Append and save the content of the self-signed certificate to extra.crt file. Make sure to add a new line between each certificate.
g. Start the ThingWorx Flow service.
For Linux, run the following command:
sudo systemctl start ThingWorx-Flow.service
9. Reconfigure RabbitMQ port to listen to other port than default port
Reconfigure the RabbitMQ port for ThingWorx Flow, to listen to other port than default port 5672, if the following conditions meet:
a. ThingWorx Analytics was installed before ThingWorx Flow.
b. RabbitMQ service for ThingWorx Analytics uses the default port, 5672.
For Windows
a. Stop ThingWorx Foundation, and ThingWorx Flow services.
b. Under <flow_install_dir>\erlang\erts-9.0\lib\rabbitmq-server\rabbitmq_server-3.7.4\sbin folder, open the Command Prompt as Administrator, and run the following commands:
▪ rabbitmq-service.bat stop
▪ rabbitmq-service.bat remove
c. Under Installation Directory\modules\RabbitMQ folder, create a file rabbitmq-env-conf.bat with the content (replace HOSTNAME with the actual host name):
set SERVICENAME=RabbitMQFlow
set NODENAME=rabbitFlow@HOSTNAME
set NODE_PORT=5673
set NODENAME=rabbitFlow@HOSTNAME
set NODE_PORT=5673
d. Add the following line to Installation Directory\modules\RabbitMQ\rabbitmq.conf file:
management.listener.port = 15673
e. Delete all the files and folder under <flow_install_dir>\modules\RabbitMQ\mnesia.
f. Under Installation Directory\erlang\erts-9.0\lib\rabbitmq-server\rabbitmq_server-3.7.4\sbin folder, open the command prompt, as Administrator, and run the following commands:
▪ rabbitmq-service.bat install
▪ rabbitmq-service.bat start
g. Change the RabbitMQ port in platform-settings.json file:
"QueuePort": 5673,
h. In the deploymentConfig.json file, change the port for the modules: ux, trigger, engine, exchange, oauth, and lookup.
"ADAPTERS": {
"AMQP": {
"CONFIG": {
"port": 5673,
"AMQP": {
"CONFIG": {
"port": 5673,
i. Restart ThingWorx Foundation, and ThingWorx Flow services.
For Linux
a. Stop RabbitMQ, ThingWorx Foundation, and ThingWorx Flow services.
b. Under /etc/rabbitmqCreate folder, create a file rabbitmq-env.conf with the content (replace HOSTNAME with the actual host name):
NODENAME=rabbit2@HOSTNAME
NODE_PORT=5673
NODE_PORT=5673
c. Modify the etc/rabbitmq/rabbitmq.conf file with the following content:
[
{rabbit, [
{loopback_users, []},
{default_vhost, <<"orchestration">>},
{tcp_listeners, [5673]}
]
},
{rabbitmq_management, [
{listener, [{port, 15673}]},
{load_definitions, "/etc/rabbitmq/definitions.json"}
]
}
]
{rabbit, [
{loopback_users, []},
{default_vhost, <<"orchestration">>},
{tcp_listeners, [5673]}
]
},
{rabbitmq_management, [
{listener, [{port, 15673}]},
{load_definitions, "/etc/rabbitmq/definitions.json"}
]
}
]
d. Delete all the files and folders under /var/lib/rabbitmq/mnesia folder.
e. Change the RabbitMQ port in platform-settings.json file:
"QueuePort": 5673,
f. In the deploymentConfig.json file, change the port for the modules: ux, trigger, engine, exchange, oauth, and lookup.
"port": 5673,
g. Restart RabbitMQ, ThingWorx Foundation, and ThingWorx Flow services.
10. Configuring Rotating Activity Logs
If you are using ThingWorx Flow 9.2 or later, you have the option to configure rotating logs.
Under > , in deploymentConfig.json file, under LOGGING edit the following values.
|
Parameter
|
Value
|
Description
|
|---|---|---|
|
MAX_LOG_SIZE
|
This must be the number of bytes, kb, mb, or gb. When using the units, add 'K', 'M', or 'G' as a suffix, directly following the number. The default value is 10M.
There can be a deviation of about double MAX_LOG_SIZE.
|
This is to set log file size. It is the maximum size of the file after which the logs will rotate.
|
|
MAX_LOG_FILES
|
This value must be a number and the amount of the log files must be slight higher than what is configured. The default value is 10.
There can be a deviation of about double MAX_LOG_FILES.
|
This is to set maximum number of logs to be kept.
|
|
ROTATION_DATE_PATTERN
|
This must be a string representing the date format according to Moment.js Documentation to be used for rotating. The default value is set to YYYY-MM-DD which mean the log will rotate daily regardless of its size.
|
The meta characters used in this string will dictate the frequency of the file rotation.
|
A sample code looks like this:
"LOGGING":
{ "MAX_LOG_SIZE": "10M",
"MAX_LOG_FILES": "10",
"ROTATION_DATE_PATTERN": "YYYY-MM-DD",
},
{ "MAX_LOG_SIZE": "10M",
"MAX_LOG_FILES": "10",
"ROTATION_DATE_PATTERN": "YYYY-MM-DD",
},
◦ Following are the configurable modules: Engine , Exchange, Lookup, Oauth ,Trigger, Ux
◦ Separate all log variables using comma.
◦ The logs are available under > folder.
◦ Ensure that the logs are in correct format: <Log-Type/Name>-<Date in YYYY-MM-DD format>.log.<Log Number>.
|
|
If you have installed ThingWorx Flow on a different machine than ThingWorx Foundation, ensure that you complete the post-installation steps specific to this scenario.
|