Git workflows and SAP Cloud Integration

All SAP Integration Developers want to have easier processes for managing the SAP Integration. DevOps is the goal in other areas and it is also what can be achieved with SAP Cloud Integration (CPI). There are a number of pitfalls that you need to be sure you will resolve before you get started.

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.

It is difficult to find good SAP Integration Developers so you need to ensure you 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, 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 development and testing of Groovy scripts and function libraries, if you have complex custom logic implemented there. It is better then to configure local IDE and keep 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. 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 what changes were made 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 in a regular place so you can see if any of the update create 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

This is great if you can 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 much 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 usage of some criteria.
  • If you want to have some integration with other platforms via git and use repository with CPI objects there.

Try Figaf

No matter what you are trying to build and run. Give Figaf a try and see what you need to build. It will give you a good baseline for achieving your goals and understanding what is required.

It is pretty quick to get started and figure out what the tool can help with. Just sign up for a free trial today.  

Simplify your SAP Integration in under 10 minutes with Figaf DevOps Suite on Cloud.

 
No credit card is required. 30 days free trial.

Latest Articles