Day: December 27, 2017

Ambassador is a Kubernetes-native API gateway for microservices built on the Envoy Proxy. Ambassador is designed for self-service. Developers should be able to manage basic aspects of Ambassador without requiring operations. Ambassador accomplishes this by enabling developers to configure it through Kubernetes annotations. This allows developers to easily manage Ambassador using their existing Kubernetes deployment workflow.

In this tutorial, we’ll do a quick tour of Ambassador with a demo configuration before walking through how to deploy Ambassador in Kubernetes with a custom configuration. https://goo.gl/nuSsL6 #DataIntegration #ML

SAP get enterprise software. They understand things like having a rock solid technical platform, scalability, 24×7 operations, multi-language, etc. They highly value backwards compatibility too because they understand their customers want to be able to upgrade without  having to make wholesale changes – or even any changes – to their custom code.

Arguably one of the great technical achievements of the ABAP application server is that it remains backwards compatible. ABAP code that was written for R/2 more than 30 years ago can potentially still run on S/4HANA. That is pretty amazing.

It is also a huge load of baggage that SAP need to carry around with them as they enhance the ABAP application server to support contemporary development paradigms and techniques. As they add support for things like the Internet Communication Framework and Object Oriented programming they have to still support things like TABLES parameters, internal tables WITH HEADER LINE, CHANGING parameters, etc. Whilst we all know we should only develop new code using contemporary syntax we also know we can use deprecated ABAP as a “Get Out of Jail Free Card” whenever we need it – and we do.

It may well be the that over the years some deprecated features of ABAP have actually been removed – but I can’t recall a single one.

The typical SAP Customer has a lot of custom code in their system of varying quality and use. Lots and lots and lots. Much of it is probably never even used as it has been replaced by new code over time but the old code has never been deleted – just in case. Similarly customers have been reluctant to upgrade more than once or twice every five years – creating a long tail of SAP releases that SAP have to maintain support for across decades. I know customers still running R/3 4.6B – I have been told of some on 3.1H and earlier.

SAP are now being very clear that they want to change this pattern. They now want you to build all custom code outside your S/4HANA system – no matter if it is the on-premise or cloud version. They want you to resist the urge to pollute (my word not theirs) your SAP applications with your own code. Instead they want you to build custom code in another system – their preference is the SAP Cloud Platform – and have it call standard API’s to integrate with the your SAP applications.

This is key to allowing you to upgrade your S/4HANA system more readily so that you can adopt the latest versions – and associated innovations – soon after they are released confident they won’t break the existing code. It is also key to customers choosing the cloud version of S/4HANA rather than the on-premise version – once those pesky API’s are available.

But what about ongoing support for the platform we use to build these so-called “extensions” on? In other words the SAP Cloud Platform. What is SAP’s plan for supporting it?

In our familiar ABAP world support for our custom code was pretty much guaranteed due to this backwards compatibility characteristic. But that becomes a bit more problematic when cloud technology can change very significantly in short periods of time and new technologies have no obligation – or interest – in supporting old technologies. In fact their main purpose is to provide an alternative to those older technologies.

Take the SAP Cloud Platform. It started with Neo. Plenty of applications, extensions, etc. have been built on and now run on the SAP Cloud Platform Neo stack. Recently SAP have started to direct developers towards their Cloud Foundry stack on SCP. We are now being encouraged to build our apps and extensions on CF. Neo you are dead to me.

At SAP TechEd this year SAP announced they had joined the Cloud Native Computing Foundation the controlling body behind Kubernetes – the open source project that acts as an orchestration layer for containers. And – as Dick Hirsch describes so well in this blog – SAP already have significant capabilities and experience building and running “containerised” applications.

Does this mean Cloud Foundry will soon be dead to me too?

All the signs are that “Serverless Computing” will be the next significant change to how we construct and run applications. And what will come next? Does this mean that Containers will become dead to me too?

Of course not. It is clearly a case of choosing the most appropriate technology for the workload at hand – just as it always has been. That might be Cloud Foundry, containerisation, FaaS, or something else. Remember also that one runtime technology can be provisioned inside another. Nothing is necessarily mutually exclusive. (Neo, I probably still think you are dead to me.)

I can see that SAP will now need to rethink how they define and position ongoing support for SCP and how they articulate this to their customers.

Backwards compatibility meant that supporting the current ABAP release also implied supporting the ability to execute all my old custom code. But there is, for example, a clear distinction between the SCP Neo and Cloud Foundry runtimes – as there will be for containerised and FaaS runtimes too. As we move to building our code for CF we still want our Neo code to keep running and the Neo-based platform to continue to be available. Maybe for a very long time.

In the consumer world cloud providers might be able to simply remove/change/enhance their services and cop any backlash on the chin. Not so in the enterprise world where – to quote the late Les Hayman – “Organisations bet their future on SAP“.

SAP get enterprise software – so I think we can be confident they get this issue as well. http://bit.ly/2C7Nt6h #SAP #SAPCloud #AI

Introduction

CPI Keystore Monitor allows a tenant administrator to manage the tenant keystore and its entries. A keystore contains entries uniquely identified by an alias where each entry has its own lifecycle. Renewal of an entry is important task to be done before expiry, else it will lead to message failure for productive scenarios using specific certificates/key-pairs entries. The tenant administrator can be notified for those entries which are about to expire, so that he can take in-time actions for renewal of the same.

Within keystore monitor, expired keys and certificates are highlighted showing expiration date. In addition, an Integration Flow can be modeled to get notifications via mail for entries reaching their expiry. This document provides steps to model a scenario triggered via scheduler which looks across all entries of the tenant keystore and sends a mail with information about those entries reaching their expiry.

Scenario Description

Cloud Integration provides various REST APIs with technical protocol as Open Data Protocol (OData) with which you can access data. These APIs can be consumed via https:///api/v1 where is the address of the tenant management node. Here we will use API for accessing keystore entries via https:///api/v1/KeystoreEntries .Overall scenario looks as below:

Create an integration flow with Start Timer Event. Using Request-Reply step call OData APIs to fetch details of the tenant keystore entries via OData receiver channel. Fetch Alias Name and ValidNotAfter for entity KeystoreEntries. Below find the configuration of OData Receiver channel:

Make sure the Page Size field value is null since entries in a keystore are not so many in numbers.

The response of the OData call will be a file containing all keystore entries with their Alias & Validity date. Now add a General Splitter step to split using XPath /KeystoreEntries/KeystoreEntry and pass split entries to a Local Integration Process.

In Local Integration Process, define a Content Modifier and store the values of keystore entry Alias and Validity Time in a header.

Additionally, add a message containing Alias & Validity Time information about keystore entry in body of Content Modifier. This message will be send via mail notification. You can choose to customize this information as per your need.

Now add a script to fetch Validity Time from header and compare with current date. Output of script shall be number of days left for Keystore entry to expire. You can find a sample code below:

     def map = message.getHeaders();

     String getCertExpirydate = map.get(“CertExpiryDate”);

     Date CertExpirydate = new SimpleDateFormat(“yyyy-MM-dd“).parse(getCertExpirydate);

     Date dateNow = new Date(System.currentTimeMillis());

     long dateDiff = CertExpirydate.getTime() – dateNow.getTime();

     def daysToExpire = TimeUnit.DAYS.convert(dateDiff, TimeUnit.MILLISECONDS);

     message.setHeader(“daysToExpire”, daysToExpire);

Add a router step to route those entries whose expiry is in less than defined number of days (e.g. daysToExpire