Stage 2 - Integration Analysis¶
A detailed study of each integration you select: what it does, what it connects to, how data moves through it, and how complicated it is.
Stage 1 told you what is in the export. This Stage opens the integrations up one at a time. It is the first point in a Project where you get a document about a single integration rather than about the estate, and it is the first point where you choose how much work to do.
Selecting integrations¶
The page carries the list Stage 1 built, headed Select Integrations with a count. Each row gives the integration’s name and, after a middle dot, the short note the Export Analysis produced for it - its category, its complexity and a one-line description of what it does.
Two things about the list are worth knowing before you touch it.
Everything starts ticked. A freshly built list has every integration selected, so pressing the run control without looking analyzes all of them. On a large export that is a great deal of work you may not want. Select All and Deselect All are at the top right if it is quicker to clear the list and tick a few.
A tick mark against a row means SLIM has already produced a document for that integration. SLIM works this out by looking at what is actually on disk rather than at what it remembers doing, so the mark is trustworthy. An integration whose analysis failed does not carry one.
Save Selection at the foot of the list records what you have ticked, and the page reloads to confirm it. Press it every time you change the ticks, and before you run anything. A saved selection is kept with the Project and is still there when you come back; an unsaved change is not a selection at all, and the last selection you saved is the one that should count. Re-running Stage 1 clears it, because that rebuilds the list from scratch with everything ticked again - see Stage 1 - Export Analysis.
If nothing at all is ticked, SLIM will not start. It tells you Please select at least one integration.
Warning
In the current build, pressing a run control also saves the ticks - including ticks you chose not to save. Whatever is on screen at the moment you run becomes the saved selection, silently and without confirmation, so an experimental tick you left in place is acted on rather than discarded. This is not what Save Selection is for and it is not behavior to depend on. Set the list to what you actually want, save it, confirm the page comes back with the selection you expect, and only then run.
Running it¶
Look at the Integration Analysis Prompt panel before you start - the section below covers what belongs in it - and then Run Integration Analyzer. In automatic mode you never press it, because Stage 1 hands straight over; see Choosing an Execution Mode.
The Activity Log streams what SLIM is doing while it works, and a Stop button is available. If another run already holds the Project you are told it is busy rather than being given a misleading error - see When a Project Is Busy.
You can watch it a second way. As each integration is picked up, a folder named for it appears under /migrations in the Project Tree on the Project Home Page, and its analysis document appears inside that folder when it is written. The Job Status page also lists every integration with its own status - Pending, Integration Analyzing, Integration Analyzed, Analysis Failed or Analysis Incomplete - and the time it started. That page does not refresh itself, so reload it or follow the Activity Log instead; see Monitoring Progress.
Two banners can appear on the Stage Page when it stops.
Integration Analysis ended without finishing, with The run exited without an error, but didn’t produce its expected output. Retry to finish the step. This is usually worth retrying as it stands.
Integration Analysis failed, with the error underneath it. See Stopping and Restarting.
When it finishes, a panel appears at the top of the page: Integration Analysis complete, with Continue to Pipeline Generation.
What this stage produces¶
One document per integration, written into that integration’s own folder under /migrations and named for the Project and the integration. This is the difference between this Stage and the one before it: Stage 1 produced a single document about the whole export, and this Stage produces as many documents as you selected integrations.
Each one is long, and it is organized as thirteen numbered sections:
What it does, and why the business has it. Its purpose, the business context around it, and the teams that depend on it.
How it is built. A diagram of the integration, its components listed out, and a breakdown of how much of its logic sits in configuration and how much is embedded code - which is often the part nobody remembers writing.
What it connects to. The source systems it reads from and the target systems it writes to, with the connection and data-format detail for each.
What happens, step by step. The end-to-end flow, from receipt through processing and transformation to delivery, followed by a diagram of how data moves between systems.
What happens when it goes wrong. Exception handling, retry behavior, monitoring and alerting, and how the integration recovers.
Design decisions, performance and dependencies. The patterns the original authors used, how the integration behaves under load, and what else it relies on.
How it is tested, deployed, configured and maintained. Including the routine operational procedures around it.
A summary, closing with a complexity assessment.
Every document carries diagrams rather than describing the flow in words alone, and SLIM checks them before it finishes. If one has slipped through, it shows in the document as a Syntax error in text placeholder instead of a picture; re-run that integration, or take the diagram out before you send the document to anyone.
Where to read it¶
Not on this page. The document panel here holds the Export Analysis document from Stage 1, because this is the Stage that reads it - the same rule as before, that a document is edited where it is consumed.
The integration documents are consumed by Pipeline Generation, so that is where you read and edit them: a dropdown at the top of the panel lists the integrations that have been analyzed, and choosing one opens its document with Edit, Download for Markdown (.md) or PDF (.pdf), and an expand control that gives the document the whole working area. Save before you navigate away or your changes are gone. The Job Status page has an Integration Analysis button that opens the document for the selected row read-only, with nothing to download. The documents are also visible in the Project Tree under each integration’s folder, and clicking one opens it in the preview pane, which offers the same Markdown (.md) or PDF (.pdf) download for any Markdown document. See Reading Analysis Documents.
Work runs in parallel, and fails independently¶
Selecting twelve integrations does not queue up one long job. It starts twelve separate pieces of work, each of which reads one integration and knows nothing about the others.
That isolation is deliberate, and it has two consequences you will notice.
One failure does not stop the rest. If an integration fails, the others carry on and finish, and you retry the one that failed. The Job Status page is where you see which is which.
No integration can affect another’s analysis. There is no way for two integrations being analyzed at the same time to become confused with one another.
Several run at once, not all of them. If you select a lot, the remainder wait their turn and are picked up as capacity frees, so a large selection takes proportionally longer rather than arriving all at once. Nothing is lost while a piece of work waits.
How long it takes¶
Longer than Stage 1, and long enough that you should not sit watching it. How long depends on how many integrations you selected and how complicated they are rather than on the size of the export, so the same Project can take minutes or hours depending on what you ticked.
The useful thing to do with the wait is the reading you owe anyway. The Export Analysis document is on this page, and correcting it now costs almost nothing - see Verifying the Output. You can also read the integration documents as they land, one at a time, without waiting for the last one.
This is the stage that pays for itself¶
For many customers this document is the first clear statement of what an individual integration actually does that anyone has had.
Integrations get inherited through restructures. The people who built them have left. What is left is a break-fix relationship: the team knows how to patch these things and keep them running, and not much more. A document that says plainly what one of them does, what it touches, how it fails and how complicated it is changes what that team is able to decide.
Including the decision underneath the whole project, which is whether a given integration should move forward at all. Not everything in an export needs to: some will be retired, and several will turn out to be doing the same job as each other. A customer who stops after this Stage has still gained something they did not have before. That is also why the documents are worth reading closely and correcting - see Sharing Results for Approval.
Adjusting and re-running¶
Instructions for this Stage go in the Integration Analysis Prompt panel on this page. Edit, type, Save. They apply to this Stage and no other; guidance meant for the whole Project belongs in the Global Prompt on the Project Home Page instead. Empty, the panel reads No step-specific instructions - click Edit to add some.
One thing does not belong here: what you want the integration to become. This Stage answers what the thing does today, not what it should do tomorrow. Design intent, target structure, naming conventions for the new pipelines - all of that goes into the Pipeline Generation instructions, and putting it here distorts the description of the current state you are about to build everything else on. SLIM enforces the same separation itself: it will not read the design documents attached to the Project at this Stage, on purpose. See Where Guidance Belongs and Supporting Documents.
Then re-run, and be deliberate about the ticks first. Re-run asks Re-run integration analysis? This will overwrite existing results. and it means every integration that is ticked, including the ones that finished perfectly well the first time. Each of those documents is replaced, and any hand edits in them go with it.
To redo one integration, untick the others and save the selection first. This is the common case after a single failure, and it is much cheaper than redoing the set.
To redo everything, leave the list alone. Useful after changing the instructions, when you want every document to reflect the new guidance.
Download anything you have edited by hand before re-running it. There is no other copy, and nothing warns you.
If a run failed the control is Retry rather than Re-run; if you stopped it, it is Re-run. Either way the overwrite is the same. See Stopping and Restarting.