Using the debugger effectively requires some understanding of iSM. This appendix is a non-technical discussion of iSM architecture and is limited to the basic knowledge required to debug.
iSM is a server that provides the ability to manage several channels each with an assigned protocol. For example, there may be a few file channels, a few HTTP channels, a few internal queue channels, etc. As each message arrives at the channel, it is assigned for work to a subchannel. The number of subchannels available to the channel is configured with the channel and can be set to vary depending upon workload.
In iSM, a channel is often called a master or listener; the subchannel is often called a worker.
The worker first encapsulates the incoming message into a document, which contains information about the message (has an error been encountered, are there attachments…). The message itself is called the payload, and it can be XML or non-XML. Additionally context information about the message (e.g. for a file channel the file name is stored) is made available in special registers. The document is passed to the process flow (Pflow) for business handling of the payload and context (registers). The debugger can manipulate the registers and document during the debug run as needed during the debug session.
Each worker is given an identifier, which takes the form W.channelname.n. One execution thread is assigned to each worker. This thread is passed into the PFlow, where additional execution threads may be assigned as the document takes simultaneous paths under control of the PFlow's program.
The Pflow program consists of nodes and edges. The nodes do the actual processing on the message and the edges connect the nodes one to the other. The debugger considers each node to have a lifecycle. This is shown in the diagram above in this manual. The inedge is the start of the node, when the interpreter first reaches it. The node process stage performs the actual task assigned to the node, such as doing a test or making an HTTP emit. Following this, the node reaches the outedge, where the registers being watched are checked for changes. The debugger then offers the opportunity (if an outedge breakpoint has been set) to see the edges that the process stage has selected to be followed. Passing control down these edges is called the dispatch stage. You can change the edge[s] to be dispatched if desired. The interpreter also supports synthetic edges which internally represent edges to be followed for specific conditions, such as $fail which matches any fail edge if no specific failure is taken.
iWay recommends the use of Integration Applications (iIA) to encapsulate a logical application. An iIA is an iSM runtime configuration. Although there is no strict rule that one configuration be one application, it is a common paradigm and in most cases a best practice. The debugger runs within the configuration and can be attached to the configuration's channels and Pflows.
In business applications, commonly multiple channels are employed in processing each message. A message can be passed from channel to channel under program (Pflow) control. Each channel often performs one step of the application processing. The debugger can be tasked to handle execution on multiple workers and multiple channels, enabling the configuration as a whole (the application) to be debugged.