YYR Repo Map

This repo is a Python migration tool that reads Apigee policy XML and emits MuleSoft project files or Flex Gateway YAML. The main path starts at the Typer CLI, moves through a pipeline, and turns source policies into mapped outputs with optional validation. By the end of this note, a cold reader should know the first moving parts and what a policy file looks like.

First ReadURL copied

The command entry is src/cli.py, exposed as migrate in pyproject.toml. It configures logging, then calls src/pipeline.py, which owns the high-level sequence: ingest, lookup, mapping, execute, validate, and audit.

src/ingest.py finds XML policy files in Apigee bundle shapes and ad hoc policy folders. It parses each XML root into a Policy model from src/models.py, preserving source path, category, family, config, and chain order.

src/mapping.py converts parsed policies into source-to-target mappings. Its old stub table still documents expected MuleSoft equivalents, but live lookup now delegates to src/semantic.py.

src/execute.py writes the target artifact. For mule-xml, it calls LLM-backed generators in src/llm.py; for flex-gateway-yaml, it copies matching YAML templates from an expected/template tree.

XML Policy FilesURL copied

At the basic level, one Apigee policy file is one XML document whose root tag is the policy type and whose name attribute is the policy instance name. A tiny Verify API Key policy says: read the API key from one request location.

<?xml version="1.0" encoding="UTF-8"?>
<VerifyAPIKey name="VerifyAPIKey-1">
  <APIKey ref="request.header.x-api-key"/>
</VerifyAPIKey>

Larger policies still follow the same shape: root policy tag, child config tags, and variable references inside child tags. This AssignMessage policy stores pieces of the incoming request into named Apigee variables.

The repo mostly cares about the root tag, the name, child config, path, and discovery order. That becomes the Policy object consumed by mapping and execution.

Pipeline CanvasURL copied