Orchestrator for ScriptX.Services for Windows PC
ScriptX.Services for Windows PC does not run as a system service, it runs per user.
ScriptX.Services Orchestrator assists in the case of multiple users concurrently signed in to a Windows PC with ScriptX.Services for Windows PC running for each user.
If the PC is not shared, or all users always sign out at the end of their session then Orchestrator is not helpful because all users will use the same port (typically the default port 41191).
Orchestrator does not assist ScriptX.Services for On Premise Devices or ScriptX.Services for Cloud.
What happens without Orchestrator
Since v2.15.1 as each user signs in, concurrently with other users, ScriptX.Services for Windows PC starts up and assigns an unique port to itself. The port number is assigned as the next available port after the configured default port (for first run this is 41191 typically).
So, the first user to sign in will use port 41191, the second port 41192, the third port 41193 and so on. The port used is recorded in the
appsettings.json file for the user
(typically located at C:\Users\[UserName]\AppData\Local\MeadCo\ScriptXServices) and will be used as the configured default port the next time the user signs in.
There are 3 possible solutions to this problem :
Dynamically generate the client side code to use the correct port for the user. To make this work effectively most likely requires that the port for a user is recorded in the user's profile data held in the application and is also specified in the
appsettings.jsonfile for the user (typically located at C:\Users\[UserName]\AppData\Local\MeadCo\ScriptXServices).
Alternatively it is possible to store the port used in the user's browser local storage or a cookie.
Either may be complex to code and maintain.
If using the ScriptX.Services v2.15 and later and v1.9 or later of the ScriptX.Services Client Library (implements compatibility to ScriptX.Addon for ScriptX.Services) then the library will take the given server url, including port and try to connect to it.
If the connection fails it will increment the port and try the next, trying up to 10 ports.
This can be a slow process that may have a significant negative effect on the user's experience.
Orchestrator is built-in and available with ScriptX.Services for Windows PC v2.17.0 and later, is simple to use and does not negatively effect the user's experience.
What happens with Orchestrator
When a user signs in, Orchestrator starts up and listens on the configured port (typically 41190).
The way that ScriptX.Services for Windows PC works does not change; as each user signs in, ScriptX.Services for Windows PC starts up and assigns an unique port to itself.
Orchestrator is built-in and available with ScriptX.Services for Windows PC v2.17.0 and later.
When the user becomes inactive, for example because another user is signing in, Orchestrator stops listening on the configured port. This makes the same port available to the new active user.
This is a single, quick, call that will not negatively impact the user's experience.
Please note that in the examples below e29212c9-3c6f-41ac-8078-4596738fdb59 should be replaced with your own License GUID.
Using attributes to specify the connection to ScriptX.Services
Specify that Orchestrator should be used by adding the data-meadco-orchestrator attribute, for example:
<!-- Add.on to scriptx.services compatibility --> <script src="//email@example.com/dist/meadco-scriptxservices.min.js" data-meadco-server="http://127.0.0.1:41191" data-meadco-orchestrator="41190" data-meadco-license="e29212c9-3c6f-41ac-8078-4596738fdb59" data-meadco-license-path="warehouse" data-meadco-license-revision="0" data-meadco-syncinit="false" > </script>
Using code to specify the connection
Set the "MeadCo.ScriptX.Print.orchestrator" property to a non-zero value to enable use of Orchestrator. This must be done before calls to connect to ScriptX.Services or apply a license. For example:
With "fetch" based code
The API is simple and requires no authentication. Default fetch() options should work.
It would be reasonable to assume that if the call fails then Orchestrator ScriptX.Services is not available or not running for some reason rather than there having been an error at the server.
response is port: not run yet (0 means failure, see console).