Azure Skill: Detecting Flow Groups
Purpose: Authoritative rules for how an AI agent should group discovered TIBCO integration artifacts into logical flow groups. The agent MUST follow these rules exactly.
1. Grouping Strategy (Flow Reference Chains)
- HIGHEST PRIORITY: If multiple flows reference the SAME sub-process via
process-call(directly or transitively), they MUST be in the SAME group — the shared sub-process is the unifying element. - Call-workflow edges: The
connectionGraphincludescall-workflowedges when one flow calls another flow or sub-process viaprocess-call. Flows linked by these edges (directly or transitively) MUST be in the SAME group. Example: If Flow-A calls sub-process-B and sub-process-B calls sub-process-C, all three belong in ONE group. - Shared-connection edges: The
connectionGraphincludesshared-connectionedges when multiple flows use the same global configuration (e.g., samehttp:listener-config, samedb:config). Flows sharing configs SHOULD be in the same group unless they are clearly independent. - Only create separate groups for flows that use DIFFERENT sub-processes with no transitive connection.
- Transitively connected artifacts belong in the SAME group.
- Name each group by business purpose (derived from flow names and HTTP listener paths).
2. Fallback Rules (When no HTTP listeners or schedulers exist)
Do NOT return empty groups. Use this fallback order:
- Flow-root grouping — one group per CONNECTED flow cluster. Follow
call-workflowedges to find clusters. Do NOT create one group per individual flow when they reference each other. - Trigger-capability grouping — flows with sources (http:listener, scheduler, jms:listener, file:listener, JMS/EMS listener) as entry points.
receiveLocationCountincludes all triggers. - Connected-component grouping — from graph edges (
call-workflow,shared-connection) and any remaining connections.
Only leave artifacts in ungroupedArtifactIds if they are truly isolated with no meaningful edges or entry semantics.
For fallback groups, set entryPoint to flow/trigger/internal-entry (not receive-location).
3. Required Output Fields
Each group MUST have:
| Field | Type | Description |
|---|---|---|
id |
string | Unique group ID (e.g. flow-1-order-processing) |
name |
string | Human-readable name by business purpose |
description |
string | What this flow does |
category |
string | e.g. message-flow, shared-infrastructure |
artifactIds |
string[] | MUST NOT be empty |
entryPoint |
object | Entry point (type, name, messageType) |
exitPoints |
array | Exit points (type, name, messageType) |
4. Procedure
- Call
migration_detectFlowGroupsto get the artifact connection graph and summaries. - If the connectionGraph has few or no
call-workfloworshared-connectionedges, the process-call data may be incomplete. In that case: a. Callmigration_listArtifactswithcategory="custom-code"to find JARs and custom Java classes. b. Read flow source files (migration_readSourceFile) to findprocess-calltargets and shared config references. c. Use the discovered call chains and shared configs to merge groups that should be together. - Determine logical flow groups using the process-call chain strategy above, incorporating both graph edges AND any call chains discovered in step 2.
- Call
migration_discovery_storeFlowGroupswith the groups array,ungroupedArtifactIds, and explanation.
5. What NOT to Do
- Do NOT create empty
artifactIdsarrays. - Do NOT split flows linked by process-call chains into separate groups.
- Do NOT skip source reading when the connectionGraph has missing call-chain edges — incomplete grouping causes downstream analysis failures.