SAP Integration Suite : GitHub integration in SAP Cloud Integration

[kamlesh_zanje]

Introduction 

SAP Cloud Integration version 6.80/(8.x --> 8.44 ), one of the capabilities of SAP Integration Suite, comes with a feature which will allow you to integrate the GitHub to the integration suite to perform the basic GitHub operations on the design time integration artifacts. To know more, you can refer the help documentation.

In this blog post, you will understand the detailed aspects of this feature, Why, What, its objectives, principles and how to leverage in the Cloud integration capability of the integration suite.

Why GitHub integration is essential?

• No GitHub integration in the Integration Suite for collaborative development, track changes, storage, backup, or recovery.
• Users must manually download and upload artifacts in GitHub, causing media breakage.
• Manual process is slow, error-prone, and impacts version control, reducing productivity for effective collaborative developments.

What is GitHub Integration?

• Integrates Integration Suite with GitHub for secure repository connection, Git authentication, and operations directly in-app.
• Streamlines artifact management, reduces errors, enhances version control, and supports collaborative developments and CI/CD compatibility.

Benefits/Value proposition

• Collaboration: Streamlined teamwork via branches and pull requests
• Seamless Integration : No media breakage between Integration suite and GitHub
• Governance : Github repositories maintained in Integration suite via Tenant administrator
• DevOps: Enables CI/CD automation
• Backup: Secure storage for artifacts with easy recovery.
• Distributed: Work locally and sync changes.
• Rollback: Revert to previous versions quickly.
• Traceability: Track changes for auditing.
• Scalability: Supports large and distributed teams.
• Security: Protect artifacts with permissions and authentication.

Availability

GitHub integration in the integration suite for cloud integration capability is available in the trial, standard and above/higher editions.

How to leverage?

Let me explain the workflow and steps into two parts.

• How to Successfully Configure GitHub Repositories for Cloud Integration?
• How to successfully import/clone, push, Pull the integration artifacts from/to Github?

How to Successfully Configure GitHub Repositories for Cloud Integration?

To integrate GitHub repositories successfully, follow these easy steps:

Prerequisites:

1. Ensure your account has a Tenant Admin role (refer to Cloud Integration documentation if unsure).
2. Generate a Personal Access Token (PAT) with the required permissions for the repositories.

How to Create a Personal Access Token (PAT):

1. Log in to GitHub, go to Settings -- >  Developer Settings -- > Personal Access Tokens.
2. Choose Fine-Grained or Classic Tokens and click Generate New Token. Set an expiry for the token.

Simple Setup Steps:

1. In the Cloud Integration portal, navigate to Settings -- > Integrations -- > Git Access.
2. Click Edit in the Repository Details table and select Add to set up a new repository.
3. Enter your PAT and GitHub repository URL.
4. Click Connect to link the repository (Name and Description will auto-fill).
5. Click Add to save the repository details in the table.

Notes:

• You can integrate up to 50 repositories.
• Make sure to click Save after completing all configurations.

Follow these steps to configure your GitHub repositories for seamless Cloud Integration!

View Github Repostories

Add Github Repository

Edit Github Repository 

How to successfully import/clone, push, Pull the integration artifacts from/to Github?

• Git Import use case & experience 
• Git Push use case & experience
• Git Pull use case and experience

Git Import use case & experience 

Prerequisites:

• Ensure Git repositories are configured by the tenant admin.
• Have a Personal Access Token (PAT) with permission for the repositories.

Steps for Importing Integration Flows:

1. In the Design section, go to Integration Packages.
2. Select an integration package and click Edit.
3. Open the Artifacts tab and select Add Integration Flow.
4. Choose Add Integrations Manually (requires Premium plan).
5. Use Git Import to import the flow:
• Enter your PAT.
• Select a repository and branch.
• Choose the desired flow and click Add or Add and Open in Editor.

Outcome:
The flow is imported into the integration package, enabling Git operations like push and pull for collaboration and version control

Add Integration flow from Github repository, branch

Git Push use case & experience

Git Push lets you upload local changes from an integration artifact to a connected remote Git repository, ensuring your repository is fully updated for collaboration and version control.

Prerequisites Before Git Push:

• Configured Repository: Your admin should set up the necessary repositories (see Git Access guide for details).

• Access Permissions: Have the right permissions and a Personal Access Token (PAT) ready.

Steps to Push Changes:

1. Navigate to Integration Packages: Go to Design > Integrations and APIs to find the list of integration packages.

2. Select the Package: Choose the package with the artifact you want to push and click Artifacts.

3. Start Git Push: Click the ... (triple dot) icon on the artifact and select Git Push.

4. Fill in the Details:

• Add your PAT for authentication.

• Choose the repository name and branch.

5. Commit Message: Enter a clear message describing your changes.

6. Push Changes: Click Push to upload updates to the remote repository.

Key Notes:

• The repository will be updated with the latest version of your artifact.

• Ensure branch and repository details are correct to avoid errors or conflicts.

Git Push operation to push the local changes to the Github repository, branch

Git Pull use case and experience

