What runs where#
| Where | What |
|---|---|
| In the MAS cluster on OpenShift | One container per Manage workspace, next to IBM’s own MAS components, with a data volume for the workbooks and the job history. It is reached under the suite’s own domain. |
| Inside Manage | Four automation scripts, an application of its own for the rights, and two security groups. |
| Optional, in the cluster | Metrics for Prometheus and a set of alerts. |
Users open the app in the browser and sign in through MAS, like any other part of the suite. Nothing gets installed on their computers. A command line client exists for scripts and build servers.
Who does what#
The work splits along what each side does best.
The app handles everything that has to do with files and time: it reads the workbook, streams large sheets, plans every row, keeps the history and the log, and writes the result workbook. A workbook of a million rows stays on the app’s volume and never travels into Manage as a whole.
The scripts inside Manage handle everything that needs Manage’s business objects. The app sends them rows in small groups, a record together with its child records. The scripts apply each group through the business objects, in one save: relationships, status changes, field validation and your own automation scripts run as they would in the Manage screens.
The seam between the two is a small JSON document per batch of rows. That keeps each side simple, and it makes the seam easy to test.
It works as you#
Every write happens as the person who signed in. When you open MAS Data Import, you sign in through MAS. The app passes that sign-in on to Manage with each call, so Manage sees you and applies your security. On our test system, a record saved through the app carries the user’s own name in its change history, read back independently.
The app has no Manage account of its own for imports, and it never falls back to one. It keeps your sign-in in memory only, for your session and for a job that runs. It never writes it to the volume, a log line or a metric.
Long jobs need care, because a sign-in expires after a while. The app renews it before each batch while it can. When renewal fails, the job stops at a safe point and waits for you. You sign in again, press Resume, and the job continues where it stopped, without sending a row twice. For jobs of many hours, the command line client with a Maximo API key suits better.
Automation scripts in place of Java#
Inside Manage, MAS Data Import needs four automation scripts. We write them in TypeScript and build each one into a single file in the JavaScript dialect that Manage’s script engine runs. A build check fails on anything newer, so a script never meets a syntax Manage cannot read.
The app installs the scripts itself. An administrator presses Install on the administration screen, and the app writes the scripts, its own application with its options, and its two security groups, with the administrator’s own sign-in. Where an installation may not write scripts, the same files can be exported and installed by hand.
Nothing else in Manage changes. The app adds no Java code and no customization archive, and it
leaves the existing applications, their options and their settings as they are. Its rights live in
its own application, MASIMPORT, as signature options that you grant like any other.
Two ways into Manage#
MAS Data Import writes through one of two paths, chosen per job:
- The business object path applies the rows through the scripts described above. It reaches any relationship the workbook names, sets a status at the position of its column, and runs the automation scripts that a workbook names per row, inside the same save.
- The object structure path turns each group of rows into a document for an object structure and imports it through Manage’s integration framework. The object structure decides which objects and attributes may change. An administrator who wants a strict import builds an object structure with exactly the fields an import may touch, and offers only that one.
Deployed like a cluster app#
An OpenShift administrator deploys MAS Data Import with a small overlay for the cluster: the namespace, the domain and the routing. The container image is pinned by its digest, so the cluster runs exactly the image that was tested. Settings come from a ConfigMap, and the app checks the file against its catalogue on every change. A file with an error keeps the previous settings in force and raises an alert.
The app serves its metrics to Prometheus, with alerts for the conditions that need a person. Two scripts back up the data volume while the app runs, and restore it.
Because nothing goes into the Manage image, MAS Data Import has a release cycle of its own. A new version is a new container image. The scripts carry a version number, and the administration screen shows the installed and the bundled version side by side.
What comes next#
The next article is about the step that comes before every write: the plan. The MAS Data Import page lists the whole series.
Want to see MAS Data Import running beside your Manage? Get in touch.