New License Option

Licensing is pretty difficult. It is one of the findings over the years as a software vendor. We have to change the model a few times after was have been adding much more functionality into the application. I really do understand why it is something that makes things complicated.

Rule number 1 in licensing: You will never find the optimal model

Rule number 2 in licensing: Customers will always have objections to the license terms and pricing or it is too cheap

The license should match the business case

The main criteria the license should in some way reflect the way the business case is able to find the money. So if the service is able to save 100 EUR pr employee, then the software should be licensed at 50-80 EUR pr employee. That will give some room for making an ROI and will mean the business will save 20-50 EUR pr employee. It is seldom that simple.

We are creating software that makes it a lot easier to run SAP PI/CPI and API mgt. We help automate the change management process so the value you are getting from the Figaf tool is in the following ways.

  • Each time you are doing a new development or a change on interface there is a cost associated with testing, documentation, and transportation. The Figaf tool help save you time here so it makes sense to license this factor
  • The other place where the tool will help is in the areas of upgrades that the Figaf tool will help make it easier to test the SAP PI/PO system after an upgrade
  • Automation of support with the Support tool. The Support tool is a part of the suite, making it easier to set up automatic monitoring of the solution.
  • Git integration enables users to expose CPI or API mgt repository to a Git project making it a lot easier to write and test unit tests in the code.

We have expanded the reach from just testing SAP PI to be able to support the full change management process for PI/PO, CPI and API mgt. We may add SAP Open Connectors if there is a request for it. So it makes sense to consider how we can make a good license model that will enable users to grow with the product.

Earlier we licensed the number of named users, the number of the system you connected and number of test cases. It leed to some strange offers for some clients where it really did not make a lot of sense. We needed to create a license with the specific system users could use the system on.

In the new option, we tried to make it more aligned with the business values we provide and easier to maintain. To enable it we have enabled a license server that record objects are licensed. Then we can use this information to validate the used amount. The information sent is just hash of system, interface, namespace and some statistical information like type of object like ICO/IFlow. That way we will not know what systems customers are using.

  1. The number of scenarios where the Figaf tool is used. This is an ICO, Iflow in CPI and a Proxy in API mgt. We will only license the base version in the development system that way it is only the places where Figaf tool helps that is counted. It also only count the Objects where you are using Figaf to manage, so all the objects that you do not want to use the tool which is not counted. You can also connect all different types of objects under the license. So both PI, CPI or API management can be used, so you can use the tool for all the platforms that matter.
  2. The number of tickets. In Figaf we have a concent called Ticket. A Ticket is a way to collect all the information required for solving a business request, like a Jira, ServiceNow or Solution Manager. The Ticket collects all the objects that are changed as a result of the test, the transports performed for it, the testing involved.

We then have three packages

Change Trackingx
Base Price EUR/Year€4,000.00€10,000.00€15,000.00

The one that makes most sense and where the Figaf tool is giving the most value is for the DevOps Package.

Both Testing and DevOps come with 100 Objects and DevOps comes with 100 Tickets/Year for that price. It is possible to buy an extra of both. There is a bigger discount for buying many objects.

Trial license

We have previously given a pretty wide scope for the trial license that we have, it was a community license. You could test with 10 ICOs, but it may have been able to give you too much access to use the product. With this online licensing server we also have to option to give 10 Integration Objects and 10 Tickets to trial users. You can get access to a trial license. See the email when you register.


We have added the option to help perform SAP PI/PO migrations. Here it is leveraging the same license way of licensing. Here we are counting the number of objects that you migrate to the development system in the new landscape. It will be a one time fee pr ICO that is migrated.

Try the Figaf Tool

You can signup and try the tool pretty easy. Just go to and try it out. It will take you around 30-60 minutes to get started on your laptop.

What is new in 2.11 new Transport for SAP PI/CPI

Over the last two months, we have written a lot about all the features that are in the coming release, and that it can automate the migration. To be able to auto migration we have added quite a number of new functions, which also makes the platform more useful for everyday usage. The biggest is to make governance much tighter integration with the transports.


One of the big things we needed to figure out was how to do transports. It is one of the areas where I do not think SAP PI/CPI is lacking modern change management. Sure CTS transports work but they don’t really give good visibility of what is transported.

Figaf can handle full transport no more need for CTS+. A number of our customers are not using CTS+ and therefore have not really been able to leverage a good way to do change management. So now you can just switch a flag on the landscape definition in Figaf Integration Tool and then be able to use Figaf to handle all your transports.

In the transport, we have now added an option to set up approval. So Architects can approve all transports before they can be imported.

Speaking of transports we have added two new options for the transport.

  1. Direct access to transport configuration from one view. So you can configure what hostnames should be in production. Once the transport has been approved it is not possible to change the configuration, otherwise, you will need to create a new transport.
  2. Virtual comparisons of change of what is change when applying the change. This makes it a lot easier to see what really will be changed when applying the patch.

We are considering how we can improve transport better. That there should be required testing on QA/Test system or secondary approval before transport can be imported to production. Only specific users can approve transports or they are imported at specific times.