Git Pull updates your local files by fetching and merging the latest changes from a remote Git repository, keeping everything in sync.

Before You Start

1. Ensure repositories are set up by the administrator (Check Git Access documentation).
2. Git Pull works only for imported artifacts.

Steps to Perform Git Pull

1. Open Integration Packages:
   Go to Design -- > Integrations and APIs to find integration packages.
2. Select a Package:
   Click on the package and then choose Artifacts to view its contents.
3. Use Git Pull:
   Find the artifact to update and click the Git Pull icon.
4. Verify Details:
   Confirm the displayed artifact info and enter your Personal Access Token (PAT).
5. Finish Up:
   Click Pull to update your local artifact with the latest changes.

This helps you easily keep your files updated for smooth collaboration.

Git Pull operation to pull the latest changes from the Github repository, branch

FAQs

1. Supported Integration Artifacts: Basic Git operations are supported for Integration Flows in the initial release.
2. Available Editions: GitHub integration is available in the Trial, Standard, and higher editions of the Integration Suite.
3. Repository Limit: You can add up to 50 GitHub repositories in the integration settings.
4. Impact of Removing Repositories: Removing repositories from the integration settings has no effect on integration flows—they remain in the design workspace and GitHub, if previously pushed. However, the integration flow will be de-linked from GitHub.
5. Supported Platforms: Only GitHub on the cloud is supported, on-premise GitHub is not supported.
6. Cloud Platform to be supported in future: GitLab and BitBucket, 
7. Authentication: GitHub operations are supported through PAT tokens only.
8. PAT Token Persistence: PAT tokens are not stored, you must manually provide one for each GitHub operation.
9. Repository Descriptions: Descriptions for GitHub repositories can be set during creation on GitHub and will be visible when imported into the Integration Suite.
10. Differentiate local and remote changes: Github repository name, branch name is tagged to the integration flow available in the remote branch. Integration flow is tagged in the design workspace and monitoring view(for deployed artifact).

What’s coming next?

• Introduce CRUD functionality for user Personal Access Tokens (PAT).
• Add support for more authentication types and cloud platforms like GitLab.
• Extend compatibility with on-premise GitHub repositories.
• Enhance Git operations like import, push, pull for the remaining integration artifacts.
• Implement conflict resolution tools (graphical/text editor) for integration artifacts and resources.
• Support multi-branch management for integration artifacts.
• Enable public OData Remote APIs for CI/CD processes.
• Expand Git support for integration packages.

Other source of material

• https://help.sap.com/docs/integration-suite/isuite-integrations-and-apis/git-access
• https://help.sap.com/docs/integration-suite/isuite-integrations-and-apis/git-push
• https://help.sap.com/docs/integration-suite/isuite-integrations-and-apis/git-pull
• https://help.sap.com/docs/integration-suite/isuite-integrations-and-apis/import-integration-flows-fr...

I hope you find the feature in this blog post beneficial. If you have any questions or feedback, please leave a comment.

[Yogananda]

@kamlesh_zanje - could you please mask internal sap github urls.

[NIGAMSA]

@Yogananda - Aha, good catch sir! 👍

@kamlesh_zanje - fya, there are a few more to mask in the screenshots.

[Saurabh-Kabra]

@kamlesh_zanje  Thanks! One question... Is there any plan to support other Git based platform like Bitbucket from atlassian? Or only GitHub is planned to be supported in the long term?
I already checked https://roadmaps.sap.com/board?PRODUCT=73554900100800003241&range=CURRENT-LAST&q=git#Q3%202026;INNO=... but din't find any thing on the roadmap 😔.

Thanks
Saurabh

[kamlesh_zanje]

Hello @Saurabh-Kabra  - We have a plan to support GitLab which is also widely used. Could you create an influence request to support Bitbucket? We shall also consider supporting Bitbucket if the requirement flows from good number of customers.

https://influence.sap.com/sap/ino/#/campaign/2282

[GiulioN]

Hi, is there a way to edit the branch after the push has been done?

Created

Branch : main | Repository : CPI_XXX

After doing this, is there a way to remove the Git integration? This way, you could change branches and add a new one.

Thanks

Giulio

[SebastianEsch]

Hi!

Why is only GitHub supported? Our customers use the whole range of available platforms. We use Bitbucket, but we also work with Azure DevOps and GitLab at different customers. I have created Influence Request https://influence.sap.com/sap/ino/#/idea/378829 for general Git support.

And why are only 50 repositories supported? In larger landscapes with one Repo per Integration Package, we will reach the limit quite soon.

And having to enter the PAT for every Git operation will drive developers mad quite quickly!

Kind regards,
Sebastian

[SebastianEsch]

Hi,

is there a way to associate a complete Integration Package with a Git Repository? And what about other artifacts than iFlows? At the moment we can only track parts of an integration package in Git and have to do it for each iFlow individually. This is not a usable development flow.

Kind regards,
Sebastian

[kamlesh_zanje]

@SebastianEsch  -  This is the first increment ! 

