And here's how we did it....
When it comes to printing, control is everything.
And that’s even more true when you work with mission critical businesses like logistics, healthcare, pharmaceutical and legal.
When we built our first variation of ScriptX (way back in 1999) we impressed customers by becoming globally acknowledged as the ‘de facto’ web-technology printing utility. But, as companies grew larger, and an ever-increasing number of corporate applications became cloud-based, we soon realised there was a strong need for highly advanced browser capabilities that offered more long-term scalability and enhanced levels of print control.
But here’s the thing.
That level of control isn’t easy to achieve.
And especially not in the case of ScriptX.Services for Windows PC, which runs per user. That meant that when we had concurrent users (i.e. users who had all signed in at the same time and or weren’t signing out after sessions), it dramatically impacted the experience of ScriptX.
So, in August 2021, we launched our V2.15.0 edition – a variant which introduced a new, and ‘simple’ client-side solution. This solution involved coding ScriptX to ‘hunt’ for the port in use, and to only stop once a valid answer was found. Simple yes, however, we found it only just solved the problem. It caused terrible lag times, and the user experience issues remained. As result, a different approach was required.
In short, what we needed to do, was adapt ScriptX in a way that ensured every user who logged on to ScriptX was assigned and *guaranteed* a unique port value. This would ensure users were not confused with anyone else logged-on, all the while still giving developers the ability to control the entire print experience.
And this was when ScriptX.Services Orchestrator was born. Read on to find out more.
The development of Orchestrator: an overview
ScriptX.Services Orchestrator for Windows PC (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. (NB. If the PC is not shared, or if all users sign out at the end of their session, then Orchestrator is not needed).
Orchestrator was needed, because without it, the JavaScript code used in the client browser would attempt to use the default port for connecting to the server and, when there were concurrent sign-ins, that port would be wrong for all users after the first allocation.
And that was a big problem.
Because if that happened, we could no-longer guarantee the print workflows of a web application to developers; a promise which the ScriptX brand had been built upon. So, we set about fixing it.
Defining the perfect architecture
The development team at Mead Co. quickly defined that there were a few possible solutions to ScriptX’s port problem. Two of them included:
1. Generating the client-side code to use the correct port for the user
2. Or utilising the ScriptX.Services V2.15.0 and later variants of the ScriptX.Services Client Library (which offers compatibility to ScriptX.Addon for ScriptX.Services).
But these options were not considered to be viable.
The first, would have been too complex to code and hard to maintain, while the second process would likely have been too slow and may have a significant negative effect on the user’s experience. What we needed instead, was a solution that meant when a user went ‘inactive’ they release the port they were using, so that a newly signed-in / active user could then use the allocated port.
This however wasn’t as easy as it sounds.
Our large and heavy Kestrel server meant finding that free port was not straightforward, so a secondary ‘lightweight’ server was required.
This server would essentially take up the role of ‘speaking’ for the Kestrel server and respond with the port in use. This mini server would also need to self-sleep and relinquish the port when a user becomes inactive, so that another could use it. Then all JavaScript has to do is execute a simple request via the Orchestrator REST API, that returns the port in use by ScriptX Services.
Note: In the case of RDS and Citrix environments (where this Orchestrator would not work) we defined that a Windows Service would need to be utilised. The Windows Service would start when the host system was started and allow Orchestrator to maintain a table of key/address pairs. This client JavaScript must know the key – as passing in the key would return the port in use.
The development
ScriptX.Services Orchestrator was developed first as a small self-contained application.
We began conducting real world testing Orchestrator 1.0 in February 2022 and then in May 2022 – and only once it had proven to be reliable mini-server code – it was folded into ScriptX.Services, so that a separate install was not required. It has been live and operational ever since.
The final outcome
Now, when a user become inactive while using ScriptX (i.e. when another user is signing-in), their Orchestrator instance stops ‘listening’ on the configured port. This makes the same port available to the new active user – where their own Orchestrator instance starts up and listens on the configured port instance.
As a result, our solution does all that we set out for it to do. It offers a fast response with the ScriptX.Services for Windows PC, and all ports can now be allocated to the user, so that the single endpoint is always the same. AND it doesn’t matter how many people are signed into ScriptX either.
As a service, Orchestrator is a Windows Service that provides orchestration and port discovery seamlessly and effectively for users and developers alike. But as a product, it’s a one-in-a-kind solution for resolving port conflicts as they arise, and unlike anything else on the market.
How you can use Orchestrator today
ScriptX’s Orchestrator is available in two forms:
1. A built-in version, available with ScriptX.Services for Windows PC v2.17.0 and later.
NB. This solution is recommended for single Windows 10/11 PCs shared among several users.
2. And as a first-class Windows system service installed in addition to ScriptX.Services for Windows PC.
NB. This solution is required when using a shared host in desktop experiences such as RDS. (This solution can also be used for single Windows 10/11 PCs shared among several users. This enables a single code base solution that is applicable to different environments).
Why Script.Services Orchestrator is so critical for mission critical businesses
This question is simple to answer:
• Orchestrator is a ‘game-changer’ across all Windows environments, and not just RDS and VDI. For Mead Co customers it’s particularly important for single-shared PC environments. In fact, it’s a one-of- a-kind solution for resolving the port conflicts that arise when ScriptX is in use. What’s more, prior to its release there were no other readily available solutions to utilise.
• Orchestrator for ScriptX is an indispensable tool for ensuring that mission-critical print jobs are completed accurately and on time, ultimately supporting overall business continuity and performance.
In other words, our print SDK gives organizations:
• Seamless multi-user printing and consistent outputs
• Accurately managed batch printing (print jobs occur at the correctly targeted printer, 100% of the time)
• Full configurability and stability across all locations
• No more wasted dev time.
Partner with the experts in print
At ScriptX, we don’t just build a print SDK. We help businesses to launch web applications faster and with more robust print workflows. So, whether you’re building a web app or custom SaaS product, you can rely on ScriptX to give you and your users perfect print every time.
To learn more about how Orchestrator works for Built-In and as a Service, or to find your perfect licence, visit our Developer Hub for more information.
*ScriptX.Services Orchestrator for Windows PC does not assist ScriptX.Services for On Premise Devices or ScriptX.Services for Cloud.
