Git workflows and SAP Cloud Integration

[DG]

All SAP Integration Developers want easier processes for managing the SAP Integration. DevOps is the goal in other areas and can also be achieved with SAP Cloud Integration (CPI). You must be sure you will resolve several pitfalls before starting outlined here.

There is a cheat code. It is Figaf. It enables you to create a complete DevOps process in less than 2 hours that will cover the normal flow for most customers—saving you from the pain of building and designing it all for yourself.

Finding good SAP Integration Developers is difficult, so you must let them spend the time on what gives the most value. That is why the focus on building DevOps should be on letting them work faster and streamline the process from development to production in a controlled way.

DevOps and pipelines

You can build some good pipelines to handle SAP Cloud Integration. There are public APIs, Jenkins templates, project piper and tools like Flashpipe. It will enable you to build a process that suits your requirements. But there are no end-to-end templates you can use to cover all key steps of the DevOps process.

Before you start the implementation, have an idea about the challenges you need to resolve. Cloud Integration is a lot different than any other platform you are working with, so you cannot just apply the same level of git workflows. Do understand how you can resolve the following issues.

What is your motivation for using a Git workflow? That is an important question to answer. Is it because other teams uses Git, to make developers more productive or improve governance. You spend some time to figure out what your goal is before you get started.

Challenges

The challenges can be grouped into different areas that will be covered below.

Git workflow

1. It is not possible to keep all development locally, it is required to have CPI instance that will be shared for all developers.


2. Consequently, there are two sources of changes for git repository: CPI UI and local IDE (IntelliJ Idea, Eclipse, etc). CPI UI is the only place to efficiently update iFlow BPMN model or configure other business objects provided by CPI (like Message Mappings). At the same time, it is not efficient for the development and testing of Groovy scripts and function libraries if you have complex custom logic implemented there. It is better than to configure the local IDE and keep the development of Groovy/Java code in it.


3. All developers who make changes in repository must be familiar with the designed workflow process to avoid conflicts/data loss during development merging.


4. The requirement to have a user-friendly adapter to work with CPI Public/Web API efficiently to support all objects you will be using.


5. Some of the objects have dependency between them. You cannot deploy an iflow if the script collection is missing. You, therefore, need to make sure they are deployed, and it could require extra effort in the transport process.


6. IFlows should be configured differently in Development, QA and Production. If you do not have the configuration files in your repository then you will have manual work afterwards which could lead to slower changes.


7. The pipelines setup should be able to scale from few interfaces to 100s of objects without adding overhead to the process.


8. Transport pipeline is not enough for the full DevOps process, you will need to be using many different tools to ensure the coverage of what you want to achieve. It can be code review tools, testing, unit testing together with SAP transport tools and your ticketing system.


9. You should be able to monitor the status of the pipelines to ensure objects are processed and deployed correctly.

Governance  and change management

1. It should be possible to track changes to a specific story or bug so you have traceability.


2. It should be possible for an architect to approve the changes made. It is easy to check the code or XSLT. Checking changes in message mappings or iflows cannot really be done in a diff commands.


3. It should create documentation of the integration.


4. It should be possible for users to understand what is changed between two versions.

Testing the integration

1. For better coverage, you need to have both end-to-end testing of the whole iFlow and unit testing for its code part as a part of your delivery process. This will in most cases be manual.


2. You should have a way that enables developers to create and run test. Being able to trigger the iflows will allow them to understand how they work and ensure they do not break anything when applying fixes.


3. All test cases should be shared in an easy accessible repository that makes it easy for team members to run.


4. Test cases must be updated with IFlows when IFlows changes.


5. To test some iflows you will need to mock endpoints. It can be challenge to setup and maintain in your testing landscape.


6. It should be possible to do regression testing across the platform. Though it is cloud, it is a good idea to test all your integration regularly so you can see if any of the update created by your system is affecting your integration. You have one week to perform the testing in before the productive environment is updated.


7. Unit testing of Groovy scripts or function libraries. Some users would like to create unit tests for the Groovy/java code so they can ensure it is configured correctly.

Onboarding and rolling out

1. Many integration developers are not familiar with Git. So they may not be familiar with branches and merges and have a hard time working with tools in an expected way.


2. It should be easy to onboard new developers to the team so they would have access to the tools required for the platform.


3. With Cloud Integration/CPI development, you can just give users and S-user access to the CPI tenant, and then they can start developing. How easy can they get started with the git and the related workflows if it is relevant for them.

Better solution

It would be great if you could build a good solution with the input above!

If you think it sounds daunting. Figaf is a boxed solution tailored to make your SAP integration process faster both Cloud Integration, API management and SAP PI/PO. You can get started in 2 hours to set up the process so an Integration Developer can create changes in your integration, test, and move it to production with proper gates for approval and configuration. The focus has been on making the process as simple for users.

It will also allow your developers to be much more productive, reducing the effort for your migration.

Figaf and Git

Figaf supports Git integration, but it is not mandatory. There are several reasons to use Git integration in Figaf:

• Additional change management in the git repository. Figaf has integrated change management, but if you enable synchronization to git, it will create all packages, iFlows and other artifacts in a repository. It also automatically adds IFlow documentation to the git repository during synchronization.


• Mixed workflow when only a limited amount of Groovy/XSLT scripts are developed and debugged in local IDE. It is not required for all groovy/XSLT scripts, because Figaf has integrated Groovy Editor that provides syntax highlighting and an ability to run the script with the input from previously created test case and compare with the related output. For the remaining part, where local IDE is needed, Figaf provides Gradle plugins that will allow users to upload, download and deploy iFlows from local IDE. That approach minimizes the effort and speeds up the development process.


• Running pipelines to perform custom validation of your code like CPIlint, SonarQube or unit tests and use the result in the validation of transport.


• An ability to perform a full text search for other objects or use some criteria.


• If you want to have some integration with other platforms via git and use repository with CPI objects there

 

Cloud Integration with native Git

I have had a few discussions about how cloud integration could be integrated with Git. I don't think it is a silver bullet. That would be possible, and it could benefit the process, at least to the import to QA/Production, where a commit to a branch would trigger a deployment. It would also lock you into the selected git structure.

But Git on the development would cause a much bigger challenge. Here again, you get to have multiple versions of an iFlow deployed simultaneously and then the mix between code and WebUI.

Everything is possible, it just depends on how much resources should be place on this path.