Ok, in this one I am going to do one simple trick: I am going to write the first part now, and then second one in ~6 months later after I will have finished my current project (s/4 private cloud implementation).
First part will be something of “product pitch” based on my naive understanding (these 2 months) of what is going on in cpi world in terms of dev tools and all that stuff.
The second one (lets call it “reality response“) probably will thrash most of those thoughts/ideas, but it could also be a good read to someone stumbling upon this series in some years to come (yes, one of those 10 persons reading it in 2030, I did it for you!)
Pitch part (March’25)
We will use very basic “pitch deck” format:
ProblemSolutionDemoMarket Development PotentialBusiness modelTeam / Advantage
Problem statement
Lack/absense of pro-code tools allowing local development / testing / debugging of iflows (camel routes)
In more details:
Having all artifacts in vcs (for paralel development, code review etc)And therefore being able to use other local dev tools for certain artifacts (xslt, groovy scripts etc)Being able to do local testing / debugging of iflows in local karaf instance (we need those jars for karaf published somewhere at tools.hana.ondemand.com)Being able to run automated tests (for iflows that are designed testable, of course)
Solution
Open-source tooling available free of charge, supported by both sap and community.
For now (based on problem definition) let’s assume that CI/CD is out of scope, but complete suite must definitely include this (seems like we currently miss that part anyway, while the same approach we use for cap ci/cd – simply running mbt in pipelines and then deploying mtars to CF – could probably work here as well).
Demo
Well, basically, this is why I did all those demo videos in my series.
But if I were to pick one, the last part would be my choice.
Just in case, let’s briefly mention features that were demoed:
setup of local karaf instance through ui (almost completely)manual sync (rezip) of locally stored artifacts to cpimanual sync to local git repo back from cpiui for manual adaptation of camel blueprints to run locally (this is a critical gap on our path to proper automated testing)ui for cpi endpoints testing (primitive http client)ui for local testing of iflows and remote replay of messages on cpi side
Market Development Potential
I mean, seriously, it’s sap cosmos.. One good – and especially free / opensource – tool dominates the market.
Then monetisation comes in forms of consulting and proper execution of projects utilising the tool.
Let’s instead focus on what could be added later into product:
Fully local development of iflows (theoretically, we just need that bpmn to camel translator they use)Proper BTP CI/CD that we already mentioned earlier (that can be used anywhere by anyone eg gitlab-ci)Monitoring of deployed stuff (need to check mpl and mpl api to maybe add it myself to capic)Cloud deployable and multi-user (for example, to have ui for Event mesh amqp/http client there)Usable by business users to produce test data (also maybe in cloud so that they don’t have to deal with local setup)Framework/guidelines for designing testable iflows (so that it is, well, you know, at least no that bad)
Business Model
Well, again, investing in such product would bring indirect return of investment in a form of competitive advantage – basically, it is selling quality to those who is willing to buy it.
Also if it saves time of your devs and they deal with less issues during the whole project lifecycle – your price can be lower (or margin is higher).
Team / Advantage
I put it into one bullet because as I said earlier, it felt to me that CAP java could be a really nice stack for such tool.
Therefore the advantage would be to develop something first using the right technology stack aligned with sap strategy, and also that fits well in Camel/Java pro-code world.
Therefore here I am referring to the team that would make this unfair advantage happen, consisting of couple of java devs (cap java and camel/osgi experienced) + maybe one fiori frontend guy (for proper ui5 development).
Product owner with knowledge of fiori ux + cap and java + osgi + camel is essential of course.
Basically, thats it.
And based on my experience, in like 6 months such team could deliver something really nice (I guess it took me around 100-150 hrs to develop current version, though I did not track all the time, especially weekends)
Call for feedback
If somehow you saw this blog before I wrote second half, please kindly provide some feedback regarding tooling you currently use and would love to use for CPI development.
Ok, in this one I am going to do one simple trick: I am going to write the first part now, and then second one in ~6 months later after I will have finished my current project (s/4 private cloud implementation).First part will be something of “product pitch” based on my naive understanding (these 2 months) of what is going on in cpi world in terms of dev tools and all that stuff.The second one (lets call it “reality response”) probably will thrash most of those thoughts/ideas, but it could also be a good read to someone stumbling upon this series in some years to come (yes, one of those 10 persons reading it in 2030, I did it for you!)Pitch part (March’25)We will use very basic “pitch deck” format:ProblemSolutionDemoMarket Development PotentialBusiness modelTeam / AdvantageProblem statementLack/absense of pro-code tools allowing local development / testing / debugging of iflows (camel routes)In more details:Having all artifacts in vcs (for paralel development, code review etc)And therefore being able to use other local dev tools for certain artifacts (xslt, groovy scripts etc)Being able to do local testing / debugging of iflows in local karaf instance (we need those jars for karaf published somewhere at tools.hana.ondemand.com)Being able to run automated tests (for iflows that are designed testable, of course)SolutionOpen-source tooling available free of charge, supported by both sap and community.For now (based on problem definition) let’s assume that CI/CD is out of scope, but complete suite must definitely include this (seems like we currently miss that part anyway, while the same approach we use for cap ci/cd – simply running mbt in pipelines and then deploying mtars to CF – could probably work here as well).DemoWell, basically, this is why I did all those demo videos in my series.But if I were to pick one, the last part would be my choice.Just in case, let’s briefly mention features that were demoed:setup of local karaf instance through ui (almost completely)manual sync (rezip) of locally stored artifacts to cpimanual sync to local git repo back from cpiui for manual adaptation of camel blueprints to run locally (this is a critical gap on our path to proper automated testing)ui for cpi endpoints testing (primitive http client)ui for local testing of iflows and remote replay of messages on cpi sideMarket Development PotentialI mean, seriously, it’s sap cosmos.. One good – and especially free / opensource – tool dominates the market.Then monetisation comes in forms of consulting and proper execution of projects utilising the tool.Let’s instead focus on what could be added later into product:Fully local development of iflows (theoretically, we just need that bpmn to camel translator they use)Proper BTP CI/CD that we already mentioned earlier (that can be used anywhere by anyone eg gitlab-ci)Monitoring of deployed stuff (need to check mpl and mpl api to maybe add it myself to capic)Cloud deployable and multi-user (for example, to have ui for Event mesh amqp/http client there)Usable by business users to produce test data (also maybe in cloud so that they don’t have to deal with local setup)Framework/guidelines for designing testable iflows (so that it is, well, you know, at least no that bad)Business ModelWell, again, investing in such product would bring indirect return of investment in a form of competitive advantage – basically, it is selling quality to those who is willing to buy it.Also if it saves time of your devs and they deal with less issues during the whole project lifecycle – your price can be lower (or margin is higher).Team / AdvantageI put it into one bullet because as I said earlier, it felt to me that CAP java could be a really nice stack for such tool.Therefore the advantage would be to develop something first using the right technology stack aligned with sap strategy, and also that fits well in Camel/Java pro-code world.Therefore here I am referring to the team that would make this unfair advantage happen, consisting of couple of java devs (cap java and camel/osgi experienced) + maybe one fiori frontend guy (for proper ui5 development).Product owner with knowledge of fiori ux + cap and java + osgi + camel is essential of course.Basically, thats it.And based on my experience, in like 6 months such team could deliver something really nice (I guess it took me around 100-150 hrs to develop current version, though I did not track all the time, especially weekends) Call for feedbackIf somehow you saw this blog before I wrote second half, please kindly provide some feedback regarding tooling you currently use and would love to use for CPI development. Read More Technology Blogs by Members articles
#SAP
#SAPTechnologyblog