As mentioned, in the upcoming phases, we plan to support GitLab. Other platforms will be evaluated based on the customer pull. BitBucket will also be considered to support.

Remaining integration artifacts are in our radar as well. We will check and extend the limit beyond 50 repositories.

PAT token persistency, CRUD functionality for user Personal Access Tokens (PAT) to avoid user entering the PAT token is also part of the upcoming increments.

Your ask is covered in the what's coming next. Rest assured, it will be addressed one by one !

Regards, Kamlesh.

[kamlesh_zanje]

@GiulioN - We have a plan to support multi-branch management for the integration artifacts. However, as an alternatives, you can explore either of the options.

1. Push the integration flow let say in github repo, x branch from ISuite tenant and then from GitHub repo, x branch, transport the integration content to the y branch.

2. Create a new repo and push the integration flow in the branch of new repo.

3. User to remove the git repo from the ISuite tenant settings page which will un-link the integration flow from the repo, branch.  Add again the same repo in the settings page.. This time push the integration content in the new branch.

4. One more way is download the integration flow, delete the same, re-create the integration flow by uploading it and push to the new branch.

These are workarounds.  However, we will work on multi-branch management.

Regards, Kamlesh.

[SebastianEsch]

Option 3 would unlink all iFlows from the Repo. And you would have to add them all one by one manually again.

[shubham_relekar]

Hello @kamlesh_zanje / Experts

I noticed different behavior between SAP Business Application Studio (BAS) and SAP Integration Suite when using GitHub integration.

In BAS, GitHub correctly shows the actual user who commits the changes.
In Integration Suite, GitHub always shows the repository owner as the commit author, regardless of which user performed the commit.

Is this the expected behavior? Is there any way to have GitHub display the actual Integration Suite user as the commit author instead of the repository owner?

Thanks in advance!

[asutoshmaharana2326]

If this is meant to support collaborative development, it still needs two basics — tenants that can check out any branch, not just push/pull one, and an iFlow format (current .iflw file) stable enough that two people’s changes can actually merge. Right now it works more like a backup tool, mirroring the iFlow rather than enabling real version control. Transport mechanisms also don’t properly handle hotfixes — reconciling a hotfix with in-progress dev work in a proper DevOps flow isn’t something Git or TMS solves cleanly today.

[IKhurana]

Hello @kamlesh_zanje 
Thank you for the details, We meet again on this blog 🙂 (we had discussion on CEI session).

Could you please elaborate on branches too, how many can we create and their merging  into main branch?

Thanks,

Indu Khurana.

[HarshPatelV]

Great article! The step-by-step explanation of GitHub integration with SAP Cloud Integration is very clear and practical. This feature significantly improves collaboration, version control, and DevOps practices by eliminating manual artifact management. The configuration guide and benefits section make it easy for users to get started. Thanks for sharing this valuable walkthrough!

[kamlesh_zanje]

Thanks Harsh !

[kamlesh_zanje]

@IKhurana Best practise for branching differs from org to org.  Below is the guidance. 

Main/Master Branch - The primary branch containing production-ready code.

Feature/Dev Branch - A branch created for developing a new feature.

Release/Rel Branch - A branch used to prepare a new release.

Hotfix Branch - A branch for urgent production fixes.

[kamlesh_zanje]

@shubham_relekar  - We should see the footprints of the user in github who had performed the push/commit. Let me check with my team.

[kamlesh_zanje]

@asutoshmaharana2326  - This is the first release where the USP is the integration of the Github in IS without any media breakage.  Yes, two tenants are required if developers wants to work on the same iflow in a collaborative fashion. However, more features are in pipeline to leverage Github and other Git servers effectively from version control standapoint.

[kamlesh_zanje]

@SebastianEsch - Yes, its workaround to select the envisioned branch for push/commit., but it will come with effort.

However, there are plans in the upcoming phases to offer an option to unlink the branch at the integration flow/artifact level such that envisiond branch can be selected for push/commit. This will bring much better experience till we offer multi-branch management.

[kamlesh_zanje]

@shubham_relekar - I hope your user is using a dedicated pat token, not the shared. As per the Github recommendation, you should create a pat token for every user. It must not be shared. 

[IKhurana]

Hi @kamlesh_zanje 

Regarding the PAT,
1. As there are fine grained and classic, is there any recommendations on these two types?
2. Secondly, as you commented on ownership of PAT, are you suggesting that every user generate a fine grained/Classic token to perform GIT operations.
3. While connecting to Git hub enterprise account, must we connect with classic token with repo scope and wider access?
4. If each developer uses their own Fine-grained/recommended PAT, can those tokens be configured to access all required CPI repositories while still ensuring that all Git commits and Push/Pull operations are attributable to the individual user for audit purposes?
5. If a centrally managed PAT is used only for establishing the repository connection in CPI, but developers use their own PATs for Push/Pull operations, is this a supported and recommended configuration?

Thanks,
Indu.

[YashwanthM07]

Do we have this feature available in the trial account to test it out. I tried in the Trial account have assigned Tenant Admin role yet not able to add any directories as the button is disabled.