Normally you will just develop single development and fix an interface at the time with a link to the service request. Other times you have a release or wave with some new interfaces that need to be applied on at special time and that contains a number of changes. Which this functionality it is possible to group and manage multiple tickets and interface at the mime.


See the video about how thise functions work together, making governance possible.

So now we are just waiting on our tests is working satisfying so we can create our release. There is still a number of regressions and flows that we need to optimize. We hope to release a beta of it soon.

Be the first to know

You can signup now and be one of the first to know when something changes.

Figaf Automatic Migration Demo

Over the last 2 months, we have been working on making full automation of the migration tool. It is probably the longest we have worked on a release. I had expected it would be a lot faster but once we got into the different areas we could see there process we could improve.

There are still a large number of customers how are still not on 7.5 for all their integrations. They will need to be using a lot of effort in migrating. We want to be able to save them time.

The migration is handled in waves/releases that each can contain a number of interfaces/ICOs. Once you have assigned an ICO to a migration task then it will guide you through the process. There is two processes and you will get tickets to handle them both in the Figaf Tool.

  1. Migrate the content from old Dev system to new Dev system
  2. Development to move from new Dev system to production.

What is the goal with the tool

The Figaf tool will handle all transports, testing, and configuration from an easy to use approach. Check the video below to see how smooth it works for the process of migrating 3 interfaces at once time.

There are still some gaps that we need to solve for the process to be maximumly automated, but we are moving towards it. It is a great leap compared to what existed earlier. It also gives a much better view of what you have migrated for each process.

Signup now to get access to the first release once we are ready.

Join webinar

We have a webinar on the October 24 to share and show more of what the tool can do. We hope that you will join us to learn more.

Sign up here.

Monitoring of SAP CPI

One challenge about making an application that runs well is to be able to monitor it with less effort. And being proactive about errors.

SAP CPI comes with some limited screens for monitoring what is processed and active alerting.

SAP is providing the OData API, so you can make your own monitoring application if you want more than the standard monitor. You can develop the monitor by a number of ways from Analytics Cloud to an SAP UI5 application. They will all work but it is some work you will need to do. You can also use Solman, though I’m not sure it will give much other information. There is also some more advanced monitoring tools from SAP Focused Run and a cloud version, but they will probably require a large investment and implementation.

That is why we have added it as part of the Figaf IRT application. It gives you three essential views:

  1. Active alerting if a message is not being processed correctly, then it will allow you to set up rules. A rule could be to notify a specific person or to restart the message. For the restart to work, you will need to include a script that saves payload as an attachment in case of errors.
  2. Monitoring for processes. The Figaf Monitor allows users to set up a group of iFlows to be viewed together. You can then give access to Finance interface for the Finance people, and they will not be able to see anything from HR. The view also gives a better overview of Sender, Receiver, Application ID from the Table view. This will allow you to find the correct message faster.
  3. System status page. We have a page that logs the status of the CPI system every 5 minutes. You then get a nice graph over how the system performs. It also has actions os if latency is above 500ms you can send an email.

Here is a list of screenshots to show that it is possible to monitor SAP CPI better without needing to code anything.

I have recorded a video of this you can see it here.

If you want to try it out you can get started for just 150 EUR/month for our cloud version of Figaf Tool. You can try it out for free.

Change Management can be simple

In the old-time, you had the SAP R3 ABAP system. There it was a pretty good tool to do change management. There was a limited number of objects that you could change and they could all be managed by one way of handling transports. In the new world, it is a lot more complicated.

Now the landscape is completely different. You have many different services that you need to find a way to manage. And if you start using SAP cloud solutions many of them have their own way of handling transports.

I have created a video to show, how I see the concept in some more details.

You have two options for Change Management: A generic approach or a specialized approach for your most important systems.

Generic Change management

No matter what you need to develop change, everything is handled in the same way. Then all developers know how to do change management for everything. It will speed up making it possible for other developers to handle the tooling.

The downside is that you will need to make a process that can encompass all systems. You will, therefore, get to little information or spend to much time creating the documents that you need for your project.

You may also miss an important part, and that is the ability to like changes both ways

Tool specific change management

If you have a lot of development or highly critical tools. It does make sense to have a better way to handle it.

When we are working on our Java application for the Figaf tool. We use Jira to create tickets in, Developers will then use this ticket number for all commits to a given ticket. Changes to our unit tests are also linked with the ticket. That is allowing us to trace all changes back to a ticket. That is a hyper-specialized tool to make change management for just one case. It can then be bundled with Jenkins to make build and test automation.

This type of specialization of your change management saves you time for your development. Because developers don’t need to note all the different places they are making modifications. It is handled automatically by the tool and captured as a part of the change.

Sure it will cost you more to buy or create an environment. It will cost both money, time and effort to get it working. Hopefully, this investment will be returned with better documentation, easier change management and faster delivery of code.

If you are using SAP Integrations products like SAP PI/PO, CPI or API mgt then we have a tool that will allow you to optimize your delivery process. Check the tools at there are even free versions that allow you to get started.

With our approach we will handle all the tool-specific requirements in our application and then let your original system containing all organizational data.

If you want to see how our tool works to make DevOps possible check this video