Lesson 9Hands-on · ~25 min

Testing Your Project

Before promoting a project to production you have to know it works. Magic xpi ships two tools for the job: the Checker, which audits your configuration, and the Debugger, which lets you walk a live flow step by step. This lesson tours both.

The Magic xpi Checker

The Checker lives inside the Studio and audits the way your components and flows are defined. It runs automatically when:

You start the Debugger.
You build an executable for deployment.

It can also be run manually:

Project » Checker... » Run (or Ctrl+R) to check the entire project.
Checker... from a flow's context menu to check a single flow.

What gets disabled. If errors are found while debugging, no executable is created. If errors are found during a build, only flows with errors are made inactive — so the rest of the project can still ship.

Reading the Checker Results

The Checker classifies messages by severity:

Error	Fatal — the step will not work. Example: missing component configuration.
Warning	Won't stop the step from executing, but the result may not be what you expect.
Information	Efficiency hints, like an undefined timeout or insufficient Server capacity.

Filter buttons at the top of the Checker Results window let you toggle message types on and off. Double-click any line to jump to the exact location that produced the message — the fastest way to fix things.

Step-internal logic. The Checker validates configuration but does not evaluate the logic inside a step (expressions, conditions, etc.).

The Debugger

The Debugger runs your project — or attaches to a project that is already running — against the live Server engine. Two ways to start it:

Open mode	Opens a project on the local machine. Debug xpi » Start Debugging or press `F5`.
Attach to Project	Connects to a running project locally or on a remote Server. Debug xpi » Attach to Project.

While debugging, all step properties are read-only. Stop the Debugger to make changes, then restart.

The Debugger has two modes:

Stopped	Waiting for a command. Lets you toggle breakpoints, change settings, or step.
Running	Executing one or more flows. The Continue, Restart, Break All, Stop, and Context View commands light up.

Debug a single flow? If you choose Debug from a flow's context menu, every other flow in the project is disabled for that session.

Breakpoints and Suspends

A breakpoint halts execution on a specific step. When the Debugger hits one, every running thread or branch stops before its next step; the Debugger then waits for Step or Continue. Toggle a breakpoint by selecting the step and choosing Breakpoint from the context menu — a red dot appears on the step icon.

Suspending is different: a suspended step is skipped, a suspended flow won't run at all, and a suspended branch is treated as already executed. To suspend, right-click the step and choose Suspend Step; the icon and text dim to indicate the change. The very first step and the very last step in a flow can't have their branches suspended.

Context Tree and Context View

When the Debugger is running, the Components pane is replaced by the Context Tree — a tree of every loaded context for every running flow. Only one context is the active debug context at any time; right-click a different context and choose Set Active Context to switch.

Colors and emphasis tell you the state at a glance:

Yellow	The active debug context.
Gray	The context's path.
Green	Contexts still running.
Black	Contexts that stopped without hitting a breakpoint.
Bold	Active step in the active context.

The Context View form (open it from Debug xpi » Context View while stopped) lists every variable visible to the current context, grouped by scope on four tabs. You can edit values directly — very handy for "what if" testing.

Adding Your Own Log Messages

Sometimes a breakpoint isn't enough — you want a trail of what's happening at points before the breakpoint. Magic xpi gives you two ways to add your own entries to the Activity Log:

Use the Logging section in any component's Properties pane.
Drop a Save Message utility wherever you need it.

Logging Scope	No, Step, Method, or Full. Method is not available with the XML interface.
Step Logging Options	Before, After, or Full — only meaningful when scope is Step or Full.
Message	String to be written.
BLOB / File Extension	Optional BLOB attachment plus the extension that determines which viewer the Monitor uses.

As an example, on the Send Email to Sales step set Scope to Step, Options to Before, Message to "A request was received", BLOB to F.RequestXML, and File Extension to XML. Now the request payload appears in the Activity Log before the email is sent.

Exercise

Try the tools.

Run the Checker on the whole project; clean up any messages it surfaces.
Add a breakpoint on the Extract Details from Request step and run the Debugger in Step mode.
Run the Debugger again, this time without breakpoints, and review the Activity Log afterwards.

Summary

You should now be able to:

Run the Checker and triage its findings.
Start the Debugger and switch between Open and Attach-to-Project modes.
Add and remove breakpoints, suspend steps and branches.
Inspect (and modify) variable values from the Context View.
Add custom Activity Log messages from a component's Logging section.