We have users who work with Simple Workspace every day, using the classic web-based application.
It couldn’t be simpler!
The Simple Workspace platform can manage product data flows, press articles, images, InDesign documents, etc. It provides configurable workflows to manage these incoming flows.
It can generate catalogs, books, cards, etc. grouped in Flatplans, and provides workflows to manage the inherent workflows, such as proofreading, validations, and translations.
It produces validated data, PDFs, InDesign or Excel files, etc.
It is used by many companies, each of them having different data models, production workflows, and various types of documents.
How does the Simple Workspace platform, which is in demand 24 hours a day, maintain a consistent level of performance, whether in reliability or in smooth response times? How does it protect the privacy of each client and the confidentiality of their data, and how does it allow updates to be made on a regular basis, but also in a structured manner?
Simple Workspace is constantly upgrading!
Obviously, there is no easy solution!
However, behind this regularity, there is of course a human team that has been building and evolving the platform for years, a set of modular software bricks that have been logically assembled and cooperate to optimize their performance, an optimization that relies both on the hardware and on the way these bricks interact with each other.
In the following article, you will learn about two examples that highlight the way Simple Workspace has been architected to achieve its performance and overall reliability, and that allow the platform to evolve regularly without disruption.
When a user logs in, the authentication phase directs them to one or more workspaces, which contents are filtered. It is at this point that the user’s task list is retrieved, which can guide him to specific elements, such as products to be validated, pages to be reviewed, etc. His actions generate queries which are then sent to the system. His actions generate requests that are directed to one of the available “front-end” servers.
The concept of a workspace is important. In fact, it refers to the different workspaces in the interface that are accessible to the user. Each space can have its own databases: this is one of the keys to the architecture, which explains, for example, how the DAM of one company is a different database from the DAM of another company within Simple Workspace, or how the same company can use several DAMs.
This physical fragmentation has several consequences, including security (“a database cannot impact the operation of another database”), performance and consistency (the actions of one database do not impact the actions of the other), flexibility (each database contains various data descriptions), and smoothness (databases can be copied, or even used in different versions, in order to evaluate the consequences of a version upgrade, for example).
The notion of multiple databases does not only concern the DAM: the BRIEF (Flatplan), as well as the MOM (source databases), are also databases distributed within the workspaces. In fact, all Simple Workspace applications benefit from this partitioned design.
As you can imagine, distributing thousands of databases in this way requires orchestration. They have to cooperate with each other, like when you drag an image into a product sheet or a page, or a news article. This orchestration of workspaces and the related databases contained (or inherited) is itself based on distributed databases, databases that “manage databases”.
Another theme is the operation of the InDesign servers, which is the object of much attention: the response time of a task assigned to an InDesign server is indeed crucial for the user, whether it involves generating hundreds of pages or previewing an article.
To handle this, Simple Workspace implements what internally is known as “dispatchers”, which can be considered as ” pointers ” that receive job requests (e.g. generating a product sheet rendering), and they are familiar with the most appropriate InDesign services available and assign the job to them, and then return the response to the user – who then sees the output as an image.
Choosing the most appropriate InDesign service is a delicate exercise, which relies among other things on knowing which services are free (which are not generating a document, for example), and on the fact that the images that the InDesign service will need are available and accessible quickly: nothing is left to chance so that the InDesign document is processed as quickly as possible. In the worst case, if all the InDesign services are busy, then the job is waiting for a release: this is called contention. But we have enough parallel services that this only happens in exceptional cases!
So far I have not discussed the underlying hardware infrastructure, which is itself very sophisticated and resilient to provide a reliable and resilient service. This infrastructure contributes to Simple Workspace’s scalability, i.e. Simple Workspace’s ability to grow to accommodate more customers, as well as to absorb peak loads, such as when multiple customers have overlapping production cycles.
There are many ( really a lot ) other topics to talk about, each of which has involved the J2S teams at some point in making sustainable and optimized choices and implementing, testing, and monitoring them. This will be the subject of other articles!
Contact us : we are looking forward to hearing from you.
D. Lantier
Business Developer