DevOps is tricky for SAP companies. It rhymes with something not well enough governed for an enterprise world for some, but really it doesn’t have to be.
We at Gekkobrain believe that DevOps done with the right tools will bring your developers much closer to the software they wrote and increase the collaboration between your functional experts and the programming team.
And as we are committed to helping you then we just wanted to tell you that we have released a new version of our Gekkobrain for SAP DevOps tool.
It’s Software as a Service. So, if you are already a customer then its already done. For the rest of you we’ll make room for you too….
It was a bug, Dave….
HAL 9000 is unable to understand the concept of lying and it makes him paranoid in the AI science fiction movie of my generation.
Paranoia is not a wise strategy if you want solve a problem quickly and thoroughly, and in many ways, transparency (and not being transparent is what made HAL go crazy) is the best way to stay focused on the real problem.
And why have a chain of control processes if they are really not reacting to a problem, but rather trying to slow the development process down enough to get as many people as possible to evaluate the code going to production.
Wouldn’t it be better to let a tool, that looks at the code from all corners, knows everything about all the programs the new program calls out to and knows if they themselves are responsible for instability, make that decision?
We developed our tool to provide that security for your CAB board. If the new code passes all the checks, calls to code that also passes all the checks and runs fast in production and your code is not located in a business process which you weren’t aware of because it would have meant too much where-used analysis for your developer, then you should be good to go. And with your permission we even do that check as part of our auto-import plugin.
When problems do occur, we’re also here to help.
So lets consider 3 scenarios and how Gekkobrain helps you:
First example:
Are the dumps you’re having, for example an overflow in a field, something that happens frequently to the IDOC interface you have developed or is it exotic?
We monitor patterns for your system dumps. We tell you how frequently they occur and we compare that with the versions of your code. You can see that the problem is persistent in certain cases where a great number of records are read in a previous step. You find out that the number of records are IDOC control records and it doesn’t take long for you to look at the dumping ABAP to realize that this happens because the number of segments are higher than usual for a particular sending partner.
Another example:
It seems that you have a specific report which is being used more and more, but it’s already now a long-runner. And the reason for this seems to be that it joins 2 tables wrongly.
We monitor the SQL performance of all your programs and we monitor all the transactions you perform. The trigger for a piece of code, batch, webservice, dialog, RFC etc. You’ll need this information along with the duration of the report to understand that timeouts only happen when the report is run in batch and never in dialog. And the fix you will create needs to cater for a scenario where you need to check for batch process in a custom class you recently added in which a lot of data is compiled.
A third example:
Your retail stores are using a stock lookup web service and that service is using a standard BAPI function module inside a loop and that causes a series of select single on large MM stock tables and furthermore it reads a lot of pricing condition tables which always return 0 records. You can see that there are no dumps but the web service times out well before the price is found.
It seems you haven’t been informed that the code you wrote for a monthly stock valuation report has recently been added to the web service which didn’t have prices. The prices are not changing that often (in fact they only change twice a year) and the store would rather suffer slightly wrong prices (the 0 record is for special promotional discounts) than a very poorly performing stock checker across stores. But looking at the SQL monitoring data you realise that the usage data has changed and the call stack tells you the new usage pattern which makes it easy for you to refactor the code.
This is why Gekkobrain monitors your system and alerts you of problems already in development. And should it happen that a program starts to develop problems in production, it finds the developer who made the program and alerts him about it. Even if another developer should do the fix, it makes for quicker fixes if the original developer evaluates the error.
Remember: It’s not the same a pulling nightshift after your dayshift. Gekkobrain does that for you. But it does save you a ton of time looking for someone who knows what might be wrong.
Reliability Reimagined
For those of you that know our thoughts on DevOps, we don’t think the change will come if the tools are wrong.
And while culture and the right mindset is really important, then having information about the code from production which will make you solve the issue quickly is the key.
It will also help you write the right test cases and it will assist you in structuring your new development in a proper way.
We have designed the solution in our DevOps tool in such a way that someone is always responsible for providing a fix.
It boils down to this:
Gekkobrain DevOps for SAP never lets a failing piece of code out of its sight.
If something starts performing badly Gekkobrain will let you know and not be satisfied before you have fixed it.
Such a service really isn’t fit for humans. It can only be done by an AI. And that’s why we made one for you.
Want to learn more about Gekkobrain’s software?
Just fill in the form below, and we will contact you within 24 hours.