A recent SAP Integration Suite update adds native GitHub integration for your integration flows. You can now connect a GitHub repo straight to your tenant and push, pull, and import iFlows directly from the design view. It’s a welcome addition, the kind of thing that really could’ve been there years ago.
Here’s what it actually does, where it gets a little rough around the edges, and how it compares to what Figaf has been doing in this space for a while.
What’s new
Open a package and you’ll spot new Git Push and Git Pull buttons under Actions, plus Git import when you add an iFlow. In total, you’ve got three moves:
- Push send an iFlow from the design view up to a chosen repo and branch. Push it, and it shows up in GitHub as a folder representing your flow.
- Pull grab the latest changes from a branch back into the design view.
- Import create an iFlow directly from a repo branch.
Setup is pretty easy: an admin goes to Settings → Integrations → Git Access, behind a slightly sneaky Edit button, hits Add, pastes in the repo URL and a GitHub Personal Access Token, and hits Connect. You can wire up to 50 repositories per tenant.
And in the monitoring view, synchronized objects now show two new properties, Repository and Branch, which gives you a bit more context on what’s backed up where.
So: is this the end of iflow_v3_actually_final.iflw.zip flying around? Not quite.
Some catches
1. It asks for your token. Every. Single. Time. Every push, every pull, every import, there’s no “remember me.” That, combined with there being no “Push All from Package” option, is a recipe for a boring afternoon.
2. There are no guardrails on where things go. Nothing stops you from pushing iFlows from different packages into the same repo, branch, and folder. For a small landscape, that can be fine. For an environment with thousands of iFlows, you can see how it gets messy fast. The discipline has to come from you, not the feature.
3. Import won’t let you clone-and-rename. Say you want to import an existing iFlow just to tweak it and deploy it as something new. You can’t, the Git import keeps the original ID and won’t let you change it on the way in, so you hit an ID collision. To make a copy you still need to export it manually and import it back the old way. So the archives aren’t entirely gone yet.
4. It only works for iFlows. Mappings, script collections, and everything else won’t come along for the ride.
Figaf: Git, but make it a workflow
Figaf has had Git integration in its Change Tracking Tool for a while, and it comes at the problem from a different angle. Where SAP gives you buttons to press, Figaf’s approach is closer to “let the tool watch everything and handle Git for you.” One is a feature; the other is a workflow.
What that looks like in practice:
1. Setup is one switch. You go to your agent, enable Git integration, and fill in the same Git details. That’s the configuration, and unlike SAP’s feature, once it’s set up there’s nothing else you need to remember to do.
2. Syncing is automatic. Every time you run a synchronization, all detected changes get committed and pushed to Git for you, across all your objects, not one at a time. And it’s more thorough about it too: not just iFlows but whole packages tidily organized into its own folders. It’s not only CPI, either, API Management proxies are covered.
3. The pipeline validates your changes. Set up the pipeline process and Figaf wires into GitHub Actions to actually check your changed iFlows, running CPILint rules and unit tests, then writing the results back into the repo and surfacing them on the tracked object. There’s even Groovy script unit-test generation from recorded messages. So “CI/CD-ready” isn’t a slogan; there’s a working, opinionated pipeline.
The tradeoff, of course: Figaf is a separate tool you install and configure. There’s an agent, a bit more to understand, and more moving parts. It’s more powerful and more to run.
Wrapping up
These two aren’t really competing so much as they’re sitting at different points on the same journey. So whether you stop at the built-in buttons or go all the way to an automated pipeline, is entirely up to you and your needs. Still, the fact that we’re debating which Git workflow suits us best, instead of whether Git is even on the table, is a sign of progress.
