SAP Inside Track Belgium 2019
On the 18/05/2019 was the SAP Inside Track event in Belgium. It used to be called SIT Brussels, but it is in Antwerp now, so the old name makes no sense.
SIT Logo
I am doing a bit of a European tour this year, going to as many SIT events as I can, and volunteering to give a presentation where possible. Ten years ago there was one SIT a year, now there is more than one per week.
Thus far in 2019 I have been to SIT events in Maidenhead UK, and Walldorf (which is right next to where I live at the moment) where I did not speak, and Copenhagen and Belgium where I did speak. Next week it is Essen for “SIT RuhrPott” and then SIT Oslo in August and maybe Berlin as well. It is a hard life.
Getting back on track (to coin a phrase) the SIT Belgium event was very good indeed. There were a nice lot of people, maybe about seventy, but it says a lot about IT that apart from two women who worked for the host company there was only one female delegate present.
The theme of the event was “To ABAP or not to ABAP, that is the question” and there were enough speakers that there were two streams, one trying to be ABAP based, the other not.
I am an ABAP nerd, so I stayed in the ABAP room the whole day. What I did like is by accident or design the speeches tended to link into each other which gave a sort of coherent theme to the day. This is really not that surprising as I tried to find ways to link my speech to the one that went before me, and the guy who came after me managed to link parts of my speech to his, but if the talks had been on utterly different subjects that might have been quite a bit more difficult.
What follows are my notes on each speech I attended. As always I would say as a disclaimer I may well have forgotten important details, or misinterpreted the speaker, so if anything below gets your goat, blame me. I will probably spell all the speakers names wrong as well. I wrote them down off the slides, but my handwriting is so bad I cannot read it properly.
KEYNOTE – SAP CLOUD SDK – MARCO DAHS
You most likely will have heard of this product, though as it has had ten thousand different names during its very short life you may well have though there was more than one. SAP really have to stop doing this, though I do not suppose they will.
Anyway the Cloud SDK is all about extending SAP cloud solutions – obviously S/4HANA (no space between the 4 and “H” so I have been told) but also all the other companies that have been acquired such as Success Factors and the like.
This is the equivalent of adding “Z” code to an on-premise system, but here the extensions are in Java or JavaScript (more specifically Typescript which is a variant of JavaScript) and decoupled from the S/4 system.
More importantly their logo is in the shape of a rocket.
What I learned was that the SDK concept was extracted from an application that SAO built from scratch called REALSPEND. It must have been a pain, so the developers created a SDK to help themselves, and then someone released this could be a re-usable tool for all comers.
There are two halves to the SDK in whatever language. The first is the ability to generate Java or JavaScript classes based on the business object in the S/4 (or whatever) system, so you can work with them like proxies rather than having to manually code everything yourself, and the second is the “continuous integration / continuous development” pipeline that gets delivered with the SDK so you can run all sorts of tests (using Jenkins) to make sure everyone is working OK before your code actually gets deployed.
At the time of the event the JavaScript CD/CI pipeline was a work in progress, the Java one has been complete for some time.
The next point is the so called concept of “feature toggling” –this is a way to switch new features on and off for individual customers. You would not think you could do that that in a “multi-tenant cloud environment” but if you think about it you have to know which customer is which to make sure they do not see each other’s data. So a feature cannot be different for different consumers – because of the shared code base – but it can be active or inactive.
New versions of both the Java and JavaScript SDK’s are released every two weeks.
Naturally the presentation ended with questions, and the obvious ones came up – namely how does the SDK relate to the Cloud Application Programming Model and the Extension Factory. This question always makes people who work for SAP deeply uncomfortable. If you ask six different people you get six different answers.
I strongly suspect they were all developed totally independently of each other and then there was a desperate effort to make it look like it was all carefully planned and the three things work together in a seamless manner.
Now as it happens I know what the extension factory is, and it is nothing to do with extensions per se, though it can help you prepare the environment for extending cloud applications. Connecting the SAP Cloud platform to (say) an S/4HANA cloud system is a pretty long drawn out process consisting of many manual steps. Each step on its own is not too bad but there are a lot of them – about 62 as I recall.
So the extension factory could perhaps be better called a “connection factory” – it automates a large number of those manual steps. Obviously you need to connect to a cloud system if you are going to be extending it.
The relationship between the Cloud SDK and the CAPM is a bit more tricky. The answer given this time was that developing using the Cloud SDK requires a lot more technical knowledge than developing using the CAPM (you need to know about “Maven” and half a hundred other things like that which are very obscure to most people including me). Conversely I saw D.J. Adams give a demonstration where he whipped up an application using the CAPM in no time at all right in front of our eyes. The CAPM appeared to me to auto-generate pretty much everything that was needed. However as I understand it the CAPM can make use of artefacts developed using the Cloud SDK.
ME – THE FUTURE OF ABAP PROGRAMMING
Me Speaking
As in my last blog about SIT Copenhagen I am going to gloss over my own speech. After the last SIT of the year that I got to I will do a detailed blog. The talk keeps evolving anyway each time I give it – for example in between the Copenhagen and Belgium events a new version of ABAP was released (1905).
This time I tried to link to the talk before me by saying that if the Cloud SDK could extend S/4HANA using Java or JavaScript then ABAP in the Cloud could be described as “Cloud SDK ABAP” as it can also be used to extend S/4HANA. I don’t think anyone in SAP would describe it thus.
Furthermore the CDS concept in ABAP needs to be extended a bit more, otherwise it is not really comparable with the CDS equivalent in the CAPM. By the way the “M” in the CAPM is silent – you pronounce it “CAP”.
Suffice it to say I talk about Test Driven Development, abapGit and ABAP in the Cloud and the Restful ABAP programming Model (RAP) and how they all fit together.
LAURENS VAN RIJN – HITCHIKERS GUIDE TO THE LEGACY
He is a really good speaker. His talk about code comments at various SIT events last year was great. Like me he is doing an SIT tour around Europe, giving the same speech each time and improving it as he goes.
It says a lot about IT people that SIT Copenhagen was on Star Wars day (May 4th) and SIT Essen is going to be on “towel day” (May 25th).
As he will be giving this speech a few more times I am going to gloss over this as well for the moment but I can give you the general idea. The “linking” between speeches was still there as I talked about TDD and Unit Tests and so did Laurens to an extent.
In the same way that we now have “Clean ABAP” which is an adaptation of Robert Martin’s “Clean Code” book converted into ABAP concepts, Laurens was giving a talk where he took Michael Feathers “Working with Legacy Code” and converted the concepts into ABAP world.
It is just a question of taking weird phrases like “sprout and wrap” and explaining them in a way an ABAP programmer can understand. You really have to know something about OO programming though or you will struggle a lot.
In case you were wondering “sprout” is where you write all your new code in a separate class that gets called from the existing code (I am doing that right now at work) and “wrap” is where you create a new class that “wraps” an existing one and adds some new functionality and then the application calls the wrapper class instead of the original one. Somewhat similar to the “Decorator Pattern”.
Anyway when I realised what was happening I sat bolt upright like I had got an electric shock. The reason being I had actually talked to Michael Feathers on the phone some years back. He had been provisionally hire to give his course to a bank in Australia which had got to the point where their code was so brittle it fell to bits every time they changed anything.
That is just the situation his book (and live curses) addresses. The problem was he had never even heard of ABAP and the bank used SAP. So the consultant arranging the deal for the bank looked on the internet and found my blogs about unit testing, and indeed could not find any other ABAP person even thinking about such a strange concept so he asked if I would be willing to work with Michael Feathers and redo his examples in ABAP.
I sent him (MF) the chapter of my book about unit testing and TDD and he told me that at least I understood tests, which does not sound like high praise, but it was to me.
Sadly the bank got cold feet and decided the idea was far too radical, so nothing ever happened which was a great pity, both for me (I would have loved working with Michael Feathers) and indeed for the bank.
Anyway I had got as far as creating a two page document outlining the general procedure for approaching legacy code as outlined in the book, and gave some possible ABAP examples for each step. Looking back at it now I would change a lot, but anyway I forwarded it as-is to Laurens in the hope he might find something useful to enhance his speech next week.
Maybe at the end of it all (SIT European tour) we can put a “Working with Legacy ABAP Code” document on GitHub in the same way that the “Clean ABAP” document is there now.
TUDOR RISCUTIA – DOMAIN DRIVEN DESIGN
Take the Blue Pill, Neo
There is a pattern forming here. Once again we have a generic concept – Domain Driven Design – which has been used extensively in other languages but not particularly in ABAP thus far.
So Tudor was explaining the concepts and giving examples in ABAP (as far as was possible).
The overarching concept is that for a programmer business (domain) logic is far more important than knowledge of any given programming languages. Programming languages come and go, but the business stays the same. Thus at my company in Australia we make sure all the IT people go to the “coal face” (concrete pants and quarries and the call centre) as often as possible, to see how the business works and how it uses the software we create and maintain.
Unlike the last few areas mentioned there is not one central book that talks about this but the main DDD book is by Eric Evans.
https://en.wikipedia.org/wiki/Domain-driven_design
This talks about an “onion architecture” sometimes called “hexagonal architecture” where the domain model sits in the middle. In the below diagram layers only know about the layer below them and have no knowledge of any layers above them. Thus the domain model has no idea how it is going to be used, which is as it should be.
Onion Architecture
https://www.codeguru.com/csharp/csharp/cs_misc/designtechniques/understanding-onion-architecture.htm...
Once again the aim of the game was to take the various concepts in DDD and see if an ABAP equivalent could be coded. As it turns out that was not very easy at all, as ABAP is a data based language (even in its OO persona) and DDD is a behaviour based concept.
The first concept is a “value object”. This contains values which are immutable once they have been created. That is fairly easy to achieve in ABAP though it has to be said that public read only attributes are not really immutable as the values can be changed within the class, which is not the case in some other languages.
The next concept is an “entity” – the attribute values of an entity do not matter, what defines an entity is continuity of existence. A monster is an entity for example, even if it a shape shifting monster whose height and weight and number of heads keep changing. That is such an obvious example I don’t know why it is not mentioned more often. I bet that example is not in the text books on this subject. Anyway the “entity” concept is covered in ABAP. BOPF thinks in those terms, as does the RAP, and indeed the CAPM. We love acronyms (WLA).
The next concept is a “service” which is none of the above i.e. not a value object or an entity, but works with one or both, calculating values or whatever. In ODATA terms I suppose this is a “function import” though I could be wrong.
Lastly we have an “event” which is raised by an entity or whatever and does not care who receives it. You would think that would be fairly easy in ABAP (Classes or instances of classes can raise events) but apparently the ABAP event concept does not really match the DDD event concept.
One proposed way to square the circle was to use “ABAP Daemons” as event handlers which I am told is a much closer match. If so then that would be the first unequivocal use case I have come across for that technology.
As an aside ABAP is evolving to become more and more like a functional programming language, which is great. My Christmas lst is to have ABAP get built in support for design by contract, and if there is something missing which prevents a proper DDD implementation then maybe that should be added as well.
CHRISTIAN DRUMM – HUNTING FOR ZOMBIES
I like monsters for my example, Christian likes using zombies, specifically the zombies from “The Walking Dead”. One of his zombie types was called “monster” so it all fits together quite well.
The purpose of the presentation – and live demo – was to show how to use the workflow and business rules services in the cloud to enable a zombie killing application.
The first trip was to the “SAP API Hub”. Christian said this could be overwhelming at first, and how right he is. I am sure it is possible to get used to it eventually.
To test the workflow he used “Postman” which, as I understand it, always knocks twice.
I am very familiar with both SAP business workflow, and BRF+ and so was very interested to see what the cloud counterparts looked like.
The workflow in the cloud seemed very similar to what I am used to inside R3. The two main differences is that what I call the “VISIO” screen where you have boxes linked together to form the steps looked a bit better in the cloud (it could not be more ugly than the R3 one, after all) and the R3 one was more form based and the cloud one more text based e.g. when configuring the YES/NO decision box in the cloud version you have to input a lot of text, so much that Christian had to cut and paste the value in the interests of time.
There is a special sort of step in the cloud workflow which seems to me to correspond to the “binding” concept in the R3 workflow. Then instead of calling a “task” the workflow calls a “service” which sounds much more cloud like.
As far as I can see the cloud platform business rules look exactly the same as BRF+ and can be consumed by the workflow in the same manner that BRF+ rules can be consumed by an R3 workflow.
I always quiet liked the various logs in the R3 workflow. The cloud one does not look as good at first glance – the steps are in one part of the screen, the “container” equivalent with the data in another.
Christian decided to see if he could call the cloud workflow from ABAP. It took him 2 hours to create the cloud workflow in the first place, and then a week to work out how to invoke it from an ABAP system. To my eyes the resulting ABAP code to call the workflow looked to be about 100 lines or so.
It could be argued that you could have a UI5 application which started a workflow within R3 (or S4) which used BRF+ and sent the result to another UI5 application, and yes of course that would be easier, but that is not really the point. The point was to demonstrate the cloud equivalents, and kill some zombies as well.
WRAP-UP
The most important thing to mention was that everyone who attended got a free bottle of beer. Not just any beer but DIGIT-ALE transformation, which had its alcohol percentage written in binary i.e. 111% and was inspired by design drinking and had been thoroughly unit tested.
There was also a raffle and using a high technology EXCEL spreadsheet people were picked randomly from the list of attendees and the winners could pick from a list of books bought specially to give away.
Points make prizes
I could not help but notice that the first two winners picked my book as their prize and then the next ones had to settle for SAP HANA XSA. Clearly a spaceship beats a train any day of the week, even if the spaceship is full of monsters.
Anyway to sum up, SIT Belgium was fantastic. If you ever have a chance to go to a future event in Belgium – or indeed any SIT anywhere in the world – jump at it. You will not regret it.
Cheersy Cheers
Paul
On the 18/05/2019 was the SAP Inside Track event in Belgium. It used to be called SIT Brussels, but it is in Antwerp now, so the old name makes no sense.
SIT Logo
I am doing a bit of a European tour this year, going to as many SIT events as I can, and volunteering to give a presentation where possible. Ten years ago there was one SIT a year, now there is more than one per week.
Thus far in 2019 I have been to SIT events in Maidenhead UK, and Walldorf (which is right next to where I live at the moment) where I did not speak, and Copenhagen and Belgium where I did speak. Next week it is Essen for “SIT RuhrPott” and then SIT Oslo in August and maybe Berlin as well. It is a hard life.
Getting back on track (to coin a phrase) the SIT Belgium event was very good indeed. There were a nice lot of people, maybe about seventy, but it says a lot about IT that apart from two women who worked for the host company there was only one female delegate present.
The theme of the event was “To ABAP or not to ABAP, that is the question” and there were enough speakers that there were two streams, one trying to be ABAP based, the other not.
I am an ABAP nerd, so I stayed in the ABAP room the whole day. What I did like is by accident or design the speeches tended to link into each other which gave a sort of coherent theme to the day. This is really not that surprising as I tried to find ways to link my speech to the one that went before me, and the guy who came after me managed to link parts of my speech to his, but if the talks had been on utterly different subjects that might have been quite a bit more difficult.
What follows are my notes on each speech I attended. As always I would say as a disclaimer I may well have forgotten important details, or misinterpreted the speaker, so if anything below gets your goat, blame me. I will probably spell all the speakers names wrong as well. I wrote them down off the slides, but my handwriting is so bad I cannot read it properly.
KEYNOTE – SAP CLOUD SDK – MARCO DAHS
You most likely will have heard of this product, though as it has had ten thousand different names during its very short life you may well have though there was more than one. SAP really have to stop doing this, though I do not suppose they will.
Anyway the Cloud SDK is all about extending SAP cloud solutions – obviously S/4HANA (no space between the 4 and “H” so I have been told) but also all the other companies that have been acquired such as Success Factors and the like.
This is the equivalent of adding “Z” code to an on-premise system, but here the extensions are in Java or JavaScript (more specifically Typescript which is a variant of JavaScript) and decoupled from the S/4 system.
More importantly their logo is in the shape of a rocket.
What I learned was that the SDK concept was extracted from an application that SAO built from scratch called REALSPEND. It must have been a pain, so the developers created a SDK to help themselves, and then someone released this could be a re-usable tool for all comers.
There are two halves to the SDK in whatever language. The first is the ability to generate Java or JavaScript classes based on the business object in the S/4 (or whatever) system, so you can work with them like proxies rather than having to manually code everything yourself, and the second is the “continuous integration / continuous development” pipeline that gets delivered with the SDK so you can run all sorts of tests (using Jenkins) to make sure everyone is working OK before your code actually gets deployed.
At the time of the event the JavaScript CD/CI pipeline was a work in progress, the Java one has been complete for some time.
The next point is the so called concept of “feature toggling” –this is a way to switch new features on and off for individual customers. You would not think you could do that that in a “multi-tenant cloud environment” but if you think about it you have to know which customer is which to make sure they do not see each other’s data. So a feature cannot be different for different consumers – because of the shared code base – but it can be active or inactive.
New versions of both the Java and JavaScript SDK’s are released every two weeks.
Naturally the presentation ended with questions, and the obvious ones came up – namely how does the SDK relate to the Cloud Application Programming Model and the Extension Factory. This question always makes people who work for SAP deeply uncomfortable. If you ask six different people you get six different answers.
I strongly suspect they were all developed totally independently of each other and then there was a desperate effort to make it look like it was all carefully planned and the three things work together in a seamless manner.
Now as it happens I know what the extension factory is, and it is nothing to do with extensions per se, though it can help you prepare the environment for extending cloud applications. Connecting the SAP Cloud platform to (say) an S/4HANA cloud system is a pretty long drawn out process consisting of many manual steps. Each step on its own is not too bad but there are a lot of them – about 62 as I recall.
So the extension factory could perhaps be better called a “connection factory” – it automates a large number of those manual steps. Obviously you need to connect to a cloud system if you are going to be extending it.
The relationship between the Cloud SDK and the CAPM is a bit more tricky. The answer given this time was that developing using the Cloud SDK requires a lot more technical knowledge than developing using the CAPM (you need to know about “Maven” and half a hundred other things like that which are very obscure to most people including me). Conversely I saw D.J. Adams give a demonstration where he whipped up an application using the CAPM in no time at all right in front of our eyes. The CAPM appeared to me to auto-generate pretty much everything that was needed. However as I understand it the CAPM can make use of artefacts developed using the Cloud SDK.
ME – THE FUTURE OF ABAP PROGRAMMING
Me Speaking
As in my last blog about SIT Copenhagen I am going to gloss over my own speech. After the last SIT of the year that I got to I will do a detailed blog. The talk keeps evolving anyway each time I give it – for example in between the Copenhagen and Belgium events a new version of ABAP was released (1905).
This time I tried to link to the talk before me by saying that if the Cloud SDK could extend S/4HANA using Java or JavaScript then ABAP in the Cloud could be described as “Cloud SDK ABAP” as it can also be used to extend S/4HANA. I don’t think anyone in SAP would describe it thus.
Furthermore the CDS concept in ABAP needs to be extended a bit more, otherwise it is not really comparable with the CDS equivalent in the CAPM. By the way the “M” in the CAPM is silent – you pronounce it “CAP”.
Suffice it to say I talk about Test Driven Development, abapGit and ABAP in the Cloud and the Restful ABAP programming Model (RAP) and how they all fit together.
LAURENS VAN RIJN – HITCHIKERS GUIDE TO THE LEGACY
He is a really good speaker. His talk about code comments at various SIT events last year was great. Like me he is doing an SIT tour around Europe, giving the same speech each time and improving it as he goes.
It says a lot about IT people that SIT Copenhagen was on Star Wars day (May 4th) and SIT Essen is going to be on “towel day” (May 25th).
As he will be giving this speech a few more times I am going to gloss over this as well for the moment but I can give you the general idea. The “linking” between speeches was still there as I talked about TDD and Unit Tests and so did Laurens to an extent.
In the same way that we now have “Clean ABAP” which is an adaptation of Robert Martin’s “Clean Code” book converted into ABAP concepts, Laurens was giving a talk where he took Michael Feathers “Working with Legacy Code” and converted the concepts into ABAP world.
It is just a question of taking weird phrases like “sprout and wrap” and explaining them in a way an ABAP programmer can understand. You really have to know something about OO programming though or you will struggle a lot.
In case you were wondering “sprout” is where you write all your new code in a separate class that gets called from the existing code (I am doing that right now at work) and “wrap” is where you create a new class that “wraps” an existing one and adds some new functionality and then the application calls the wrapper class instead of the original one. Somewhat similar to the “Decorator Pattern”.
Anyway when I realised what was happening I sat bolt upright like I had got an electric shock. The reason being I had actually talked to Michael Feathers on the phone some years back. He had been provisionally hire to give his course to a bank in Australia which had got to the point where their code was so brittle it fell to bits every time they changed anything.
That is just the situation his book (and live curses) addresses. The problem was he had never even heard of ABAP and the bank used SAP. So the consultant arranging the deal for the bank looked on the internet and found my blogs about unit testing, and indeed could not find any other ABAP person even thinking about such a strange concept so he asked if I would be willing to work with Michael Feathers and redo his examples in ABAP.
I sent him (MF) the chapter of my book about unit testing and TDD and he told me that at least I understood tests, which does not sound like high praise, but it was to me.
Sadly the bank got cold feet and decided the idea was far too radical, so nothing ever happened which was a great pity, both for me (I would have loved working with Michael Feathers) and indeed for the bank.
Anyway I had got as far as creating a two page document outlining the general procedure for approaching legacy code as outlined in the book, and gave some possible ABAP examples for each step. Looking back at it now I would change a lot, but anyway I forwarded it as-is to Laurens in the hope he might find something useful to enhance his speech next week.
Maybe at the end of it all (SIT European tour) we can put a “Working with Legacy ABAP Code” document on GitHub in the same way that the “Clean ABAP” document is there now.
TUDOR RISCUTIA – DOMAIN DRIVEN DESIGN
Take the Blue Pill, Neo
There is a pattern forming here. Once again we have a generic concept – Domain Driven Design – which has been used extensively in other languages but not particularly in ABAP thus far.
So Tudor was explaining the concepts and giving examples in ABAP (as far as was possible).
The overarching concept is that for a programmer business (domain) logic is far more important than knowledge of any given programming languages. Programming languages come and go, but the business stays the same. Thus at my company in Australia we make sure all the IT people go to the “coal face” (concrete pants and quarries and the call centre) as often as possible, to see how the business works and how it uses the software we create and maintain.
Unlike the last few areas mentioned there is not one central book that talks about this but the main DDD book is by Eric Evans.
https://en.wikipedia.org/wiki/Domain-driven_design
This talks about an “onion architecture” sometimes called “hexagonal architecture” where the domain model sits in the middle. In the below diagram layers only know about the layer below them and have no knowledge of any layers above them. Thus the domain model has no idea how it is going to be used, which is as it should be.
Onion Architecture
https://www.codeguru.com/csharp/csharp/cs_misc/designtechniques/understanding-onion-architecture.htm...
Once again the aim of the game was to take the various concepts in DDD and see if an ABAP equivalent could be coded. As it turns out that was not very easy at all, as ABAP is a data based language (even in its OO persona) and DDD is a behaviour based concept.
The first concept is a “value object”. This contains values which are immutable once they have been created. That is fairly easy to achieve in ABAP though it has to be said that public read only attributes are not really immutable as the values can be changed within the class, which is not the case in some other languages.
The next concept is an “entity” – the attribute values of an entity do not matter, what defines an entity is continuity of existence. A monster is an entity for example, even if it a shape shifting monster whose height and weight and number of heads keep changing. That is such an obvious example I don’t know why it is not mentioned more often. I bet that example is not in the text books on this subject. Anyway the “entity” concept is covered in ABAP. BOPF thinks in those terms, as does the RAP, and indeed the CAPM. We love acronyms (WLA).
The next concept is a “service” which is none of the above i.e. not a value object or an entity, but works with one or both, calculating values or whatever. In ODATA terms I suppose this is a “function import” though I could be wrong.
Lastly we have an “event” which is raised by an entity or whatever and does not care who receives it. You would think that would be fairly easy in ABAP (Classes or instances of classes can raise events) but apparently the ABAP event concept does not really match the DDD event concept.
One proposed way to square the circle was to use “ABAP Daemons” as event handlers which I am told is a much closer match. If so then that would be the first unequivocal use case I have come across for that technology.
As an aside ABAP is evolving to become more and more like a functional programming language, which is great. My Christmas lst is to have ABAP get built in support for design by contract, and if there is something missing which prevents a proper DDD implementation then maybe that should be added as well.
CHRISTIAN DRUMM – HUNTING FOR ZOMBIES
I like monsters for my example, Christian likes using zombies, specifically the zombies from “The Walking Dead”. One of his zombie types was called “monster” so it all fits together quite well.
The purpose of the presentation – and live demo – was to show how to use the workflow and business rules services in the cloud to enable a zombie killing application.
The first trip was to the “SAP API Hub”. Christian said this could be overwhelming at first, and how right he is. I am sure it is possible to get used to it eventually.
To test the workflow he used “Postman” which, as I understand it, always knocks twice.
I am very familiar with both SAP business workflow, and BRF+ and so was very interested to see what the cloud counterparts looked like.
The workflow in the cloud seemed very similar to what I am used to inside R3. The two main differences is that what I call the “VISIO” screen where you have boxes linked together to form the steps looked a bit better in the cloud (it could not be more ugly than the R3 one, after all) and the R3 one was more form based and the cloud one more text based e.g. when configuring the YES/NO decision box in the cloud version you have to input a lot of text, so much that Christian had to cut and paste the value in the interests of time.
There is a special sort of step in the cloud workflow which seems to me to correspond to the “binding” concept in the R3 workflow. Then instead of calling a “task” the workflow calls a “service” which sounds much more cloud like.
As far as I can see the cloud platform business rules look exactly the same as BRF+ and can be consumed by the workflow in the same manner that BRF+ rules can be consumed by an R3 workflow.
I always quiet liked the various logs in the R3 workflow. The cloud one does not look as good at first glance – the steps are in one part of the screen, the “container” equivalent with the data in another.
Christian decided to see if he could call the cloud workflow from ABAP. It took him 2 hours to create the cloud workflow in the first place, and then a week to work out how to invoke it from an ABAP system. To my eyes the resulting ABAP code to call the workflow looked to be about 100 lines or so.
It could be argued that you could have a UI5 application which started a workflow within R3 (or S4) which used BRF+ and sent the result to another UI5 application, and yes of course that would be easier, but that is not really the point. The point was to demonstrate the cloud equivalents, and kill some zombies as well.
WRAP-UP
The most important thing to mention was that everyone who attended got a free bottle of beer. Not just any beer but DIGIT-ALE transformation, which had its alcohol percentage written in binary i.e. 111% and was inspired by design drinking and had been thoroughly unit tested.
There was also a raffle and using a high technology EXCEL spreadsheet people were picked randomly from the list of attendees and the winners could pick from a list of books bought specially to give away.
Points make prizes
I could not help but notice that the first two winners picked my book as their prize and then the next ones had to settle for SAP HANA XSA. Clearly a spaceship beats a train any day of the week, even if the spaceship is full of monsters.
Anyway to sum up, SIT Belgium was fantastic. If you ever have a chance to go to a future event in Belgium – or indeed any SIT anywhere in the world – jump at it. You will not regret it.
Cheersy Cheers
Paul
- SAP Managed Tags:
