SAP Community - SAP BTP, Kyma runtime

Why I love SAP and Blockchain Databases and why you should too 🚀

2024-03-06T10:07:44.299000+01:00

I am going to be writing a lot of blogs about two of my loves, SAP technology and Blockchain technology, and this is the first one, so buckle up, it's going to be an exciting ride, and there is so much to discuss it's going to be a marathon rather than a sprint.

We've got so much to talk about in this space, this blog is going to discuss the why and the how:

. Why Blockchain Databases or Distributed Ledger Technology Databases are so useful for SAP Customers

and

. UseCases, how Blockchain can solve existing challenges and enable re-imagining of business processes

and

. How Blockchain and SAP is no longer just a dream, just a hype, but how you can start doing Blockchain and SAP today solve old challenges with new(er) technology

A lot has been written about Blockchain and Blockchain Databases, in the SAP Community there is a very nice explanation which I recommend you to read.

In 2019, Gartner wrote to CIO's and said, "CIOs should begin to embrace blockchain to explore strategic business initiatives, but avoid falling for the hype", that's 5 years ago, and the point is, back then, as I know from first hand experience, as a SAP Customer, if you wanted to "do" Blockchain, it was complicated, even just trying to play with the technology was like a University Project. And here's the thing, fast forward 5 years to 2024, and now, within the SAP Partner Edge Open EcoSystem there are enabling technology Blockchain Products designed and built by SAP Experts specifically for the needs of SAP Customers to make doing Blockchain and SAP easy, and so today, you can do SAP and Blockchain, it's no longer hype, today it's real and there's nothing stopping you.

McKinsey & Company, in their December 2023 Featured Insights Publication, gave a beautiful description of what is unique and special about Blockchain, "Blockchain is a secure database shared across a network of participants, where up-to-date information is available to all participants at the same time". If we just pause for a moment and let that sink in, and think about what that means, to Business Processes, to Collaboration, to System Resilience, we start to see what is so special about Blockchain Databases and Distributed Ledger Technology.

Let's begin with the first deliverable of the Blog, Why I love SAP and Blockchain Databases and why you should too, and:

Why Blockchain Databases or Distributed Ledger Technology Databases are so useful for SAP Customers

As a 25 year career veteran of SAP Technology, [15 years SAP Basis and 10 years SAP Tech Arch including Tech, Integration, Security, Data from 3.1H to S/4HANA PCE on RISE and the BTP and everything in between, and former SCN Moderator and Mentor alumni], some of the biggest challenges which I've spent a greater part of my career solving for SAP Customers are:

. Protecting the Integrity and Originality and Confidentiality of SAP Data - making sure that only the people and system who need to see it can see it in the Business Processes [here's a Blog I wrote in 2013]

. Protecting the Availability and Resilience of SAP Data and SAP Systems for Business Processes

. Protecting the Movement of SAP Data across Business Process which include SAP and 3rd Party Systems

. Protecting SAP Data which is Shared in collaborative Business Processes

To do all of this in the world we had prior to Blockchain Databases, required layers and layers of technologies, often from different Vendors, and combinations of automation and human centric processes.

To do all of the above items needed amongst other things:

. Multiple Installations of SAP Systems and Databases

. Clustering and Replication Software running between

. Job Scheduling Software

. Multiple layers of Security

Additional Encryption of Data when it is stored (at rest)

Additional Encryption of Data on the move (in transit)

Key Store Management and Rotation

House Keeping

. Monitoring & Logging

. Different Security and Resilience approaches and tools for the different

So we had to take the out of the box products and we had to build security and resilience on top of them with even more products and human centric processes.

And here's the thing, guess what, Blockchain Databases, Distributed Ledger Technology Databases have all of that built in ! How cool is that ?

Really... how does it work ?

Blockchain Distributed Ledger Technology has four special characteristics:

What is a Blockchain atkrypto.io

Let's think of a Blockchain Database as a Database Server Software. And let's think of the Blockchain Ledger as a Database Table.

If you install two or more Instances of the Blockchain Database Software and connect those two Instances together, you have a Blockchain Database Network, or a Distributed Ledger Network. In Blockchain Architecture this is considered as Layer 0, the Blockchain Network.

Blockchain is a very simple form of database atkrypto.io

The Four Layers of Blockchain Architecture:

The four layers of Blockchain Architecture atkrypto.io

Let's go through the characteristics of the Blockchain and why they are so special.

The Blockchain Hash Mechanism

Every row [Block-Data] in the ledger contains a unique Hash identity [This-Block-Hash]

Every row in the ledger contains the Hash of the previous row [Previous-Block-Hash]

The Hashes tie the Blocks together in a Chain and this is what makes the Chain of Blocks [Blockchain]

This weaves the rows of data together into an impenetrable sequence [as shown below]

The Blocks tied together as Chain make it very hard for hackers to insert new data into the Blockchain

The Blockchain Hash Mechanism atkrypto.io

The Blockchain Is Decentralised / Distributed

Blockchain Software must be installed on more than one Server (Node) in more than one place

This is what makes the Blockchain Decentralised and Distributed

Consequently the Blockchain has built in resilience and high availability and disaster recovery

To hack and attack the Blockchain you would have to destroy every Server where it is running

Blockchain Decentralised Distributed atkrypto.io

The Blockchain Is Immutable

Data in the Blockchain cannot be modified or deleted because it is immutable by design

This makes it difficult for malicious actors to modify or delete the data

A malicious actor would have to hack the Blockchain on every Server to modify the data

The Blockchain is Immutable atkrypto.io

The Blockchain Concensus Mechanism

To add a new row of data to the Blockchain, a majority of the Blockchain Servers in the Blockchain have to agree (concede) that the data can be added to the chain – this is known as the Concensus Mechanism

Getting concensus among Blockchain Servers makes it extremely difficult for Hackers to maliciously attack the Blockchain because to attack the Blockchain the Hacker will need to be trusted by a majority of the Blockchain Servers in the Blockchain

The Blockchain Consensus Mechanism atkrypto.io

And this is why, and this is the key here, the key difference between Blockchain Databases and the previous generation of Databases, Blockchain Databases, natively, out of the box, have a level of security and availability resilience built in which is not there in the previous generation of databases.

With the Blockchain Database you have the High Availability and Disaster Recovery built in, you have your Business Continuity Plan built in, and not only because of the availability resilience but also because of the immutability of the data.

This is why Blockchain Database Technology is so exciting for SAP Customers, we can get rid of layers of security hardening and have all of these layers taken care of natively out of the box in one product.

And we can do it today, it is no longer just hype, there are products in the SAP Partner Edge Open EcoSystem which can enable SAP Customers to do Blockchain and leveraging their existing investments in the SAP BTP, and running Blockchain in the SAP BTP on the SAP BTP Kyma Runtime.

Let's pause and take a breath, have a cup of tea or a cup of coffee, and then let's move to next objective of this blog...

UseCases, how Blockchain can solve existing challenges and enable re-imagining of business processes

There are loads and loads of use cases for Blockchain, and people have been writing for years about the Enterprise Blockchain use cases and benefits. a quick search on google will lead you to years of articles about the benefits of Blockchain and the use cases.

What I am going to do here is list a few of them as headlines across the dimensions of Securing the Integrity and Originality of Data, enabling Data Sharing and Orchestration and Multi-Party Collaboration, and Resilience and Business Continuity, and in the subsequent Blogs I will deep dive into the use cases and Technologies both from SAP and from SAP Partner Edge OpenEcoSystem partners which you can already leverage today to implement these solutions and do these use cases in your Enterprises.

Enterprise Blockchain Use Cases for Protecting/Security the Integrity and Originality and Confidentiality of Data:

. Track and Trace across all Industries and Business Processes, Single Party & Multi Party

. Finance & Insurance Business Processes, Single Party & Multi Party

. ESG - proving that what happened did happen and the evidence cannot be manipulated

Enterprise Blockchain Use Cases for Data Sharing and Orchestration and Multi-Party Collaboration:

This is a really interesting one for the Blockchain, this is where McKinsey & Company, in their December 2023 Featured Insights Publication, really nailed it with, "Blockchain is a secure database shared across a network of participants, where up-to-date information is available to all participants at the same time".

Just think about that. Think about how Blockchain could be used as an irrefutable common store of data, across your Enterprise, or across Enterprises.

Imagine running Blockchain on SAP Edge Lifecycle Management, or between the SAP Integration Cell and instances SAP BTP CI.

We all know, as the number of parties involved in a transaction goes up, so the trust in the transaction goes down.

Just think about how in Business Process and Business Scenarios where the same data is shared between multiple Teams in your Enterprise, or multi Enterprises in a Business Transaction or Process, just think about how the Blockchain and its special native out of the box characteristics will enable everybody to trust the information they are sharing and working with.

And then think about how Blockchain could be used to orchestrate data, to communicate data, to share data.

Imagine you have to give an instruction to a third party and you want to be the most certain that you can be that nobody with bad intentions can manipulate the instruction... you set up a Blockchain between you and your Partner and you write the data to the Blockchain and let the Partner read the data from the Blockchain.

Blockchain Muiti Party Collaboration atkrypto.io

Enterprise Blockchain Use Cases for Resilience and Business Continuity:

This one is a really interesting Blockchain Use Case. All of the SAP Technical Architects out there take note, Blockchain can today, using Blockchain products within the SAP Partner Edge Open EcoSystem solve your BCP challenges.

In all of our Enterprises we have the Business Continuity Plan.

The Business Continuity Plan leverages technologies to ensure that in the event of a BCP situation the Business can continue to operate to some extent.

To be able to operate most Businesses to some extent, there needs to be Data, certain core Master and Transactional Data to enable the Business to keep running.

As SAP Technical Architects our job is to design Technical Solutions which will enable the BCP scenario.

The basis requirements for the BCP scenario are:

. Store the core Data somewhere where it will be available for a BCP scenario

. Make sure that the core Data cannot be modified, make sure we can trust the core Data

And this again is where the Blockchain shows its beauty. Thanks to the dimensions and characteristics of the Blockchain which were described above, it's Immutable, tick that box for BCP, it's Distributed and Decentralised, tick that box for BCP, all we have to do as SAP Technical Architects is set up a Blockchain and write the most important BCP data to the Blockchain. We could set up a Blockchain Server on the SAP BTP Kyma RunTime Service in three continents in three SAP BTP Regions, connect that Blockchain to our S/4HANA, write the data to the Blockchain, and voila, we have our BCP.

Blockchain for BCP Business Continuity Planning atkrypto.io

If you've got this far, good job, now we are on to the last section which will be a shorter one 🙂

How Blockchain and SAP is no longer just a dream, just a hype, but how you can start doing Blockchain and SAP today solve old challenges with new(er) technology

I've been interested in Blockchain for the Enterprise since about 2018. As a career SAP Basis and SAP Technical Architect, when I started looking at Blockchain, I wanted to play with it, and I wanted to set one up, connect it to our R/3's and the, back then, new S/4HANA, and see what we could do with it. My expectation was that it would be like, download the software, self extract it, run it, do a few configurations and then integrate it and bring data in to it. All of the Blockchains for Enterprise which I looked at back then were extremely complicated, it was like a University Project to try to figure out all of the pieces of the puzzle that were needed to get it running.

6 years later, times have changed, the Blockchain technology is on its journey and maturing, and now, there are Blockchain products which SAP Customers can implement today, and which are coming from the SAP Partner Edge Open EcoSystem partners and are designed for the needs of SAP Customers and to leverage existing SAP investments and run on SAP BTP Kyma Runtime and consequently natively integrate with SAP data sources, S/4HANA and the SAP Cloud Products and integrating through the common SAP integration channels, SAP CI, SAP APIM, SAP AEM etc.

So what are we all waiting for ?

Ok, that's the end of this blog. This blog is the first of many, you will be seeing a lot more SAP and Blockchain blogs coming from me, explaining how implement the Blockchain software within your SAP investment and talking about all of the SAP Enterprise Blockchain use cases and business cases.

What do you think, are the words Blockchain, Web3, Distributed Ledger Technology, starting to appear in your Company's visions and technology visions ? What use cases are you looking at ? Let's chat about it in the comments.

For today, over and out. 🚀

Andy Silvey.

Independent SAP Technical Architect and CEO of atkrypto.io

Author Bio:

Andy Silvey is a 25 years SAP Technology veteran [15 years SAP Basis and 10 years SAP Tech Arch including Tech, Integration, Security, Data from 3.1H to S/4HANA PCE on RISE and the BTP and everything in between, and former SCN Moderator and Mentor alumni].

Andy is also co-Founder of atkrypto inc, an startup whose ambition is to make Blockchain easy for Enterprise.

atkrypto.io's flagship product is the atkrypto Enterprise Blockchain Platform for SAP, and atkrypto.io is a SAP Partner Edge Open EcoSystem Partner.

The atkrypto Enterprise Blockchain Platform for SAP has been designed by SAP Independent Experts for the needs of SAP Customers and to be deployed on the SAP BTP Kyma Runtime Service and leverage native integration to SAP Products.

atkrypto Enterprise Blockchain Platform for SAP has a number of unique qualities, including being the only Blockchain software in the world which has a DataCenter version and a light mobile version which can run on Edge/IoT/Mobile devices and enables data to be written to the Blockchain at the Edge where that same Blockchain is running on a Server in the DataCenter, protecting the integrity and originality of data from the Edge to Insights. Taking Blockchain to the Data at the Edge instead of taking the Data to the Blockchain.

SAP Enterprise Architecture: Positioning Blockchain Database as an Enterprise Technology Standard 🚀

2024-03-08T19:19:41.200000+01:00

This blog, which follows on from the previous one in the series, "Why I love SAP and Blockchain Databases and why you should too 🚀", will deliver an approach to positioning Blockchain Technology as a Technology Standard in our Companies.

The goal of the previous blog in this series was to get us thinking about Blockchain Databases in our Companies, in the Enterprise, and the goal of this blog is to get us thinking about how to position an Enterprise Blockchain Platform as a Technology Standard in our SAP Enterprise Architecture.

Why do we need to do this ? Why does Blockchain need to be a Technology Standard within the Enterprise Architecture in our Companies ?

In our SAP Enterprise Architecture we use Technology Standards as a way of framing where we use what software applications and why, what is the purpose of that software application.

So for each Technology that we have in the house, we have a box which describes what that Technology and do, what it's strengths are, and therefore where we should use it.

This all sounds very formal, but in our personal lives we do this at home every day. We possibly have more than one pair of shoes, perhaps one pair for going to the office and one pair for going running. I don't really want to get in to a debate about how many pairs of shoes people have and which ones they use for what but I imagine that you get the point.

Some shoes are more suited to different activities than others. Some have a hard sole some have a soft sole. These are capabilities of the shoe, soft sole leans towards capability for sport, thanks to this soft sole capability the shoe is more appropriate to be used for, to be applied to sport, You get the point.

And it's the same with software, some software is more suited to different activities than others, these are capabilities. And by keeping a list of what software we have in the company and what the capabilities of the software are, and where the software is encouraged to be used, helps to ensure that in our SAP Enterprise Architecture decision making processes we more consistently use the different types of software that we have for the purposes in which they are intended based upon what they can do.

To be more formal, there is a very nice description of Technology Standards here, 'At the most basic level, technology standards establish boundaries for technology usage, specifying technology to be used (acceptable use) and restricting access to technology that is deemed "non-standard"'.

If we agree that to be able to consistently, repeatedly use Enterprise Blockchain Databases in our Companies we need to classify where we should use the Enterprise Blockchain Databases and why, then the first step is to write down all of the things that Enterprise Blockchain Databases is good for, what it can do, where it is strong, what the capabilities are.

Capabilities means what is it good for what is it good at ? What can it do ? Let's try to group the capabilities together where it makes sense. The most important capabilities and enablers of Enterprise Blockchain Databases and on a wider scale the Enterprise Blockchain Platforms, from the high level view, revolve around Data across the dimensions of:

Security / Privacy

Availability / Resilience

Collaboration / Sharing

Orchestration

Web3 / Tokenization / Wallet / SDK / Smart Contracts

Mobility / Edge

Integrations / Connectivity / Blockchain Bridges and Bridging

Types of Blockchain

Artificial Intelligence

Let's go through these capabilities one by one and think of all of the words we can around the dimension and picture what it actually means.

Enterprise Blockchain Database Capability - Security & Privacy

Capability/Enabler: Secure, Immutable, Trust, Cannot be modified, Tamperproof, Protect, Safe, Proof, Auditable, Confidentiality, Integrity, Originality, Transparency, Privacy

Why are Blockchain Databases so strong in this: As we discussed in the previous Blog in this series, Blockchain Databases have four special characteristics that make them a Blockchain Database, and those are, Immutable, Hash Mechanism, Distributed/Decentralised, Consensus Mechanism.

Regarding the Security & Privacy capability, it is the Immutable and Hash Mechanism and Consensus Mechanism which make the Blockchain Database so natively security hardened out of the box and in fact security hardened natively out of the box to a level which most conventional databases are not.

In terms of the NIST CIA Triad for Data Security, Criticality, Integrity, Availability, Enterprise Blockchain Databases comes in Very High across all three classifications.

Blockchain Security SAP NIST Triad atkrypto.io

Enterprise Blockchain Database Capability - Availability & Resilience

Capability/Enabler: Resilience, Distributed Multi Region, Distributed, Decentralised, Network Database, High Availability, Disaster Recovery, Business Continuity Planning

Why are Blockchain Databases so strong in this: Again, as we discussed in the previous Blog in this series, Blockchain Databases have four special characteristics that make them a Blockchain Database, and those are, Immutable, Hash Mechanism, Distributed/Decentralised, Consensus Mechanism.

Regarding the Availability & Resilience capability, it is the Distributed & Decentralised characteristics which make the Blockchain Database so natively resilient out of the box and in fact resilient natively out of the box to a level which most conventional databases are not.

An Enterprise Blockchain Database is a Network Database. When one of the Servers is down, the other Servers are up, A Server can go down and when it comes back up it will automatically synchronise with the rest of the Enterprise Blockchain Database Network. This is really suited to Business Continuity Planning.

Blockchain for BCP Business Continuity Planning atkrypto.io

Enterprise Blockchain Database Capability - Collaboration / Sharing

Capability/Enabler: Single Source of Truth, Shared Single Source of Truth, Multi-Party Collaboration, 3rd Party Collaboration, Common Store of Data, Sharing, Collaboration, Master Data Store, Distributed Data, Network Database, Track and Trace, Traceability, Audit, Auditability

Regarding the Collaboration / Sharing capability, it is the Distributed & Decentralised characteristics which make the Blockchain Database so natively supporting Collaboration / Sharing out of the box and in fact supporting Collaboration / Sharing natively out of the box to a level which most conventional databases do not and can not, without additonal Clustering and Networking software.

An Enterprise Blockchain Database is a Network Database. This means the Database is running active on multiple Servers in multiple locations. As was described in the previous blog, McKinsey & Company, in their December 2023 Featured Insights Publication, gave a beautiful description of what is unique and special about Blockchain, "Blockchain is a secure database shared across a network of participants, where up-to-date information is available to all participants at the same time".

And this is what is so important and so special. When we install the Blockchain Database Server in two different Company's DataCenters (or as Blockchain as a Service in the Cloud) and establish a Database Ledger on the Servers we enable the two Company's to share Master and Transactional Data while knowing that neither can modify the Data which has been shared. This is really suited to sharing Data across the Enterprise or across Enterprises.

Blockchain as a Shared Single Source of Truth atkrypto.io

Enterprise Blockchain Database Capability - Orchestration

Capability/Enabler: Data Orchestration, Data Integration, Network Database, Instructions Communication, Data Delivery, Sending Data, Data Transfer, Data Connection

Regarding the Data Orchestration, it is again the Distributed & Decentralised characteristics which make the Blockchain Database so natively supporting Data Orchestration out of the box and in fact supporting Data Orchestration natively out of the box to a level which most conventional databases do not and can not, without additonal Clustering and Networking software and all of the extra effort that that brings. An Enterprise Blockchain Database is a Network Database.

This means the Database is running active on multiple Servers in multiple locations. As was described in the previous blog, McKinsey & Company, in their December 2023 Featured Insights Publication, gave a beautiful description of what is unique and special about Blockchain, "Blockchain is a secure database shared across a network of participants, where up-to-date information is available to all participants at the same time". And this is what is so important and so special.

When we install the Blockchain Database Server in two different locations / DataCenters (or as Blockchain as a Service in the Cloud) and establish a Blockchain Database Ledger on the two or more locations' Servers we enable a situation where one Datacenter can put data onto the Blockchain, which is in fact an instruction for an action from an Application which is reading from the Blockchain in the other Datacenter. What this leads to is Data Integration at a level which is not possible with End to End Encryption and Encryption of Data at Rest alone.

Today Companies send Data to each other, with Blockchain Companies will write to and read from the same Blockchain Database Table. This is really suited to Orchestrating Data across the Enterprise or across Enterprises. In the following example we see how instructions to a Third Party Logistics company can be orchestrated across the Enterprise Blockchain running between the two companies.

SAP Master Data Integration and Orchestration with Blockchain atkrypto.io

Enterprise Blockchain Database Capability - Web3 / Tokenization / Wallet / SDK / Smart Contracts

Capability/Enabler: Web3 Foundation, Digital Asset Tokenization, Digital Wallet, Software Development Kit, Smart Contracts, Business Logic, Extension, Programming, Customisation

Tokenization is a combination of all of the Blockchain characteristics in one. Tokenization is the action of creating a Block on the Blockchain which is a Digital Token. The Digital Token is the digital representation of the information which has been stored on to the Blockchain.

With Tokenization comes a Wallet to store the Tokens in, it can be argued that the Wallet is not a classic capability of the Blockchain, but rather a capability of the Blockchain Platform.

A Software Development Kit is also not a classical characteristic or capability of the Blockchain, but rather a capability of the Enterprise Blockchain Platform. The SDK enables Developers to develop Decentralized Applications which run on top of the Blockchain.

And Web3 is the culmination or the whole of all of these capabilities and some more. The capabilities listed here go a long way to making up the core foundation of Web3. There is a nice overview of Web3 here in the SAP Community, including the following drawing:

Enterprise Blockchain Database Capability - Mobility / Edge

Capability/Enabler: Mobile, Mobility, Edge, IoT, Wireless, Move, Industry 4.0, Smart Everything, Connected Everything

The Distributed/Decentralised characteristic of the Blockchain Database Technology is what is so special here. As discussed above the Distributed characteristic of the Blockchain enables us to have a database which is networked between two locations.

It's this network database, and another fact which make Blockchain Databases so interesting for Edge/IoT/Mobile.

The other fact is the anologue to digital transformation of Things and the network getting closer to the Things at the Edge.

In the past Data was pretty much centralised to the DataCenter.

Things like Thermometers (in Pharmaceutical and Food Production), Maps & Compasses in Delivery Vehicles, Instructions on Paper, Locks on Doors, Photographs and Video, all of these Things were analogue. And now, all of these Things are going through a digital transformation, in two aspects, they are able to create digital representation of facts, and they are connected to the Network, and in some cases they even have larger computational power and can do business/processing logic and therefore are Smart Things. Thermometers are now connected to the Network, same for Maps and Compasses in Delivery Vehicles (GPS Location and navigation), Paper based Instructions are now electronic, Locks on Doors are now electronically monitored and controlled from the Network, Photographs and Video are now digital and connected to the network. And all of things Things are connected to the Network,the Edge of the Network, because they are the final point of the Network and together they make up the Internet of Things.

And so all of these Things are producing Data at the Edge of the Network. And this is where Blockchain comes in, Blockchain, for all of the reasons above is natively out of the box the most security hardened and resilient Database for protecting the integrity and confidentiality and originality of Data from the Edge.

The Capability and Enabler, Mobile / Edge / IoT comes in to play regarding having a Enterprise Blockchain Platform Server Node as close to the Edge as there is computational power, eg, on the Device, in the Connected Vehicle, or in the 5G Network IoT Gateway.

Do we take the Data from the Edge to the Blockchain or do we take the Blockchain to the Data at the Edge.

The most elegant is to take the Blockchain Mobile and to the Data at the Edge.

Surely the most secure way, is to protect the originality, integrity, confidentiality of the Data, at the Source, at the Edge, or as close to the Source as there is enough computational power to run a light Blockchain Database Server Node ? We will discuss this in detail in subsequent blogs.

Enterprise Blockchain SAP IoT Edge Mobile Vehicle to Insights Connected Everything atkrypto.io

Enterprise Blockchain Database Capability - Integrations / Connectivity / Blockchain Bridges and Bridging

Capability/Enabler: Integration, Integrator, Connection, Connectivity, Connector, Bridge, Blockchain Bridge, Bridging

This capability mainly revolves around the Distributed/Decentralised characteristic of the Blockchain.

This capability has a several different dimensions:

Getting Data in to the Blockchain

There are basically two clear leading options for getting Data in to the Enterprise Blockchain Platform, and those are:

API's

API's, there is nothing wrong with API's and there must always be API access to the Blockchain, for writing and for reading. For writing I see the API as more reactive than real time, and for reading data from the Blockchain API is the obvious choice.

There is a very nice blog in the SAP Community which favours Events over API's and personally I also lean that way for the majority of cases for writing data to the Blockchain. The blog is here: APIs: our flawed legacy from 1960’s thinking.[thanks to my friend Thomas Kaiser for finding that one]

Events

For me the biggest reason for using the Enterprise Blockchain Platform is the incredibly high level of security hardening and Data protection that it natively brings.

If we agree we will be more often positioning the Enterprise Blockchain Platform because of its security strengths, then next dimension is to write Data to the Enterprise Blockchain Platform as close to the source of that Data as possible no matter where the Data is, Edge or DataCenter.

The next dimension is that in the majority of cases, we will want to write the Data to the Enterprise Blockchain Platform as early as we can in the lifetime of the Data, ie, as soon as the Data was created.

If we want to write Data to an Enterprise Blockchain Platform as soon as the Data is created then the obvious technology for getting the Data to the Enterprise Blockchain Platform is Events, Event Driven Blockchain. I will be discussing this in detail in the later blogs which will deep dive in to individual use cases and reference architecture.

The Blockchain as a Data Integrator across the Organisation or Organisations

This capability crosses over with the Data Sharing capability. Basically the Enterprise Blockchain Platform becomes a Data Integrator within the Enterprise.

In a number of use cases the Enterprise Blockchain Platform could replace classical API based Integrations. In scenarios where there are Data Integrations between Applications, for example between Salesforce and SAP S/4HANA, instead of doing an API based Integration and only have security and protection to the level End to End Encryption, there could be an Enterprise Blockchain where Salesforce writes to the Enterprise Blockchain and SAP S/4HANA reads from the Enterprise Blockchain. This will be discussed in subsequent blogs which will deep dive in to use cases and reference architecture.

Bridging between Blockchains

This is a very important capability of Enterprise Blockchain Platforms and enables that Data can be bridged between Blockchains.

SAP S4HANA BTP Blockchain Web3 Reference Architecture Example atkrypto.io

Enterprise Blockchain Database Capability - Types of Blockchain

Capability/Enabler: Public, Private, Semi-Private, Consortium, Bridge

This capability mainly revolves around Layer 0 of the Blockchain Architecture, which is the Blockchain Network. An Enterprise Blockchain Platform which enables the Customer to create their own Blockchain Network will most likely have the best capability to enable the Customer create the Blockchain of their choice.

The main classifications of Blockchain Database are nicely described in this article from SAP, What is blockchain technology?.

SAP Article What is Blockchain Types of Blockchains atkrypto.io

Enterprise Blockchain Database Capability - Artificial Intelligence

Capability/Enabler: Integrity, Auditability, Traceability, Originality, Confidentiality, Protection, Safe, Treasure, Surety, Certainty, UnCompromised, Intelligent Technologies, Smart Technologies

This capability mainly revolves around Security characteristics of the Blockchain Platform and Database.

For Artificial Intelligence outcomes to be trustworthy, it must be certain that the Data used for the Artificial Intelligence can not have been altered.

That's it, it's as simple as that, if we want to trust what AI is telling us, then we need surety and certainty that the integrity and originality of the Data which the AI used cannot be or have been compromised.

Intelligent Technologies, for Intelligent Technologies to be intelligent, they cannot depend on stupid Data !

Smart Technologies, for Smart Technologies to be smart, they cannot depend on stupid Data !

That's where the Blockchain comes in.

SAP What is an Intelligent Sustainable Enterprise atkrypto.io

Now that we have elaborated on all of the capabilities and enablers of Enterprise Blockchain Databases and Enterprise Blockchain Platforms, let's get back to the goal of positioning Enterprise Blockchain Database and Platform as an Enterprise Technology Standard.

Before we do that, let's recap on the capabilities and enablers and summarise them:

Enterprise Blockchain Platform Capability Layers Map courtesy of Jan Tuma (TOGAF Certified SAP Enterprise Technical Architect) - atkrypto.io

In SAP Enterprise Architecture there is only one place to run the Enterprise Blockchain Platform, and that is, right next to the Digital Core S/4HANA in the "enabler", the SAP Business Technology Platform.

Why place the Enterprise Blockchain Platform in the SAP BTP ?

It's very very simple....

Proximity to the Data (of the Digital Core)

Ethnicity of the Data (in the Digital Core)

Proximity to the Process(es) (in the Digital Core)

Proximity to the Technology (of the Digital Core)

To wrap up, what we've done in this blog is identify all of the capabilities and enablers of Enterprise Blockchain Databases and the Enterprise Blockchain Platform, we've discussed why these capabilities are so important, and consequently how to position an Enterprise Blockchain Platform in the SAP Enterprise Architecture Technology Standards, where we use what and why.

We have also looked at where the Enterprise Blockchain Platform should reside, and the conclusion is in the "enabler", the SAP Business Technology Platform BTP, right next to the Digital Core S/4HANA, and enabling and leveraging all of the other Services in the SAP BTP and the native integration to the SAP Product Portfolio and other Enterprise Applications.

The good news is, as we discussed in the previous blog, this is no longer hype, we can do all of this today, and now, within the SAP Partner Edge Open EcoSystem there are enabling technology Blockchain Products designed and built by SAP Experts specifically for the needs of SAP Customers to make doing Blockchain and SAP easy, and so you can do SAP and Blockchain, today it's real and there's nothing stopping you.

So what are we waiting for ? Oh yeah, use cases, ok, that will be the next blog 😀 🚀

For now, over and out.

Andy Silvey.

Independent SAP Technical Architect and CEO of atkrypto.io

Author Bio:

Andy is also co-Founder of atkrypto inc, an startup whose ambition is to make Blockchain easy for Enterprise.

atkrypto.io's flagship product is the atkrypto Enterprise Blockchain Platform for SAP, and atkrypto.io is a SAP Partner Edge Open EcoSystem Partner.

Generative AI Hub using Azure OpenAI GPT-4

2024-03-15T20:14:46.164000+01:00

Note: This blog serves as a technical walkthrough for the Automatic Service Order creation with SAP Build Process Automation and Generative AI blog.

SAP Build Process Automation

Our solution employs SAP Build Process Automation to log email data and attachments.

Image 1: SAP Build Process Automation workflow

Essentially, the process automation is designed to monitor a dedicated inbox for service order requests sent by customers. Upon detecting a new service order request, it performs these actions:

It saves the email attachments and content.
It activates a custom script that packages the saved data into a JSON body.
It calls a Flask web service hosted on the Kyma runtime for processing, passing the above JSON body to it.
Once the web service has finished processing, it sends back an automated email response to the customer, updated with the service order number and status.

Following the processing of a request, the automation system continues to scan the inbox for additional emails. This iterative process repeats, ensuring no request is overlooked, and ceases only when there are no more relevant emails to process.

The custom script below shows an example of how you can package your payload to send over to the web service:

Image 2: Custom script within the automated workflow

For a more in-depth example of developing a custom process automation workflow, check out this video done by my colleague here.

Custom Flask web service hosted on the SAP Kyma runtime

For your reference, the code for this custom flask web service can be found in this Github repository link,

Upon receiving the JSON body from the above process automation, this custom Flask web service will then process the JSON body and post the desired outcome in JSON format into the S/4HANA system via two different API calls, which will be detailed below.

This web service makes use of the SAP AI Core, allowing us to utilize a variety of generative AI models in the Generative AI Hub.

For our solution, we thought that it was necessary to use two different AI models:

A text-based LLM that is capable of extracting and summarizing important information out of the mail (which in our case, is Azure OpenAI gpt-4-32k)
A large language-and-vision model that is capable of understanding and describing images (which in our case, is LLaVA-1.6)

Needless to say, these two models integrated seamlessly with our solution.

Text processing using Azure OpenAI gpt-4-32k

This is an example of a service order request mail sent in by a customer:

Image 3: Example service order request email

When handling a service order request sent by a customer, it's crucial to extract key details, such as the purchase date, model number, the problem as described by the customer, and the customer's contact information. The lack of uniformity in customer emails makes it challenging to use traditional methods like Regex for keyword extraction. This is where artificial intelligence becomes invaluable. It excels in understanding diverse text inputs and identifying essential information without the need for predefined patterns.

From a single email, AI enables us to accurately extract vital data, including:

Model number
Purchased date
Customer's description of the problem
Customer’s details
Description of any attachments
Any additional information that may be pertinent to the service request

Moreover, AI can leverage this information to generate a comprehensive problem description. When combined with image processing capabilities, this facilitates the creation of a detailed JSON payload.
This payload is then submitted to the S/4HANA Cloud, where the service order is generated (detailed at the bottom section of this blog).

For example, the following problem description is generated by AI (after passing to it the context of the mail and the images descriptions as well):

The customer has requested a service order for the following issue: damage to their shear, rendering it unusable, specifically a broken and detached handle grip, and a dislodged spring mechanism. The shear also began rusting within a month of use despite being advertised as waterproof. This damage considerably impacts the customer's ability to use the shear for its intended purpose. The customer mentioned that the shear was purchased on 27th December 2023, with the model number XKU00145. Given the unexpected nature of the damage and the fact that the shear should still be under warranty, the customer expects help in rectifying this situation through repair or replacement. The customer has also attached images documenting the specific damage (0987865.jpg). The image shows a pair of separated garden shears, a detached and possibly rusted spring, and signs of corrosion and wear on the metal parts. Due to these damages, the shears are not functional and appear to need repair or replacement to be usable again. The customer's contact number is +65 91112222.

Image processing using LLaVA-1.6

The above customer sends in an email with the following image attachment:

Image 4: Example of an image attachment (take note of the file name)

Image 5: Example of an image attachment

The following description of the above image was generated using LLaVA-1.6:

The image shows a pair of garden shears that appear to be broken. The tool is meant to be a single piece, but it has been separated into two parts, indicating a failure. Specifically, the shears' handles have been detached from each other, and a spring which is likely supposed to provide tension for the pruning action is also detached and appears to be rusted. The metal parts of the tool show signs of corrosion and wear. Due to these damages, the shears are not functional in their current state and would require repair or replacement to be usable again.

Additionally, it renamed the file from 0987865.jpg to BrokenShears_RoronoaZoro_20240228213047.jpg.
Notice how a short description of the problem, the customer’s name, and a timestamp is concatenated to make the filename unique and easily identifiable:

Image 6: Renaming of image attachment(s)

Also, multiple image attachments are also supported.

Creation of service order in the S/4HANA system

All the above data is then processed and passed on into a JSON payload (hint: we also used AI to format our JSON body😉, think adhering to maxLength text fields and potential loopholes that can be solved using AI), which is then submitted to the S/4HANA system through two separate APIs:

As the name describes, the Service Order Creation API enables us to create service orders without having to manually create it on the S/4HANA system.

The Attachments API enables us to latch onto the business object (which is the service order created above), and uploads the images into the same service order. I have included the link above to both the API references. The APIs require CSRF tokens to be called, therefore a GET precedes every POST. The business object type to be used in the attachments API is BUS2000116.

The web service then passes the following example JSON payload into the S/4HANA system via the service creation API:

Image 7: Example of the Service Order API JSON payload

Results

The service order is successfully created in the S/4HANA system!
The below image shows an excerpt of the service order:

Image 8: An excerpt of the service order (Note that not the full service order is shown above, due to its large content)

Of course, if any of the fields are not filled in properly or if its properties are not respected, then the service creation will fail. I encourage you to read up the API reference for both the service order and attachments before getting started.

Solution Architecture – Service Order Automation

Image 10: Solution architecture for automation scenario

If you’re interested in a high level overview of this solution, you can visit this blog. Also, if you're interested in exploring solutions like this or wish to learn more, feel free to reach out to me.

References

SAP Build Process Automation
SAP AI Core
SAP AI Core service guide
Generative AI @ SAP
Service Order documentation
Generative AI hub sdk
Service Order Creation API (OData v2)
Image Attachments API (OData v2)

Automatic Service Order creation with SAP Build Process Automation and Generative AI

2024-03-15T20:15:28.015000+01:00

Motivation

In the fast-paced digital era, businesses seek efficiency in every operation. Yet, the process of creating service orders for faulty equipment remains labor intensive, requiring manual data entry and analysis.

Our solution leverages the power of SAP Build Process Automation as a SAP BTP extension, a web service hosted on SAP BTP Kyma runtime, and generative AI powered by SAP AI Core, to transform this tedious process into a seamless, automated workflow. This blog outlines the approach.

The Original Business Process

Traditionally, the creation of service orders is a manual and time-intensive process.

The cons? Lots of tedious toggling between email and S/4HANA system service order creation page, involving several steps that are not only prone to human error but also lead to delays and potential customer dissatisfaction.

This is how it originally looks like:

Image 1: Outline of the original service order creation workflow

Receive customer email requesting a service order for faulty equipment.
Manually extract key information from the email, such as equipment details, purchase date, and analyze attached images for consistency with the equipment description.
Download, rename, and document descriptions of attached images for organization.
Develop a comprehensive problem description based on the email and images, manually entering this along with all extracted information into the S/4HANA system.
Manually upload images to the service order form.
Create the service order.
Confirm service order creation with the customer via email.

Solution

We aim to automate the manual aspects of this process, creating a system that automatically processes customer emails, including attachments, to generate service orders in S/4HANA without manual input.

This solution relies on two main components:

SAP Build Process Automation, an extension of SAP BTP, for workflow automation.
Generative AI, powered by SAP AI Core and delivered through a web service on SAP Kyma runtime, to interpret and process data.

Image 2: SAP Build Process Automation as an SAP BTP extension

SAP Build Process Automation, an SAP BTP extension, streamlines business process automation and decision-making with minimal coding. It features intuitive drag-and-drop interfaces for easy process design and quick integration within the SAP ecosystem, thereby boosting operational efficiency and facilitating digital transformation.

The automation workflow, created with SAP Build Process Automation, monitors the inbox for service order requests, extracting content and attachments from emails. This information is processed by our web service on SAP Kyma runtime, where the “magic” happens.

Image 3: SAP Build Process Automation workflow

Generative AI is an exceptional component in solutions like ours. Within our web service, we utilized the open-source vision model Llava 1.6 to interpret attached images and GPT-4 for analyzing email content, all powered by the SAP AI Core.

Image 4: Vision and text models, powered by SAP AI Core

We then use the results to populate the S/4HANA system via POST requests, ensuring that the entire service order form is filled accurately and thoroughly. Multiple image attachments are also supported, with the attached images being uploaded and renamed automatically.

Last but not least, to end off the automation workflow, we can send an automated email reply to the customer with an update on their server order number and status.

Results

From just a single customer email,

Image 5: Original email sent by the customer

we unlock all these capabilities shown below, hands-free and without any human intervention!😉

Image 6: The service order is successfully created in the S/4HANA system

Image 7: Results generated by LLaVA 1.6 and gpt-4-32k

Image 8: Uploaded attachments of renamed images

Image 9: Automated email response sent to the customer

Conclusion

The most remarkable aspect of this solution is its complete automation, which can lead to the significant advantages below:

Faster creation of service orders (~2 min per email)
Increased accuracy of service orders
Higher scalability where hundreds of requests can be handled simultaneously
Better customer satisfaction due to rapid response and accuracy

Beyond service order creation, the potential applications of AI and SAP products can extend to various other business processes, including warranty claim automation, invoice posting automation, and many others.

This video summarises the automatic service order creation process using SAP Build Process Automation and Generative AI:

If you’re interested in the technical details of this solution, you can visit this blog. Also, if you're interested in exploring solutions like this or wish to learn more, feel free to reach out to me.

References

SAP Build Process Automation
SAP AI Core
SAP AI Core service guide
Generative AI @ SAP
Service Order documentation
Generative AI hub sdk

Oil & Gas - Ultimate Data Security - Blockchain Data Backbone from OT to SAP IT🚀

2024-03-18T08:58:40.889000+01:00

The Problem

One of the Oil & Gas Industry's biggest challenges is protecting the data which is flowing from UpStream OT Operational Technology to SAP IT Information Technology.

Due to the very nature of Oil & Gas operations, more often than not, the OT Operational Technology is located in geographically remote places, and a long way from the SAP Information Technology and DataCenter.

The OT Data is the most vulnerable, the most exposed to threats when it is flowing from the UpStream Sectore, the "E & P" Exploration and Production, to the SAP IT systems in the DataCenter:

SAP Oil Gas Operations Technology Data Risk Integration to S4HANA Industry Cloud atkrypto.io

The Threat:

The biggest threat to getting data from the Oil & Gas Operational Technology to the SAP Information Technology, is the threat of Cyber Attacks. The attack vector at most risk is the movement of the data, or the data on the move, the integration between the OT and the SAP IT.

In their March 2023 Report, "How to enhance the cybersecurity of operational technology environments", McKinsey and Company highlight the need for "strengthening technological foundations", and in particular, highlighting that,

"integration between OT systems and ERP systems increase the need for secure convergence between the IT and OT environments"

Courtney Schneider, in the report, "OT security incidents in 2021: Trends & Analysis," Waterfall Security Solutions, May 17, 2022, noted that,

"OT cyberattacks tend to have higher, more negative effects than those in IT do, as they can have physical consequences (for example, shutdowns, outages, leakages, and explosions). Of 64 OT cyberattacks publicly reported in 2021 (an increase of 140 percent over the number reported in 2020), approximately 35 percent had physical consequences, and the estimated damages were $140 million per incident."

Today's Legacy Approach to Integration Security

Data Security has evolved slowly during that last 30 years:

Evolution of Data Security atkrypto.io

Data Encryption is not enough

Encryption is not enough atkrypto.io

The Business Demand

The Oil & Gas industry is demanding more, the Business is demanding better security of integration between OT and SAP IT.

The Digital Transformation of Information Security is Enterprise Blockchain, The Next Generation Data Integrity, Originality, Confidentiality Protection

Enterprise Blockchain, Enterprise Distributed Ledger Technology is re-imagining information security.

Enterprise Blockchain Platforms bring, out of the box, natively, a level of security which is not possible out of the box, natively, with any other commercial database product.

What is so special about the Enterprise Blockchain, (and discussed in the previous blogs, here, here, and here) is that Blockchain Distributed Ledger Technology has four special characteristics which make it information security re-imagined, and the next generation of information security, these special characteristics are:

atkrypto.io what is a blockchain SAP Oil Gas OT IT

This means, we can have the an Enterprise Blockchain Database Tenant running at the Oil & Gas E&P OT sector and an Enterprise Blockchain Database Tenant running at the SAP DataCenter location, and the same data available in both places and protected to the highest level by the Blockchain's Hash Mechanism, Consensus Mechanism, Immutable status, and Distributed resilience.

We can now run Enterprise Blockchain Database from the Exploration and Production sector to the SAP system in the DataCenter, protecting the OT Data as it flows to the SAP IT, to a level of security protection that was not possible with the previous generation of technology:

Blockchain Next Generation Data Protection SAP Oil Gas OT IT atkrypto.io

Wrapping Up and Reference Architecture

To wrap up, a simple reminder,

The Digital Transformation of Information Security is Enterprise Blockchain

Enterprise Blockchain is the Next Generation Data Integrity, Originality, Confidentiality Protection

Enterprise Blockchain, Enterprise Distributed Ledger Technology is re-imagining information security.

SAP have got everything in place for you to do this today, and here's the thing, and now, within the SAP Partner Edge Open EcoSystem there are enabling technology Blockchain Products designed and built by SAP Experts specifically for the needs of SAP Customers to make doing Blockchain and SAP easy, and so today, you can do SAP and Blockchain, it's no longer hype, today it's real and there's nothing stopping you.

Reference Architecture Event Driven Blockchain with SAP

Here is an example of how Enterprise Blockchain can be implemented to bring next generation data integrity protection to the Oil and Gas OT to IT integrations.

The Enterprise Blockchain Database Tenant is running at the E&P Sector and at the same time, the Enterprise Blockchain Database Tenant is running at the SAP Business Technology Platform. The OT Data is written to the Enterprise Blockchain Database and the SAP S/4HANA and or SAP Industry Cloud read the data from the same Enterprise Blockchain Database.

SAP Oil and Gas OT to IT Integration Blockchain Security atkrypto.io

As McKinsey & Company, in their December 2023 Featured Insights Publication, gave a beautiful description of what is unique and special about Blockchain, "Blockchain is a secure database shared across a network of participants, where up-to-date information is available to all participants at the same time".

So what are we waiting for ? Oh yeah, more use cases, ok, that will continue in the next blog

For now, over and out.

Andy Silvey.

Independent SAP Technical Architect and CEO of atkrypto.io

Author Bio:

Andy is also co-Founder of atkrypto inc, an startup whose ambition is to make Blockchain easy for Enterprise.

atkrypto.io's flagship product is the atkrypto Enterprise Blockchain Platform for SAP, and atkrypto.io is a SAP Partner Edge Open EcoSystem Partner.

SAP BW Bridge In SAP Datasphere : Connectivity Between S/4HANA System & BW Bridge

2024-03-19T17:43:39.356000+01:00

This blog is in continuation of my previous blog on SAP Datasphere please find the following link - SAP Datasphere Connectivity With S/4 HANA System &... - SAP Community

Introduction:

SAP BW bridge is a functional enhancement of SAP Datasphere and enables ABAP-based data extraction and staging capabilities within SAP Datasphere. It provides customers who are running SAP Business Warehouse or SAP BW/4HANA with access to the public cloud as it offers SAP BW capabilities directly in SAP Datasphere.

SAP BW Bridge for SAP Datasphere is a feature that makes certain elements from the on-premise SAP BW system available in the cloud. In order to transfer these elements to SAP Datasphere, SAP also supplies the appropriate conversion tools. SAP BW Bridge is a cost-effective and simple way to switch from an on-premise SAP BW system to SAP Datasphere.

Provisioning the SAP BW Bridge Tenant:

We need to define SAP BW Bridge Storage before creating SAP BW Bridge Tenant. Configure the size of your SAP BW bridge tenant in the Tenant Configuration:

From the side navigation, go to System =>Configuration =>Tenant Configuration

Choose the size & Save

Now create SAP BW Bridge instance
Go to System -> Configuration -> SAP BW Bridge and create

Provide the Instance name and description
For Development system: Select enable system for development
For Production system: Deselect enable system for development

A SAP BW Bridge Space has been created automatically as given below-
We just need to add users in the BW Bridge space.

Activate BW Bridge Tenant:

When a new SAP BW bridge tenant is provisioned together with a new SAP Datasphere tenant, the system owner receives a welcome email. Click the Activate Account button to connect to the server and set your password.

When a new SAP BW bridge tenant is provisioned to an already existing SAP Datasphere tenant, the first login to the SAP BW bridge tenant must be done by the user who was system owner of the SAP Datasphere tenant when the SAP BW bridge tenant was provisioned.

System owner needs to create the other users in the BW Bridge Cockpit.

After activating it get activated:

Open SAP BW Bridge Cockpit:

From the side navigation, choose Data Integration Monitor -> Choose BW Bridge space

Now we can see the BW bridge cockpit, Click Open SAP BW Bridge Cockpit

Preparing Connectivity for ODP Source Systems in SAP BW Bridge:

Connecting an SAP on-premise system to SAP BW bridge requires a few more steps than connecting the same system to an SAP BW on SAP HANA or SAP BW∕4HANA system.

We will required a Cloud Connector which serves as a link between the on-premise source system and your SAP BW bridge tenant which is technically based on an ABAP Platform in SAP BTP. RFC is used as a protocol for data exchange between on-premise source systems and SAP BW bridge.

System needs to be added in the cloud connector with RFC protocol.

The on-premise source system must be configured as communication system in BW Bridge Cockpit.

The source system connectivity is established following these procedures:

Add the SAP Datasphere subaccount in the Cloud Connector.
Create the on-premise source system in the Cloud Connector.
Add the relevant resources to the source system.
Add a service channel to the SAP BW bridge tenant in the Cloud Connector.
Create a communication system in the SAP BW bridge tenant.
Create the source system in the SAP BW Modeling Tools.
Optional: Select and activate preconfigured SAP BW bridge Content objects.

Steps 1 to 3 already done before in my previous blog post please find the following link – SAP Datasphere Connectivity With S/4 HANA System &... - SAP Community

Add a Service Channel to the SAP BW Bridge Tenant in the Cloud Connector:

The on-premise source system must be able to call the SAP BW bridge tenant via RFC. Therefore, a service channel must be added in the Cloud Connector.

Procedure:

Log in to the Cloud Connector
In the left-side menu of the administration UI, select On-Premise To Cloud
In the Service Channels section, click (Add) to add a new service channel.
In the Add Service Channel dialog, use the following values:
1. Type: ABAP Cloud System
2. ABAP Cloud Tenant Host: For SAP BTP ABAP based systems like SAP BW bridge, the tenant host is <serviceinstanceguid>.abap.<region>.hana.ondemand.com . The region is, for example, eu10 or us10.

To retrieve the host name:

Log on to SAP Datasphere.
From the side navigation, choose Space Management.
Select the space BW Bridge.
Navigate to the section Connections.
Mark the local connection BWBRIDGE and choose Edit.
Under HTTP Access copy the host name to the clipboard (without https://).

In the same dialog window, define the Local Instance Number under which the SAP BW bridge system is reachable for the source system(s). The <Local Instance Number> will later be used when maintaining the RFC destination in the on-premise source system pointing to the SAP BW bridge system (i.e. in the so-called callback destination).
Leave Connections set to 1.
Leave Enabled selected to establish the channel immediately after choosing Finish. Unselect it if you don't want to establish the channel immediately.
Select Finish.

You can now see that Service channel is enabled.

Create a Communication System in the SAP BW Bridge Tenant:

The on-premise source system must be configured as communication system in the SAP BW bridge tenant. A communication system is a specification of a system that represents a communication partner and the technical information required for the communication (inbound/outbound), such as the host name and user information (inbound/outbound).

Procedure:

Log on to the SAP BW Bridge Cockpit.
In the Communication Management section, select the app Communication Systems.
Click New to add a new Communication System.
In the New Communication System dialog, enter a System ID and a System Name and choose Create.

Under Technical Data, maintain the following values:
1. Enter the virtual host name maintained in the Cloud Connector as Host Name.
2. Fill in the port number 33<instance number> as Port, e.g. 3301 if the instance number is 01.
3. Switch on the property Cloud Connector.

Under RFC Settings, maintain the following values:
1. Set Load Balancing if the on-premise source system was created with the option With load balancing (system ID and message server) in the Cloud Connector.
2. Maintain the client of the source system as Client.
3. If Load Balancing was set, maintain a logon group of the source system as Group. Enter the virtual system ID maintained in the Cloud Connector as Target System. Enter the virtual message server maintained in the Cloud Connector as Message Server.
4. If Load Balancing was not set, enter the virtual instance number maintained in the Cloud Connector as Instance Number. Enter the virtual application server maintained in the Cloud Connector as Target Host.
5. Maintain the location ID of the Cloud Connector as SCC Location ID. In case you did not specify a location ID in the Cloud Connector, you can leave SCC Location ID blank.

Under Users for Inbound Communication, click (Add) to maintain the user that is used in the SAP BW bridge tenant for the inbound communication. Select an existing user or click New User to create a new user.
Under Users for Outbound Communication, Enter the username and password of an existing user in the on-premise source system.
Save the new communication system.

As a result, you have created the on-premise source system as communication system in the SAP BW bridge.

Maintain Communication Arrangement:

You need to maintain communication arrangement for the communication system that we have created in the BW Modeling tool.

You need to choose the predefined communication scenario SAP_COM_0692. And enter the required details like –

Use the technical name of the source system as Arrangement Name
User for Inbound Communication
User for Outbound Communication

Maintain Callback Destination:

Create a RFC in S4H system(Standard Name Given in Communication systems):

Log in to the on-premise source system.
Call transaction SM59.
Choose Create to create a new RFC connection.
In the Create Destination dialog, enter the name of the Callback Destination shown in the BW Modeling Tools as name of the Destination and choose RFC connection to ABAP system as Connection Type.
On the Technical Settings tab, enter the hostname of the Cloud connector (without https:// and without port number) as Target Host and the local instance number you defined in the Cloud Connector for the service channel as Instance Number.
On the Logon & Security tab, enter the Language, 100 as Client and User and Password of the user you defined as User for Inbound Communication.

ODP_INBOUND User which is created in BW bridge cockpit, User for inbound communication

Connection test:

Authorization test:

Create an SAP BW Bridge Project:

To test the connection between we will create a project in BW modeling tool using service key.

For service key we need to go to BW Bridge Space => Choose Connections and select the BW Bridge space => Choose Edit => Copy the SAP BW Service Key

Now Create an SAP BW Bridge Project in BW modeling tool with the system details

Logical destination and callback destination(which we have created in backend S/4 HANA system) should have status green as below -

Now the connection has been established successfully between S/4HANA and BW Bridge cockpit.

With SAP BW Bridge for SAP Datasphere, SAP has created an attractive and cost-effective way for companies to move from their SAP BW on - premise system to SAP Datasphere. SAP BW Bridge is particularly interesting if companies do not want to do a greenfield implementation but want to take existing content with them into the cloud.

Resiliency in the SAP BTP, Kyma runtime

2024-03-20T19:31:27.680000+01:00

Have you been wondering how to achieve high availability for your SAP cloud-native Kubernetes applications with Kyma runtime?

SAP BTP, Kyma runtime is the managed service of SAP’s cloud-native Kubernetes application runtime. Its production plans ensure high availability.

To benefit from the high-availability setup, you must make sure the architecture and deployment of your application comply with resiliency best practices. But don’t worry, you don’t have to figure it out alone!

To learn about our recommendations and enjoy stable Kubernetes and microservice-based applications, read Deploy Resilient Applications in the Kyma Runtime and unlock the secrets to developing Kubernetes and microservice-based applications.

The What Is... The Why To... The How To... of: ESG & SAP & Enterprise Blockchain 🚀

2024-03-21T15:21:10.356000+01:00

What is ESG ?

ESG is "Environmental, Social, and corporate Governance" and revolves around how well an Organisation is performing across these three pillars. The stronger an Organisation is across these pillars, the higher the Organisation's ESG score or rating will be.

What is an ESG score/rating ? For me it's like when I go on Booking.com or AirBnB to find an apartment or hotel for a family holiday, I am looking for the properties which have the highest rating. This is how it is with ESG, the ESG score shows the Organisation's rating across these dimensions, "Environmental, Social, and corporate Governance", where we would expect, the higher the score, the more we can trust the Organisation.

And ESG is more than that, as @James_Marland describes in the blog Your Ledger is about to go Green the European Union is on a journey bringing legislation and "are going to ask companies to maintain a second set of books, that run in parallel to the traditional ledgers, and that’s a set of books called the Green Ledger".

ESG scoring takes a holistic view of the Organisation:

Holistic View on Sustainability Performance – Example WEF SCM Framework

[thanks to @gunther_rothermel and his ESG Performance Management blog]

For me,

ESG is about Data.

Why to do ESG ?

There are hard reasons and softer reasons, the softer reasons are elaborated in more detail below, but the hard reason for doing ESG, the reason we cannot be avoided, is European legislation, and to repeat, so that we don't miss it, as @James_Marland describes in the blog Your Ledger is about to go Green the European Union is on a journey bringing legislation and "are going to ask companies to maintain a second set of books, that run in parallel to the traditional ledgers, and that’s a set of books called the Green Ledger".

ESG (“Environmental, Social, and corporate Governance”) concerns are playing a greater role in investment decisions and hence corporate decision making.

Part of the ESG framework is scoring Organisations to measure how they are performing against ESG standards.

ESG scoring helps to provide a standardized way to quantify an Organisation’s ESG impact, and is consumed by:

Consumers of ESG Ratings - atkrypto.io

In her blog, @annchristinschechter , the report describes it like this:

The Situation: Sustainable Business is the 3rd Wave of Global Economic Transformation

Investors, shareholders, regulators, and consumers all demand responsibly derived products
and services with a smaller environmental footprint. Reducing global emissions,
waste, and social injustice requires a full-lifecycle approach with enterprises at the forefront.

Wittwer Reichel Knoedler - Sustainability within SAP Premium Engagements

Going back to the, Booking.com or AirBnB to find an apartment or hotel for a family holiday analogy, in the same way as a properties with lower ratings attract less interest, the time will soon be upon us when Organisations with lower ESG scores will be at a disadvantage compared to those with higher scores.

That and social responsibility is Why To Do ESG.

For me, again,

ESG is about the Data, and if the Data is so important, then we need to be able to Trust the Data.

How to do SAP, ESG, and Enterprise Blockchain

The ESG score is an example of the circular economy. The key to the score is the Data, the Data coming from in most cases the Edge, from Sensors and Things. As shown in the picture below, the Data from the Edge needs to be stored safely and securely so that it can be processed by the SAP Sustainability Control Tower:

SAP - ESG - IoT - Enterprise Blockchain - atkrypto.io

SAP by the way, have a portfolio of Products to enable Enterprises to do ESG, and these include:

. SAP Sustainability Footprint Management

. SAP Sustainability Data Exchange

. SAP Sustainability Control Tower

In this blog we are focusing on protecting the integrity and originality and confidentiality of Data which is used to do ESG scoring and rating, Data which would then be consumed by for example the SAP Sustainability Control Tower.

There are two related challenges to overcome when collecting data for ESG scoring. The first comes in two parts: simply collecting the data in the first place, since there may be large numbers of sensors and systems (consider carbon emissions across a supply chain, and the myriad vehicles, vessels, machines and people involved); and moving that data fast enough that decisions can be made using it (which we’ll use as the definition of “real-time” in the rest of this blog)

The second challenge is that with any measurement system, the measurement is only as reliable as the data collected. This opens a “trust gap:” organisations have incentives to increase their ESG score: how can we be sure of the validity of the data they’ve collected? Similarly, how can they be sure of the data their subcontractors have collected?

Investors are increasingly demanding ESG Audits of target Organisations, and it’s likely the requirements of ESG scoring become stricter. Being able to demonstrate that an Organisation’s ESG data collection methods are beyond reproach is likely to represent a significant business advantage, along with benefits of reacting to this data in real time.

ESG Data Sources

ESG measurement data can contain Personal Sensitive and Business Critical information across the Corporate domains of:

ESG Data Sensitivity atkrypto.io

Data sources for this data come from all over the organisation: Enterprise Applications and Things (sensors, monitors and connected applications at the edge), including ERP systems, HR systems, Sensors measuring CO2 levels and Water Quality.

In this blog we’ll take as an example data from Waste Trucks proving responsible disposal of Corporate waste, to see just how many sources of data there are and how to address the challenges this creates.

ESG Example Sources of Data - atkrypto.io

ESG Data Security

In terms of the NIST CIA Triad for Data Security, Criticality, Integrity, Availability, ESG measurement data comes in Very High across all three classifications.

NIST Triad Data Security Sensitivity Confidentiality Integrity Availability - atkrypto.io

As the ESG performance rating is so critical, data measurements which are used need to be auditable and the integrity of the data completely trustworthy, so the highest level of data security and integrity protection is required.

To address the “trust-gap”, it is essential that it can be proven that the ESG measurement data cannot be interfered with and can be trusted. At the same time, the ESG measurement data needs to be available to a number of Enterprise Applications for it to make any actionable change.

Enterprise Architecture saves the day...

So, this is where Enterprise IT comes in to save the day and solve the problem.

The business requirement is for:

. Data from any source needs to be Stored as close to the source of the Data as possible

. The source of the Data can be Edge / IoT / Mobile Things, and can also be ERP and Enterprise Software Applications

. The Data needs to be stored with the highest level of integrity and originality and confidentiality and sensitivity protection

. The Data store solution should be available out of the box in a commercial off the shelf product

. The Data must be stored Immutably

As discussed in the previous blog, [SAP Enterprise Architecture: Positioning Blockchain Database as an Enterprise Technology Standard 🚀] when we look in to our Enterprise Architecture Technology Standards we see there is only 1 Technology Standard in the Enterprise which is positioned with the capabilities to fulfill all of those requirements out of the box, and that is the, Enterprise Blockchain Platform and Enterprise Blockchain Databases.

Comparison Enterprise Blockchain Database and Traditional Legacy Database - atkrypto.io

Why Enterprise Blockchain Database for securely storing ESG measurement data ?

As we described in the first blog in this series, [Why I love SAP and Blockchain Databases and why you should too 🚀], there are four characteristics which make Blockchain natively the most secure data storage.

These are:

atkrypto.io what is a blockchain

A Blockchain can only be called a Blockchain if it has these characteristics, the point being that once data is entered in a blockchain it cannot be altered or deleted. This provides trust in the data, so that, for instance, ESG auditors know that if a measurement is calculated from data held in a Blockchain, they can trust that the data hasn’t been adulterated while being stored.

In the following Enterprise Blockchain Platform for ESG deployment example scenarios we have data coming from multiple data sources, some of which are at the Edge/IoT and some are Enterprise Applications in the DataCenter or Cloud. At the same time data which is being written to the Enterprise Blockchain Database can originate from multiple Organisations which are sharing the same Enterprise Blockchain Platform and Database as a common shared single source of truth.

ESG Comparison Enterprise Blockchain Database and Traditional Legacy Database - atkrypto.io

The immutability of blockchain data is what enables trust between what otherwise might be competing organisations.

Example 1, Single Enterprise Blockchain Database within your Organisation for ESG Data

In this example, an Enterprise is storing ESG data to its Enterprise Blockchain Platform.

ESG data is originating from multiple sources as shown in the diagram:

ESG Example Sources of Data - atkrypto.io

Imagine an Enterprise subcontracting the disposal of its electronic waste. For ESG compliance the Enterprise needs to make sure that its waste carrying vehicles aren’t tempted to take short cuts in personnel management or the disposal, but must also verify the subcontractor is upholding their standards, too.

Data can be used from the Waste Truck’s GPS and onboard cameras to prove both where the waste was disposed of geographically through the GPS data and physically through the photographic evidence from the Truck’s on board cameras. Think about how delivery drivers photograph where they’ve left a parcel.

The collection of this data is enabled either by SAP Advanced Event Mesh, which spans geographies and environments such as On-Premise, Cloud and all the way to the Edge, connecting the Waste Truck to Enterprise Applications such as Route Planning, HR management, Scheduling and other operational systems as well as the Enterprise Blockchain Database Edge Tenants and the Enterprise Blockchain Database Server Tenants.

All this data, including the photographs, are stored on the Enterprise Blockchain Platform Database, the photographs will be stored as Enterprise NFT’s in the Enterprise Blockchain Wallet.

Next generation data integrity protection is Enterprise Blockchain Platform on SAP BTP Kyma - the secure data backbone - atkrypto.io

Example 2, Single Blockchain shared across Organisations for ESG Data

This example is where the real beauty of the Distributed Ledger Technology is brought in to focus.

Enterprise Blockchain Platform Database as a shared single source of truth across Organisations.

In this example the Enterprise Blockchain Platform is running Blockchain Database Tenants in your Organisation and also in your Partner Organisations. This enables the Enterprise Blockchain Database to provide an irrefutable shared single source of truth for data across Organisations, who normally would not openly trust each other with data.

ESG Data from 3rd Party Organisations Enterprise Blockchain Shared Common Single Source of Truth - atkrypto.io

Your Organisation outsources industrial waste collection and responsible disposal to a 3rd party Organisation.

Your ERP system orders the 3rd Party Waste Processor to collect and dispose of industrial waste.

For your Organisation’s ESG data, you depend upon evidence that the 3rd Party Organisation is responsibly disposing of the waste.

The Enterprise Blockchain Platform Database enables a shared single source of truth to be created across the Organisations by running inter-connected Blockchain Server Nodes in both Organisations.

SAP ESG Blockchain Shared Single Source of Truth across 3rd Party Organisations - atkrypto.io

In the above example, the Enterprise Blockchain Platform Database is running across Organisations.

Your Organisation is writing data to the same Enterprise Blockchain Database as your 3rd Party partner Organisation.

The Enterprise Blockchain Database contains evidence from your S/4HANA ERP system that the 3rd Party Waste Processor was ordered to process your industrial waste.

In the same Enterprise Blockchain Database the 3rd Party Waste Disposal Organisation is storing evidence from the Waste Trucks that the waste was collected from your premises and disposed of responsibly at the authorised waste treatment center.

This scenario opens a new world of opportunities for multiple Enterprises to share data, multi-Enterprise collaboration, with the Enterprise Blockchain as the irrefutable common shared single source of truth across Organisations.

The most beautiful thing about the picture above is that we have an Enterprise Blockchain Database shared across 3rd party Organisations, this achieves a few things:

. Saves a huge amount of effort to integrate the IT systems of the two 3rd party Organisations

. Enables both Organisations to write Data to the same Enterprise Blockchain Database

. Enables both the ESG Customer Organisation to read the Data from the Enterprise Blockchain Database into their SAP Sustainability Control Tower to enable ESG Reporting

. Enables both Organisations to be able to trust the Data in the Enterprise Blockchain Database

. Enables both Organisations to know that neither Organisation can modify the Data in the Enterprise Blockchain Database

. Enables both Organisations to know that their shared Data is being protected to the highest level natively out of the box of any Database Product

Wrapping Up

To wrap up, a simple reminder,

The Digital Transformation of Information Security is Enterprise Blockchain

Enterprise Blockchain is the Next Generation Data Integrity, Originality, Confidentiality Protection

Enterprise Blockchain, Enterprise Distributed Ledger Technology is re-imagining information security

With regards to ESG,

ESG is about Data

ESG is about the Data, and if the Data is so important, then we need to be able to Trust the Data

If we need to be able to Trust the Data, then we need to put it on to the Enterprise Blockchain as the irrefutable common shared single source of truth across our Organisation and other Organisations

Enterprise Blockchain is both a Secure Store and a Secure Communication Channel.

This blog is the fifth in the series, the previous blogs are here, here, here and here.

We will be describing more use cases for this scenario in future blogs, including for example the Insurance use case, where the Carrier, the Broker, and the Customer are on the same Enterprise Blockchain.

So what are we waiting for ? Oh yeah, more use cases, ok, that will continue in the next blog

Credits: Tom Fairbairn Distinguished Engineer at Solace contributed to this blog. We will be following this blog up with a deeper Technical Architecture dive into getting the Data and how SAP Advanced Event Mesh is positioned in the Solution Architecture for publishing the real time ESG Data and Enterprise Blockchain is positioned for Protecting the ESG Data, Event Driven Blockchain, Publish & Protect.

For now, over and out. 🚀

Andy Silvey.

Independent SAP Technical Architect and CEO of atkrypto.io

Author Bio:

Andy is also co-Founder of atkrypto inc, an startup whose ambition is to make Blockchain easy for Enterprise.

atkrypto.io's flagship product is the atkrypto Enterprise Blockchain Platform for SAP, and atkrypto.io is a SAP Partner Edge Open EcoSystem Partner.

Kyma Integration with SAP Cloud Logging. Part 1: Introduction and shipping Logs

2024-03-25T16:31:14.239000+01:00

Welcome to the first blog in our three-part series, where we will explore how Kyma can seamlessly integrate with the SAP Cloud Logging service. By enabling the three pillars of observability - logs, traces, and metrics - Kyma developers and operators can effectively troubleshoot issues, identify root causes, investigate performance bottlenecks, and gain a comprehensive understanding of system behavior.

In this initial blog post, we will delve into the following topics:

SAP Cloud Logging: An Overview
- Learn about the SAP Cloud Logging service and its significance in the context of Kyma integration.
- Discover how to provision an instance of SAP Cloud Logging.
Shipping Logs to SAP Cloud Logging
- Explore the step-by-step process of shipping logs from applications deployed on SAP BTP, Kyma runtime to SAP Cloud Logging.

In the subsequent blogs, we will continue our exploration by discussing the integration of traces and metrics.

What is SAP Cloud Logging?

The SAP Discovery Center description says:

SAP Cloud Logging service is an instance-based observability service that builds upon OpenSearch to store, visualize, and analyze application logs, metrics, and traces from SAP BTP Cloud Foundry, Kyma, Kubernetes, and other runtime environments.

For Cloud Foundry and Kyma, SAP Cloud Logging offers an easy integration by providing predefined content to investigate the load, latency, and error rates of the observed applications based on their requests and correlate them with additional data.

To get started with SAP Cloud Logging, visit the Discovery Center where you will find more detailed information about its features and capabilities.

Pricing for the SAP Cloud Logging service can be determined using the SAP Cloud Logging Capacity Unit Estimator. It is important to note that for Kyma, the "Ingest Otel" option needs to be enabled, which should be taken into account when estimating pricing. This option is used for shipping traces and metrics.

Provision an Instance of SAP Cloud Logging

Now, let's explore how we can leverage SAP Cloud Logging to ingest logs from applications deployed on SAP BTP, Kyma runtime.

Prerequisites

SAP BTP, Kyma runtime instance
Telemetry module enabled in Kyma runtime instance
Entitlement added for SAP Cloud Logging
kubectl and command line support

Procedure

You can refer to the official SAP documentation to create an SAP Cloud Logging service instance for details.

Export your namespace's name as an environment variable.

export NS={your-namespace}

Create an instance of SAP Cloud Logging and a service binding:

kubectl -n ${NS} apply -f https://raw.githubusercontent.com/SAP-samples/kyma-runtime-extension-samples/main/sap-cloud-logging/k8s/cls-instance.yaml

For reference, this is the service instance specification:

apiVersion: services.cloud.sap.com/v1
kind: ServiceInstance
metadata:
    name: my-cls
spec:
    serviceOfferingName: cloud-logging
    servicePlanName: dev
    parameters:
      retentionPeriod: 7
      esApiEnabled: false
      ingest_otlp:
        enabled: true

This is the corresponding service binding.

apiVersion: services.cloud.sap.com/v1
kind: ServiceBinding
metadata:
    name: my-cls-binding
spec:
  serviceInstanceName: my-cls
  credentialsRotationPolicy:
    enabled: true
    rotationFrequency: "720h"
    rotatedBindingTTL: "24h"

The service binding specifies the credentials' rotation policy.

It is a great developer experience that the Telemetry module intelligently switches to new credentials once they are rotated. This does not require any action from the developer.

NOTE: The same instance will be reused for configuring tracing and monitoring.

The service binding also generates a Secret with the same name. It contains the details to access the dashboard of the SAP Cloud Logging instance previously created.

Ship your application logs to SAP Cloud Logging

To ship your logs to SAP Cloud Logging, create LogPipeline custom resources (CRs).

Your application running in SAP BTP, Kyma runtime will send logs to stdout. The Telemetry module based on the LogPipeline will capture and ship them to SAP Cloud Logging.

Create a LogPipeline CR for Your Application Logs

To create the LogPipeline, run:

kubectl apply -f https://raw.githubusercontent.com/SAP-samples/kyma-runtime-extension-samples/main/sap-cloud-logging/k8s/logging/logs-pipeline-application-logs.yaml

In the LogPipeline, configure the details about shipping the logs to SAP Cloud Logging. Include major configurations such as:

Input: From which applications, containers, and namespaces the logs should be shipped
Output: The access details of the SAP Cloud Logging instance to which logs will be shipped

You can learn about all the parameters in detail from the official Telemetry LogPipeline documentation.

This is an example of the LogPipeline configuration used for this blog post:

Create a LogPipeline CR for the Istio access logs

Referred from kyma-project.io documentation about istio access logs.

Istio access logs provide fine-grained details about the traffic when accessing the workloads that are part of Istio service mesh. The only prerequisite is to enable Istio sidecar injection for your workloads. The Istio access logs provide useful information relating to 4 golden signals, such as latency, traffic, errors, and saturation as well as any troubleshooting anomalies.

To create the LogPipeline, run:

kubectl apply -f https://raw.githubusercontent.com/SAP-samples/kyma-runtime-extension-samples/main/sap-cloud-logging/k8s/logging/logs-pipeline-istio-access-logs.yaml

This is an example of the LogPipeline configuration used for this blog post:

View the logs

You can access the SAP Cloud Logging instance dashboard. The access details are available in the Secret generated by the service binding.

The simplest way to start exploring the logs is to navigate to Discover and choose the appropriate index.

You can choose the index pattern to view the relevant logs, apply a filter or search term to narrow down your search or use other Open Search capabilities.

We will talk more about metrics in one of the next blog posts. However, I would like to bring your attention to the Four Golden Signals dashboard. It is provided out of the box and is based on the Istio access logs which we configured previously.

For reference, check out the generic and latency dashboards.

Now you can start exploring your application as well as the access logs.

Stay tuned for the next blog post about shipping traces from SAP BTP, Kyma runtime to SAP Cloud Logging.

BCP: Business Continuity Planning for SAP S/4HANA - made easy with Enterprise Blockchain 🚀

2024-03-26T20:33:44.142000+01:00

The Threat - Why do we have to care for Business Continuity Planning ?

In most large Enterprise IT we have the High Availability, we have the Disaster Recovery, so why do we have to care for Business Continuity Planning ? Business Continuity Planning is that one layer higher than HA and DR, Business Continuity Planning comes in to play when HA and DR don't solve the problem.

Cincinnati Insurance Companies have a made a very useful Business Continuity Threat Matrix to help Enterprises identify the threats across all dimensions of their business:

This is the thing with Business Continuity Planning and the threats and the risk and the why to do it, a Business Continuity situation can come individually from different angles, or alternatively it could be the contagion of a number of unrelated events which when combined together lead to the Business Continuity situation.

Gartner in their Glossary describe it as:

For me, coming from the SAP Enterprise Technical Architecture side of the house,

Business Continuity Planning is about The Data

At the heart of the Business Continuity Plan there needs to be Business Data

No Data - No Business !

Every Enterprise has a Business Continuity Plan, and SAP has got a whole library of helpful document on it over here to help with designing the Business Continuity Plan:

The Solution for Protecting Business Critical Data for the Business Continuity Plan

This blog is going to walk through and show, how very easily, and cost effectively and robustly and simply a basic Enterprise Blockchain can provide the "sleep well at night" technical foundation of a Business Continuity Plan solution.

This is one of my favourite easy peasy Enterprise Blockchain use cases, it is sooo easy to implement for SAP S/4HANA Customers using their SAP technologies, including the SAP BTP, and so simple, and so effective, and it really shows from the perspective of the Business Requirements and the Enterprise Blockchain capabilities how natively out of the box Enterprise Blockchain Databases are so secure and so resilient.

In this blog we will focus on the heart of the holistic Business Continuity Plan, and that is the Data, Master and Transaction.

A sound Business Continuity Plan will include a solution to enable OCD Operationally Critical Data to be available to Key Users in the event of a Business Continuity Scenario.

What is Operational Critical Data? OCD is critical data required to execute to Key Business Processes as defined in BCP playbook. A Business Continuity Scenario would mean that the Company is without access to the S/4HANA for period of up to 4 weeks (or more), along with which there must be a guarantee of business continuity on the most critical operations and availability of the (OCD).

All Enterprises need to be prepared for a Business Continuity Scenario, where the Company will be running in Emergency Mode, kind of like when a car goes in to Emergency Mode, the car drives, but the car does not perform to the full possibility. We are happy the car is running and we are happy that we can still use the car.

And this would be the same for Company in a Business Continuity Scenario, not everything in the Enterprise IT will be available, the S/4HANA, the Digital Core, in the worst case could be down for up to 4 weeks, but, what needs to be available is the most basic foundational Business Master and Transactional Data. And that most basic foundational Business Master Data is the Business Partner Master Data, the Customers and Suppliers, the most basic Data which any Company depends on to operate, large or small, you need to know who your Customers are and who your Suppliers are.

Requirements for a Business Continuity Planning solution would look something like this:

Blockchain SAP Business Continuity Planning Requirements atkrypto.io

With the Business Requirements in hand, the next step in the SAP Enterprise Architect Demand Process would be to make an Architecture Review of the Demand from the Business Lead.

The first step of the Architecture Review takes the Business Lead's non-Functional requirements, and matches them to the Enabling Technology Capabilities:

Blockchain SAP Business Continuity Planning Requirements Technology Capabilities Analysis atkrypto.io

Now that we have the key Enabling Technology Capabilities we can look in our SAP Enterprise Technology Standards and see which of our Technology Standards would be the most appropriate to enable the non-Functional Requirements.

The required Enabling Technology Capabilities are as follows:

SAP Blockchain Required Enabling Technology Capabilities atkrypto.io

Looking through our Technology Standards, when we "Let the Use Case find the Blockchain" we find 1 Technology Standard which meets the non-Functional Enabling Technology requirements, and that is, The Enterprise Blockchain Platform.

The Enterprise Blockchain Platform and the Enterprise Blockchain Database have all of these non-Functional requirements Enabling Technology Capabilities natively built in and out of the box.

We can consider potential alternatives, but, what is so special about Blockchain Databases and Enterprise Blockchain Platforms, and this was discussed in the previous blogs, is that, out of the box, natively, traditional Database Products do not have the characteristics that the Blockchain Databases have:

atkrypto.io what is a blockchain

For our Business Continuity Business Demand, the requirements are solved out of the box natively by the Enterprise Blockchain Platform.

Immutable, tick that box, the Blockchain Database has immutability built in.

Resilience and availability, tick that box, the Blockchain Database Platform is distributed and decentralised, again we have this requirement baked in to the capabilities of the platform.

As discussed in the previous blog, [ SAP Enterprise Architecture: Positioning Blockchain Database as an Enterprise Technology Standard

] when we look in to our Enterprise Architecture Technology Standards we see there is only 1 Technology Standard in the Enterprise which is positioned with the capabilities to fulfill all of those requirements out of the box, and that is the, Enterprise Blockchain Platform and Enterprise Blockchain Databases.

Comparison Enterprise Blockchain Database and Traditional Legacy Database - atkrypto.io

Back to the Business Requirements for the Business Continuity Planning solution:

Availability of data across three Continents, we can tick that box, we can install the Enterprise Blockchain Platform on SAP Business Technology Platform BTP Kyma Runtime Service on three separate SAP BTP Instances running in three different continents. We could install the SAP BTP on a Cloud Provider in the USA, we could install SAP BTP on a Cloud Provider in Europe, and we could install the SAP BTP on a Cloud Provider in Asia. And what's more, in each Continent we could use a different Cloud Provider, so we could for example have SAP BTP on AWS in the USA, SAP BTP on Azure in Europe, and SAP BTP on Google Cloud in Asia, this way we would take the resilience and diversification of Cloud Providers to an even higher level, and that's one of the beautiful flexibilities of the SAP BTP.

Let's just pause on that one, one of the most beautiful things about the SAP BTP is, it is so easy to set up, to spin up the SAP BTP, and when you are spinning up the SAP BTP, you get a list of Cloud Providers that you can set it up on, Google Cloud, Azure, AWS and others, and you just click the one you want and press go.

This is something very special, amazing, because, you are able to spin up your SAP BTP on pretty much any of the largest Cloud Providers, and...... without having to onboard that Cloud Provider as a Vendor ! Because SAP have done that bit for you, SAP have taken care of onboarding the Cloud Providers as a Vendor and you just select the one you want.

Anybody who has gone through, or has to go through, the process in the Large Enterprise of onboarding a new Vendor will know first hand how painful that is, and how elegant and nice it is that SAP have done that for you with the BTP.

That's one dimension, but in this Business Continuity Scenario it goes further than that. We have said we will spin up the SAP BTP in three Regions, three Continents, and by spinning up the SAP BTP on a different Cloud Provider in each Continent, each Region, and then running the Blockchain on the BTP across those Cloud Providers we build in even more resilience because we make our solution Multi-Cloud !

Regarding the Security requirement, the Data Store should be secured to the highest level possible, we can tick that box as well, Blockchain Databases out of the box are not only immutable, but also have the Hash Mechanism and the Consensus Mechanism, which no other Database Products on the planet have natively. The Consensus Mechanism and the Hash Mechanism of Blockchain Databases raises the bar of built in security hardening to a level never seen before natively in Enterprise Database Products.

And finally, the S/4HANA Data will be sent to the Enterprise Blockchain Platform which is running on SAP Business Technology Platform kyma Runtime Service because of the four dimensions which were discussed in the previous blog, why place the Enterprise Blockchain Platform in the SAP BTP ?

It's very very simple....

Proximity to the Data (of the Digital Core)

Ethnicity of the Data (in the Digital Core)

Proximity to the Process(es) (in the Digital Core)

Proximity to the Technology (of the Digital Core)

So, we're following our Company's Demand Process, we've taken the Business Demand, and the Requirements, we have processed them according to our Company's Enterprise Architecture Demand Process and we have identified by matching requirements to Enabling Technology capabilities that the Technology Standard which we have in the house to fulfill these Requirements is the Enterprise Blockchain Database Platform.

The next step is to design the Solution Architecture, the Technical Solution Architecture and show the options for fulfilling this requirement.

The basics of the Technical Solution Architecture are:

. SAP S/4HANA contains Business Partner Master Data

. Every time Business Partner Master Data changes we need to send it to the Enterprise Blockchain Database Platform

. The Enterprise Blockchain Platform Tenant will run on the SAP Business Technology Platform Kyma Runtime Service

. The Enterprise Blockchain Platform Tenants will be deployed in three SAP BTP locations around the world

. The Enterprise Blockchain Platform Tenants will be deployed in each location on the SAP BTP on a different Cloud Hyperscaler

In terms of SAP Enterprise Technical Architecture it is pretty clear what the Solution Options are, and we will draw all of the Solutions Options here in the blog, but one variable, one open question which we haven't solved yet, is how to get the Business Partner Master Data out of S/4HANA and to the Enterprise Blockchain Platform.

To solve this, to get the Data from the S/4HANA there are a number of options, and in this blog we will focus on:

. Events - Event Driven Blockchain [this will need the SAP Advanced Event Mesh]

. API's - API Driven [this will need CI to call the Business Partner API on S/4 and then call the API on the Blockchain]

we will now elaborate the Technical Solution Architecture of both alternatives, Event Driven Blockchain, and, API Driven Blockchain.

Business Continuity Planning Technical Solution Architecture SAP S/4HANA, Events, Enterprise Blockchain Platform

in this option, the SAP S/4HANA is connected to the SAP Advanced Event Mesh running on the SAP BTP. SAP S/4HANA publishes a Business Partner Event including the Data, the Payload of the Event to the SAP Advanced Event Mesh on the SAP BTP. The SAP Advanced Event Mesh on the SAP BTP has Topics and Queues created and puts the Business Partner Event and Data into one of the Queues. The Enterprise Blockchain Platform which is running on the SAP BTP Kyma Runtime Service is connected to the SAP Advanced Event Mesh Queue as a Subscriber and listens for new Business Partner Data arriving. As soon as the new Business Partner Data arrives in the Queue the Enterprise Blockchain Platform places that Data as a new Block in the Enterprise Blockchain Database.

S/4HANA on SAP RISE PCE on Azure in Europe -> SAP BTP Advanced Event Mesh Azure (Europe) ->

-> SAP BTP Advanced Event Mesh on SAP BTP on AWS Europe

-> Enterprise Blockchain Platform on SAP BTP Kyma Runtine on AWS Europe

-> SAP BTP Advanced Event Mesh on SAP BTP on Azure USA

-> Enterprise Blockchain Platform on SAP BTP Kyma Runtine on Azure USA

-> SAP BTP Advanced Event Mesh on SAP BTP on Google Cloud Platform Asia

-> Enterprise Blockchain Platform on SAP BTP Kyma Runtine on Google Cloud Platform Asia

SAP Event Driven Blockchain Advanced Event Mesh Multi Cloud Business Continuity Planning atkrypto.io

The picture clearly shows the distributed Regional/Continental resilience of the solution, and the Multi-Cloud resilience of the solution.

Business Continuity Planning Technical Solution Architecture SAP S/4HANA, API's, Enterprise Blockchain Platform

in this option, the SAP S/4HANA is connected to the SAP BTP Cloud Integration running on the SAP BTP. A Periodic Job running on SAP Cloud Integration calls the Business Partner API on SAP S/4HANA and gets the latest Business Partner Data Changes. SAP BTP Cloud Integration then calls an API on the Enterprise Blockchain Platform which is running on the SAP BTP Kyma Runtime Service and puts the new Business Partner Data on to the Enterprise Blockchain.

SAP BTP Cloud Integration (Europe) calls an API on -> S/4HANA on SAP RISE PCE on Azure in Europe

SAP BTP Cloud Integration then calls an API on the Enterprise Blockchain Platform

-> Enterprise Blockchain Platform on SAP BTP Kyma Runtine on AWS Europe

-> Enterprise Blockchain Platform on SAP BTP Kyma Runtine on Azure USA

-> Enterprise Blockchain Platform on SAP BTP Kyma Runtine on Google Cloud Platform Asia

SAP API Driven Blockchain Integration Suite Cloud Integration Multi Cloud Business Continuity Planning atkrypto.io

The picture clearly shows the distributed Regional/Continental resilience of the solution, and the Multi-Cloud resilience of the solution.

Wrapping up, the goal of this blog, was to remind us all, that if we happen to have fallen in to the bad habit of trying to find a Use Case for the Blockchain, not to worry, but at the same time, forget doing that, and get back to doing Enterprise IT Architecture the way we always have done and with proven Demand Evaluation Processes which will always lead the Business Demand to the most appropriate Enabling Technology Standard, and therefore, let the Use Case find the Blockchain instead of the Blockchain finding the Use Case.

There are many many Use Cases where Blockchain is the obvious choice for the Enabling Technology Standard.

In my opinion, Business Continuity Planning, is one of the many, a "no brainer" Use Case, for the Enterprise Blockchain Platform.

Business Continuity Planning is one of my favourite Use Cases for Enterprise Blockchain, it is so simple, so elegant, and everything is done for you. Less than 10 years ago, to achieve the same resilience and security as an Enterprise Blockchain Platform would have required a shopping list of software and procedures, some automated, some human. And this is the beauty of the Blockchain Technology.

This S/4HANA and SAP BTP and Enterprise Blockchain use case is for me, the boiling an egg equivalent of Enterprise Blockchain Database implementations, it is so simple, so elegant, so easy to set up, and so brings out why the Enterprise Blockchain Platform is so special.

Wrapping Up

To wrap up, a simple reminder,

The Digital Transformation of Information Security is Enterprise Blockchain

Enterprise Blockchain is the Next Generation Data Integrity, Originality, Confidentiality Protection

Enterprise Blockchain, Enterprise Distributed Ledger Technology is re-imagining information security

If you want the easiest, simplest, most resilient foundation to an Enterprise Business Continuity Planning Solution, just send your S/4HANA Operational Critical Master and Transaction Data to The Enterprise Blockchain. voila.

And ultimately, this is all Why I love SAP and Blockchain Databases and why you should too 🚀.

In the next blogs, week by week I will be blogging Use Cases, the blogs will follow a template where the Business Demand, the Use Case is discussed, the Architecture Demand Process will be followed and the outcome will show, week by week, Use Case by Use Case, why Blockchain is the best Enabling Technology Standard for that Use Case and Demand. The blogs will also describe all of the Solution Architecture Options.

If you have a Use Case you would like illustrated, let me know in the comments and I will blog the Solution Architecture.

So what are we waiting for ? Oh yeah, more use cases, ok, that will continue in the next blog This blog is the sixth in the series, the previous blogs are here, here, here here and here.

For now, over and out.

Andy Silvey.

Independent SAP Technical Architect and CEO of atkrypto.io

Author Bio:

Andy is also co-Founder of atkrypto inc, an startup whose ambition is to make Blockchain easy for Enterprise.

atkrypto.io's flagship product is the atkrypto Enterprise Blockchain Platform for SAP, and atkrypto.io is a SAP Partner Edge Open EcoSystem Partner.

All of this makes atkrypto,io the DePIN Decentralised Physical Infrastructure Network solution for Enterprise.

SAP HANA Cloud provisioning in Kyma Runtime Environment

2024-03-29T12:03:21.269000+01:00

In the earlier releases of SAP HANA Cloud, it was exclusively associated with Cloud Foundry runtime. Currently, SAP HANA Cloud currently supports Cloud Foundry, Kyma and also Runtime Independent provisioning of instances in SAP Business Technology Platform(BTP). In this blog we will be looking at the steps involved in provisioning and maintaining a SAP HANA Cloud instance in Kyma Runtime Environment.

Kyma is a Kubernetes based application runtime offered by BTP. It is based on modular building blocks, which contains the capabilities to run cloud-native applications. Every Kyma environment runs on a single Kubernetes cluster created specifically for your subaccount. Its environment consists of Kubernetes cluster based on project Gardener which sits on top of a cloud provider and data center of your choice. With the help of available modules, you can install the required modules to run your applications on the provisioned cluster.

Here, we will be focusing on the following areas: Prerequisites: Installing BTP Service Operator, Creating a SAP HANA Cloud Instance and Managing Instance in SAP HANA Cloud Central.

Note:
Here I am considering that you already have an SAP BTP global account with a subaccount(Subaccount Administrator Role Collection should be present for your user in the subaccount) that has entitlements and quota for SAP HANA Cloud, including "hana" plan. If not, refer Getting a Global Account, View and Manage Services from the Service Marketplace, and Managing Entitlements and Quotas Using the Cockpit.

Prerequisites
Before we go ahead with HANA Cloud provisioning in Kyma, there are few prerequisite steps that needs to be addressed. Firstly, the Kyma runtime environment has to be enabled for your subaccount. Next, in order to access the Kyma dashboard and then to install modules, create service instances, service bindings etc., RBAC(roles-based access control) permissions are to be given to the user. Finally, the BTP Service Operator module needs to be installed in your cluster to create the Service Instances and Service Bindings.

Setup of Kyma environment:
To setup Kyma environment on your subaccount, follow the steps mentioned in Create the Kyma Environment Instance. Once the setup is done, you should be able to see the Kyma Environment in the Overview section of your Subaccount.

You can access the Kyma dashboard using the Console URL link in the Kyma Environment section.

Configuring Kubernetes RBAC:
In order to create Service Instances and Service Bindings, Role Based Access Control permissions should be configured for your user in the Kubernetes cluster. Follow the steps mentioned in Assign Roles in the Kyma Environment to configure the permissions.

Installing BTP Service Operator(BTP SO):
BTP Service Operator is a free and open source software developed by SAP. It helps in provisioning, binding instances by communicating with the Service Manager that uses the service broker API to communicate with the Service brokers. In SAP BTP Kyma runtime, the btp-operator module is available as part of Kyma modules. You can follow the below steps to enable btp-operator module.

Launch the Kyma dashboard by opening the Console URL link. In the home page, Select Modify Modules.

Select Edit --> Under Modules section, check the btp-operator module --> Click Save.

Go back to Home page of the Kyma Dashboard by selecting Back to Cluster Details, then select Namespaces --> default. You should be seeing the item Service Management in side navigation as shown below.

Now you can go ahead and start creating a SAP HANA Cloud instance.

Creating a SAP HANA Cloud instance
In this section, we will be creating a HANA Cloud instance using the Service Instances(under Service Management) and also using the Upload YAML option.

Service Instances option:
Select Service Instances(under Service Management) --> Create
In the Create Service Instance section, provide the form details. The mandatory fields to be provided are for:
Name - Name of your HANA Cloud instance
Offering Name- Name of the service offering. In this case "hana-cloud"
Plan Name - Name of the service plan. In this case "hana"
Instance Parameters - Parameters required to create the instance. This has to be given in JSON format.
An example of the basic parameters is given below:

{
	"data": {
		"edition": "cloud",
		"memory": 32,
		"systempassword": "<give your password>"
		}
}

After giving the required details, select the Create option. You can check the status of the instance creation in Service Instances page. Also you can check under YAML in Edit section to check the ongoing progress of the instance creation.

Upload YAML option:
We can also create HANA Cloud instance similar to the approach that we use for creating Kubernetes resources through YAML. Go to the Namespace Overview for default namespace. Select the Upload YAML option and provide the YAML content to create the HANA Cloud instance. Here is an example of the YAML data:

apiVersion: services.cloud.sap.com/v1
kind: ServiceInstance
metadata:
  name: yaml-inst
  labels:
    app.kubernetes.io/name: yaml-inst
    annotations: {}
    namespace: default
spec:
  serviceOfferingName: hana-cloud
  servicePlanName: hana
  parameters:
    data:
      edition: cloud
      memory: 32
      systempassword: <give your password here>

After entering the YAML content, Select Upload.

The status of the instance creation can be checked in the Service Instances page.

Managing the Instance in SAP HANA Cloud central

Now the HANA Cloud instance is created successfully, you can perform Monitoring and Administration from SAP HANA Cloud Central.

This blog covers the high-level overview of SAP HANA Cloud instance creation in Kyma runtime environment. You can find more details in help guide: Help Documentation. In case you have any questions, please comment below.

sh: 1: fiori: not found-> The most popular error for Fiori Developers

2024-04-05T16:34:00.137000+02:00

Introduction:

In this technical blog, we will detail how to resolve one of the most common issues encountered by SAP UI5/Fiori developers during the deployment of their applications on the Cloud Foundry of SAP BTP.
For the case here, we have the "sh: 1: fiori: not found" error here.

Prerequisites:

SAP BTP Account- If you prefer to deploy on SAP BTP HANA Cloud.
SAP Business Application Studio (recommended) if deploying to SAP BTP HANA Cloud. Even, in this case, I recommend to use SAP BAS only for deployment .
Microsoft Visual Studio Code (optional) can be used for development but specific to this solution just use it as the Integrated Development Environment (IDE).

Delving into the Error:

Single Targeted vs. Multi-Targeted Applications: There exists a distinction between single targeted and multi-targeted applications. The issue at hand typically arises with .MTAR applications, particularly SAP UI5 multi-target applications.

"sh:1: Fiori: Not Found" Error: Whenever "cf push" command is executed, developers often encounter the "sh: 1: Fiori: Not Found" error, particularly with MTAR applications. This error is not exclusive to SAP but is a common occurrence across various cloud-native applications.

Solutions and steps to be followed:

Utilize Microsoft Visual Studio Code or SAP Business Application Studio as the IDE: It's recommended to use either Vs Code or SAP Business Application Studio solely as the Integrated Development Environment (IDE). For deployment purposes, stick to SAP Business Application Studio.
Ensure Proper Configuration of Destination Services and HTML5 Services: Make sure to follow the steps for creating Destination Services and HTML5 services in your application as per the provided guidelines.
Perform .MTAR Build: Right-click on the mta.yaml file and execute a .MTAR build.
Discovering Generated .MTAR File: Following the .MTA.YAML build, the generated .mtar file may have a generic name such as abc_appname.mtar.
Deploy .MTAR File: Right-click on the generated .mtar file and select "Deploy MTAR."
Monitor Deployment Process: Once the deployment process concludes, log in to the SAP BTP Cloud Cockpit.
Accessing applications: In the left-hand menu bar, locate HTML5 applications.
Verify Deployed Applications: You should be able to find the deployed applications listed within the HTML5 applications section.

Reference Link for more steps on deployment of Multi Target Applications by SAP: Building and Deploying Multitarget Applications

By following these steps, you can effectively resolve the "sh: 1: fiori : Not Found" error encountered during the deployment of SAP UI5/Fiori applications on the Cloud Foundry of SAP BTP.

Trustable AI thanks to - SAP AI Core & SAP HANA Cloud & SAP S/4HANA & Enterprise Blockchain 🚀

2024-04-11T12:51:09.466000+02:00

This blog is the seventh in the series and discusses what AI and and SAP and Enterprise Blockchain are, why they are so important for each other, and then takes a deep dive in to the SAP product oriented reference architecture of how to implement SAP AI Core and S/4HANA and Enterprise Blochchain.

What will it take to make AI trustable ?

tl:dr

SAP Artificial Intelligence SAP AI Core SAP HANA Cloud SAP S4HANA Enterprise Blockchain - atkrypto.io

Enterprise Blockchain is the Cyber Security for Enterprise AI. 🚀

This blog introduces the Enterprise Blockchain Wallet and Off-Chain data storage and demonstrates why it is so special and important for protecting the trustworthiness and reliability and integrity and originality of information and data, be patient and read on because the Enterprise Blockchain Wallet is something very special and enables us to protect large and unstructured data very simply and effectively and is one of the biggest reasons why an Enterprise Blockchain Database is so suited to protecting data for AI operations

The blog is going to break the subject down in to three sections:

Section 1.0: The What is it of SAP AI, and Enterprise Blockchain

Section 2.0: The Why is it, of SAP AI, and Enterprise Blockchain

Section 3.0: The How is it, of SAP AI, and Enterprise Blockchain

A huge amount has been written about both Artificial Intelligence and Enterprise Blockchain and there is no point to repeat everything here, so we will talk briefly about the subjects and then point to very useful resources for further reading, and focus our attention on why Enterprise Blockchain makes Artificial Intelligence trustable, and how to do it.

Section 1.0: The What is of SAP AI, and Enterprise Blockchain

What is Artificial Intelligence ?

What is the History of AI ?

and SAP has an amazing AI powered product roadmap, taking the product portfolio...

. from a System of Record

. through being a System of Engagement

. to being a System of Intelligence

What AI can do for the Enterprise, and where AI is going, massive opportunities are coming along, and it is happening all around us as we speak, this technology revolution is not on presentations, it is real and we can implement it and benefit from it right now, today. SAP's AI capabilities are growing by the day:

Like everything else we do in Enterprise IT,

AI is about Data

What is Enterprise Blockchain ?

Enterprise Blockchain is both:

. a Secure Store

. a Secure Communication Channel

In these previous blogs, I made a deep dive in to what Enterprise Blockchain is and why we should be positioning it in our Enterprise Architecture:

Why I love SAP and Blockchain Databases and why you should too 🚀

SAP Enterprise Architecture: Positioning Blockchain Database as an Enterprise Technology Standard 🚀

SAP Enterprise Architecture: Let the Use Case find the Blockchain🚀

and in a nutshell, Enterprise Blockchain is:

. The Digital Transformation of Information Security

. The Next Generation Data Integrity, Originality, Confidentiality Protection

. Re-imagining Information Security

. Natively, out of the box, due to its special characteristics the strongest, hardest, most resilient Enterprise Database product

To wrap up this section:

. AI is about Data

. Enterprise Blockchain is about Security of Data

Section 2.0: The Why is it, of SAP AI, and Enterprise Blockchain

SAP say it themselves, building trust in AI, means the AI has to be:

. Relevant

. Reliable

. Responsible

What is AI's biggest risk ?

AI's biggest risk is that the Data behind the AI is not trustworthy. In the same way as asking the wrong person for directions can leave you going all around the houses, if the Data behind the AI, and this means the Models as well, has been changed/contaminated/modified/poluted/made unreliable, whether purposefully through malicious acts or cyber attack, or accidentally, the result will be AI insights which cannot be trusted, and the result of that could be catastrophic.

Gartner remind us of this, when they describe the 4 key initiatives to get your Enterprise AI ready, and number 2 is AI Cyber Security:

AI is about the Data

So, if we are going to do AI, then we need to care for and protect the Data that the AI is using.

Imagine, as described in the previous blog, when we let the Use Case find the Enterprise Blockchain, we have a Business Requirement, a Business Demand, to make AI trustable to make AI achieve as SAP put it, the three R's, Relevant, Reliable, Responsible:

In the US, NIST, the National Institute of Standards & Technology have a whole section dedicated to AI and risks with AI. The biggest risk to AI is the trustworthiness of the data:

When we look in our Enterprise Technology Standards, and we look for the Technology Standard in our Enterprise Portfolio which is positioned to bring the strongest protection to Data, we find the Enterprise Blockchain.

Comparison Enterprise Blockchain Database and Traditional Legacy Database - atkrypto.io

In the previous blogs, we have discussed in detail about the special characteristics of Enterprise Blockchain and just why it natively out of the box protects the integrity of data to a level that legacy database products cannot do, in a nutshell....

AI is about Data

AI is about the Data that goes in to the AI engine

This means AI depends on a Database or a Datastore

What kind of Database does AI need ? What capabilities does the Database for the AI Data need to have ?

1. It must not be possible to modify the Data in the Database which feeds the AI - the Database needs to be immutable

2. The Data in the Database, the integrity and originality of that Data must be protected to the highest level that is technically possible

3. The Data must be available with the highest availability, the Database must be resilient to attack

When we look in our Enterprise Technology Standards we find 1 Technology Standard in the Enterprise which has those capabilities, and that is..... Enterprise Blockchain

Enterprise Blockchain ticks those three boxes...

✅Immutable - tick that box

✅Integrity must be protected to the highest level - tick that box, thanks to the Enterprise Blockchain Hash Mechanism and the Enterprise Blockchain Consensus Mechanism

✅Highest level of resilience and availability - tick that box thanks to the Distributed and Decentralised nature of the Enterprise Blockchain

This is why, Enterprise Blockchain is the enabler of trustable outcomes from Enterprise AI.

atkrypto.io what is a blockchain

But there's more than that, AI, and especially during the AI Training, AI needs a lot of data, and that's why SAP AI Core uses SAP HANA Cloud (Data Lake) as the Data Source, because the volumes of data for training are big.

And this is why, in this blog we take the Enterprise Blockchain Technology story one level further and we introduce the:

Enterprise Blockchain Wallet

Off-Chain Data Storage

In the Enterprise Blockchain Platforms, the Enterprise Blockchain Wallet is used for Off-Chain storage of big data and in the following paragraphs we will explain why.

What is the Enterprise Blockchain Wallet, and what is Off-Chain Data Storage and why would we use them and why do we need them ?

As we have explained in a previous blog, the Enterprise Blockchain Database, the Distributed Ledger, can be looked at simply as a Database Table (which is replicated and synchronised across multiple Servers) and in principle it stores the Data like this:

Blockchain is a very simple form of database atkrypto.io

This is fine, and suited to what we call Structured Data, and as AWS nicely describe, Structured Data is information like words and numbers. This kind of data is perfectly suited to being stored in an Enterprise Blockchain Database and also a legacy Database. Examples of the data would Names, Addresses, Phone Numbers, Product Information etc.

But, AI Artificial Intelligence software, especially during the Learning requires large quantities of this information, this data, and in SAP AI Core the volumes, the amounts of data which are required for AI Learning are so big, and are often stored in what's called CSV, Comma Separated Values files, and these CSV files will are too big to be stored on the Enterprise Blockchain Database itself, and they are too big to be stored in a Legacy Database.

So, if we can't store the large CSV file in Enterprise Blockchain Database, then how, in an Enterprise Blockchain Platform do we store large files of Data ?

Voila.... bring in the Enterprise Blockchain Platform Wallet. The best Enterprise Blockchain Platform products include what is called the Enterprise Blockchain Platform Wallet, or to make it shorter, the Enterprise Blockchain Wallet.

The Enterprise Blockchain Wallet enables us to store large Data, like large Files safely and securely off the chain, or 'Off-Chain'.

But if we store the large Data files Off-Chain in the Enterprise Blockchain Wallet, then how do we also have them some how on the Enterprise Blockchain Database ?

The way this works is elegant, in any decent Enterprise Blockchain Platform, the Enterprise Blockchain Wallet location is completely configurable, and could be anywhere from SAP HANA Cloud (Data Lake), or for example multiple hyperscaler object stores, such as Amazon S3, OSS (Alicloud Object Storage
Service), SAP HANA Cloud, Data Lake, and Azure Blob Storage.

The configurable Enterprise Blockchain Wallet of the Enterprise Blockchain Platform looks like this:

Enterprise Blockchain Platform - Enterprise Blockchain Wallets - Configurable Enterprise Wallets - atkrypto.io

Ok, so we've got the AI Data stored in the (configurable) Enterprise Blockchain Wallet, but what about securing the AI Data ? Obviously the Enterprise Blockchain Wallet storage location has built in security, for example the SAP HANA Cloud, the AWS S3 Buckets, but we need more than the out of the box security of these products, the reason we are using the Enterprise Blockchain Database is because of the amazing security strengths that it natively out of the box has, and so, what about the Enterprise Blockchain Wallet, doesn't the Enterprise Blockchain Platform have some cool super hard way of protecting the data in the Enterprise Blockchain Wallet ?

Well yes it does, this is the magic of Enterprise Blockchain Database 'Off-Chain' storage in the Enterprise Blockchain Wallet. This is so unique to Blockchain Technologies.

What happens is this, when store data in the Enterprise Blockchain Wallet, the Enterprise Blockchain Platform software runs a hash algorithm over the data that we have stored and the data, and the large file gets hashed:

The data or the file in the Enterprise Blockchain Wallet gets hashed, and then, that hash is stored in the Enterprise Blockchain Database.

This means we now have a unique hash of that data or file, and if anybody or anything makes even the tiniest teeniest change to that data or file, next time we run a hash over that data or file the result will be different that the original hash which is safely stored in the Enterprise Blockchain Database and this is how we will know that the data has been changed and we cannot trust the Data and therefore we cannot use it for our Enterprise AI.

On the other hand, if just before we load the data in to the Enterprise AI from the Enterprise Blockchain Wallet, if we run a hash over the data and the hash result is the same as we have in the Enterprise Blockchain Database, then we will know we can trust the Data and we can use it in our AI and we will have trustable AI.

Enterprise Blockchain Wallet Data Hashes Stored in the Enterprise Blockchain Database - atkrypto.io

And this is why, for all of these reasons,

Trustable Enterprise AI depends on Data being stored in the Enterprise Blockchain

Outlier Ventures, in their AI Thesis, very nicely show how Enterprise Blockchain & Artificial Intelligence together solves the risks associated with AI alone:

To conclude this section, the Why to, of Artificial Intelligence and Enterprise Blockchain, Artificial Intelligence needs to be Reliable, Relevant, Responsible, for it to be Trustable.

Enterprise Blockchain, due to its native super strong security strength when used as a store of Data and Models for AI, enables AI to be Trustable.

Section 3.0: The How is it, of SAP AI, and Enterprise Blockchain

Now that we know why trustable Enterprise AI needs the Enterprise Blockchain Database to protect the integrity and originality of the Data and Models, how do we implement it today ?

Well that's easy, here are the ingredients and the recipe 😄

Ingredients, you're going to need:

Data Source(s) eg

S/4HANA and others

Enterprise AI Product

SAP AI Core

SAP AI Launchpad

Large Storage for Large Data and the Enterprise Blockchain Wallet

SAP HANA Cloud (Data Lake)

Enterprise Blockchain Platform

These are the basic ingredients, the data from the S/4HANA will be stored in the SAP HANA Cloud (Data Lake) which will also be the Enterprise Blockchain Platform (configurable) Wallet, the Enterprise Blockchain Platform, and then SAP AI Core to read the Data from the (SAP HANA Cloud - Data Lake) Enterprise Blockchain Platform Wallet and process it through Enterprise AI and turn it in to insights through the SAP AI Launchpad.

And your Technical Reference Architecture will look something like this:

SAP AI Core SAP S4HANA SAP AI Launchpad SAP HANA Cloud Data Lake Enterprise Blockchain Protection - atkrypto.io

And that's how you do it.

Wrapping up, conclusions:

. Trustable Enterprise AI depends on Data being stored in the Enterprise Blockchain

Enterprise Blockchain is:

. The Digital Transformation of Information Security

. The Next Generation Data Integrity, Originality, Confidentiality Protection

. Re-imagining Information Security

. Natively, out of the box, due to its special characteristics the strongest, hardest, most resilient Enterprise Database product

Enterprise Blockchain is both:

. a Secure Store

. a Secure Communication Channel

The configurable Enterprise Blockchain Wallet enables you to store Big Data 'Off-Chain' and the hashes of the Big Data are stored safely and securely on the Enterprise Blockchain Database.

So what are we waiting for ? Oh yeah, more use cases, ok, that will be the next blog.

What do you think, are the words AI, Blockchain, Web3, Distributed Ledger Technology, starting to appear in your Company's visions and technology visions ? What use cases are you looking at ? Let's chat about it in the comments.

For now, over and out.

Andy Silvey.

Independent SAP Technical Architect and CEO of atkrypto.io

Author Bio:

Andy is also co-Founder of atkrypto inc, an startup whose ambition is to make Blockchain easy for Enterprise.

atkrypto.io's flagship product is the atkrypto Enterprise Blockchain Platform for SAP, and atkrypto.io is a SAP Partner Edge Open EcoSystem Partner.

Kyma Integration with SAP Cloud Logging. Part 2: Let's ship some traces

2024-04-19T10:59:02.498000+02:00

In the first blog post of this three-part series, we talked about:

What is SAP Cloud Logging?
How to integrate it with Kyma runtime?
How to ship logs?

In this blog, we will explore:

Shipping traces from Kyma runtime to SAP Cloud Logging.
Using SAP Cloud Logging dashboard to view and leverage traces.

What is distributed tracing?

Distributed tracing is a method used to monitor and profile applications that span multiple services or components. It provides a detailed view of the flow of requests as they traverse through various parts of a distributed system. By capturing and correlating information about each request, distributed tracing enables developers and operators to understand the performance characteristics, latency bottlenecks, and dependencies within their systems.

Shipping traces from Kyma runtime to SAP Cloud Logging

SAP Cloud Logging based on OpenSearch supports ingestion of traces when having the OTLP ingestion mode enabled. It provides pre-integrated dashboards to introspect them easily.

The goal of the next steps is to establish a cluster-central gateway using the Kyma Telemetry module being connected to Cloud Logging.

Additionally, we enable Istio to propagate trace context for every incoming request and emit trace data to the central gateway. Also, we enable our application to instrument and emit trace data to the gateway.

Prerequisites

Steps

Configure Trace pipeline.

You must tell Kyma to ship the generated traces to the SAP Cloud Logging instance. This is done by creating a Trace pipeline. If you followed steps in the previous blog post, then you can simply run the following command, else adjust the name for secretKeyRef accordingly.

kubectl apply -f https://raw.githubusercontent.com/SAP-samples/kyma-runtime-extension-samples/main/sap-cloud-logging/k8s/tracing/traces-pipeline.yaml

For reference, this is what the TracePipeline looks like:

apiVersion: telemetry.kyma-project.io/v1alpha1
kind: TracePipeline
metadata:
  name: my-cls-trace-pipeline
spec:
  output:
    otlp:
      endpoint:
        valueFrom:
          secretKeyRef:
            name: my-cls-binding
            namespace: cls
            key: ingest-otlp-endpoint
      tls:
        cert:
          valueFrom:
            secretKeyRef:
              name: my-cls-binding
              namespace: cls
              key: ingest-otlp-cert
        key:
          valueFrom:
            secretKeyRef:
              name: my-cls-binding
              namespace: cls
              key: ingest-otlp-key

To learn more about TracePipeline and possible configuration options, check the resource documentation.

Next, you enable mesh level configuration using Istio Telemetry resource.

kubectl apply -f https://raw.githubusercontent.com/SAP-samples/kyma-runtime-extension-samples/main/sap-cloud-logging/k8s/tracing/trace-istio-telemetry.yaml

For reference, this is how the default telemetry configuration looks like:

apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: tracing-default
  namespace: istio-system
spec:
  tracing:
  - providers:
    - name: "kyma-traces"
    randomSamplingPercentage: 1.0

You can learn more about various options in the standard Istio documentation.

With this configuration, you enable tracing 1.0% of all requests that enter the Kyma runtime via Istio Service mesh. To optimize resource and network usage, it is important to set the sampling percentage value to a sensible default.

To understand how tracing is implemented in Kyma and what its architecture looks like, check the Kyma documentation.

NOTE: This would require an SAP Cloud Logging service instance. To find out how to create it, read the first blog post.

Viewing the traces

You can access the SAP Cloud Logging instance dashboard. The access details are available in the Secret generated by the service binding.

Next, to access the traces, you can navigate to:

Observability --> Trace Analytics --> Traces

You can also use various filter criteria to narrow down to the trace you are particularly interested in. The simplest one to use is the Service Name. It is the name of the Kubernetes Service which is associated with your microservice or function.

In case the response contains a request ID, you can always use it to find the corresponding Trace ID from the logs and use that as filter criteria.

This is particularly useful if you have enabled 100% tracing and want to troubleshoot a specific request.

Here is an example of using the request-id for a CAP application.

Examples

Here are some examples of how traces look for various scenarios:

A function calling an upstream microservice:

I would like to point out that Kyma serverless does the additional instrumentation of your function code for tracing, and the same is visible in the spans generated.

One microservice calling another upstream microservice:

A multi-tenant JavaScript CAP application:

CAP JavaScript supports instrumentation. You just need to add the following NPM packages to your CAP project, provided by SAP and open telemetry.

{
  "dependencies": {
    "@cap-js/telemetry": "^0.1.0",
    "@grpc/grpc-js": "^1.10.3",
    "@opentelemetry/exporter-metrics-otlp-grpc": "^0.49.1",
    "@opentelemetry/exporter-trace-otlp-grpc": "^0.49.1",
    .....
  }
}

You can learn more about cap-js/telemetry in npm package documentation as well as GitHub repository.

Instrumentation

As mentioned in the previous example, you can use the npm package cap-js/telemetry for a JavaScript-based CAP application. For other technologies, consider using the SDKs provided by OpenTelemetry.

Cloud Native Buildpacks + Java

If you are using cloud native buildpacks, then you can also consider enabling OpenTelemetry while building the docker image. Check out this example from OpenTelemetry. There is also information about Paketo Buildpack for OpenTelemetry

NOTE: The endpoints to which the traces and metrics need to be shipped are available in the Telemetry default custom resource. You can view them in kyma-system namespace under Kyma -> Telemetry

Istio sidecar trace generation

If you have Istio sidecar enabled, Istio takes care of generating Spans, linking them to traces when you make upstream calls to services in the Istio service mesh. The requirement is to pass the appropriate headers so Istio can do the linking and generate the trace / span details.

This can be achieved by:

Using one of the SDKs mentioned above. (Preferred option)
Or, manually passing the required headers.

Reference: Istio distributed tracing

If you would like to do manual propagation, you should take the incoming "x-request-id" and "traceparent" headers from the HTTP request and forward them when making upstream calls to other microservices running inside the same Kyma cluster and part of Istio service mesh.

Other scenarios

Similarly, for calls to DB e.g. to SAP HANA Cloud, you can consider using SDKs that do the instrumentation.

How can you benefit from using distributed tracing?

Distributed tracing is a powerful technique used to monitor and understand the behavior of complex distributed systems. By implementing distributed tracing, you can gain several benefits:

Troubleshooting and debugging: Distributed tracing allows you to track requests as they flow through various components of your system. This helps identify performance bottlenecks, latency issues, and errors, making it easier to troubleshoot and debug problems.
Performance optimization: With distributed tracing, you can analyze the timing and dependencies of requests across different services. This helps identify areas where performance improvements can be made, such as optimizing slow database queries, reducing network latency, or optimizing resource usage.
Service dependency visualization: Distributed tracing provides a holistic view of how different services interact with each other. This helps understand the dependencies between services and identify potential points of failure or bottlenecks.
Capacity planning: By analyzing the traces of requests, you can gain insights into the resource utilization patterns of your system. This can help in capacity planning, ensuring that your system is provisioned with the right amount of resources to handle the expected load.

Coming next

Stay tuned for the next blog on Shipping metrics to SAP Cloud Logging from Kyma runtime.

SAP BTP, Kyma Runtime internally available on SAP Converged Cloud

2024-04-19T11:33:15.943000+02:00

Hello Kyma community,

the Kyma team is happy to announce the SAP internal availability of SAP BTP, Kyma runtime on SAP Converged Cloud in the eu-de-1 region. This is the first stage of gradual enablement in non-restricted regions that should culminate in the general availability of Kyma on SAP Converged Cloud for all SAP customers. With that, we will do our part to deliver the SAP BTP Everywhere promise.

We started on this journey almost two years ago. The feedback we received from a limited pilot early last year guided our efforts towards delivering the best possible user experience to enable our customers to seamlessly adopt and benefit from SAP Converged Cloud. In turn, we ensure that our customers can start their migration efforts or new development today without additional effort or cost compared to major hyperscalers.

Right now, internal SAP teams can simply enable Kyma on SAP Converged Cloud via the SAP BTP Cockpit and start using the SAP BTP platform in the SAP Datacenter just like you would on the other hyperscalers. There is no need to manage infrastructure accounts and quotas, install and upgrade Kubernetes, or worry about infrastructure monitoring and security scanning. The Kyma team handles all day two operations related to infrastructure and available modules, so you do not have to.

You can immediately connect your applications to most SAP BTP services (from the nearby cf-eu20 region today) or SAP HANA Cloud instances even if the whole of BTP is not running on SAP Converged Cloud yet. We made sure that all currently available Kyma modules run smoothly and do not require specific configuration for SAP Converged Cloud.

There are some limitations we are working on. For example, it is not currently possible to set up the hyperscaler equivalent of VPC peering within or outside SAP Converged Cloud. Nor is it possible to connect to HANA Cloud instances via private networking (which is the case on hyperscalers as well).

Stay tuned for more updates, and give Kyma on SAP Converged Cloud a try in the meantime!

To learn more about SAP BTP, Kyma runtime please read and follow our other blogs, and visit the SAP BTP, Kyma runtime site.

Configure Custom SAP IAS tenant with SAP BTP Kyma runtime environment

2024-04-20T15:41:26.519000+02:00

This brief is to showcase how to get this done using a SAP BTP trial account.

Albeit, the entire procedure is well documented in SAP Help portal, namely under Configure a Custom Identity Provider for Kyma, the missing piece of the puzzle is the configuration of the identity provider application.

Any OIDC provider can be used as a custom OIDC provider with a kyma cluster. However, SAP BTP platform makes it both simple and affordable with the Always Free SAP Cloud Identity Authentication services.

From experience, this is is the most error-prone part of the procedure.
In order to alleviate the pain and burden of creating a SAP IAS service provider application I have prepared automation scripts that can be used entirely programmatically either from a kyma environment itself or directly from a BTP subaccount level.

Let's see how.

Table of Contents

prepare subaccount for kyma runtime with a custom IAS tenant

establish BTP subaccount trust with a custom SAP IAS tenant.

Kyma Environment.

Accessing Kyma Dashboard

PS.

1. The SAP IAS service provider application automation script for those you'd like to run it directly from a kyma dashboard.

A hint: You may want to replace all the placeholder values with the shoot name of a kyma cluster.

# Source: skr-easy/templates/binding-ias.yaml
apiVersion: services.cloud.sap.com/v1
kind: ServiceBinding
metadata:
  name: skr-ias-binding
  labels:
    app.kubernetes.io/name: skr-ias-binding
spec:
  serviceInstanceName: '<serviceInstanceName>' ##fee3078
  externalName: '<externalName>' ##fee3078
  secretName: skr-ias-binding-secret
  parameters:
    credential-type: "NONE" 
  parametersFrom: []
---
# Source: skr-easy/templates/service-ias.yaml
apiVersion: services.cloud.sap.com/v1
kind: ServiceInstance
metadata:
  name: '<name>' ##'fee3078'
  labels:
    app.kubernetes.io/name: '<label>' ##'fee3078'
spec:
  externalName: '<externalName>' ##fee3078
  serviceOfferingName: identity
  servicePlanName: application
  parameters:
    name: '<name>'                     ##'fee3078' ### name of the application created in IAS or the service instance id
    display-name: '<display-name>'     ##'shoot-name-fee3078' ### display-name of the application created in IAS
    home-url : '<home-url >'           ## 'https://$BTP_SUBDOMAIN.fee3078.kyma.ondemand.com'
    user-access: public ## allows for self-registration

    oauth2-configuration:
      grant-types:
        - authorization_code
        - authorization_code_pkce_s256
      token-policy:
        token-validity: 3600
        refresh-parallel: 3
        access-token-format: default

      public-client: true ## if set to true, enables PKCE flow for the application, where the client does not need to provide a credential.
      redirect-uris:
        - 'https://dashboard.kyma.cloud.sap'
        - 'http://localhost:8000'
    subject-name-identifier:      ## https://help.sap.com/docs/identity-authentication/identity-authentication/configure-subject-name-identifier-sent-to-application?locale=en-US
      attribute: mail ##userUuid
      fallback-attribute: none ##uid

    default-attributes:    ## https://help.sap.com/docs/identity-authentication/identity-authentication/configure-default-attributes-sent-to-application?locale=en-US
    
    assertion-attributes:  ## https://help.sap.com/docs/identity-authentication/identity-authentication/configure-user-attributes-sent-to-application?locale=en-US
      email: mail
      groups: companyGroups
      first_name: firstName
      last_name: lastName
      login_name: loginName
      mail: mail
      scope: companyGroups
      user_uuid: userUuid
      locale: language

2. Let's assume one needs to provision a kyma cluster with a custom IAS from the start.
In this case the SAP IAS service provider application must be created before the kyma environment is enabled.

SAP IAS service instance application plan parameters for those who need to enable a kyma cluster configured with a custom SAP IAS from the get-go:

{
        "name": "quovadis",
        "display-name": "quovadis",
        "user-access": "public",
        "oauth2-configuration": {
            "grant-types": [
                "authorization_code",
                "authorization_code_pkce_s256"
            ],
            "token-policy": {
                "token-validity": 3600,
                "refresh-parallel": 3,
                "access-token-format": "default"
            },
            "public-client": true,
            "redirect-uris": [
                "https://dashboard.kyma.cloud.sap",
                "http://localhost:8000"
            ]
        },
        "subject-name-identifier": {
            "attribute": "mail",
            "fallback-attribute": "none"
        },
        "default-attributes": null,
        "assertion-attributes": {
            "email": "mail",
            "groups": "companyGroups",
            "first_name": "firstName",
            "last_name": "lastName",
            "login_name": "loginName",
            "mail": "mail",
            "scope": "companyGroups",
            "user_uuid": "userUuid",
            "locale": "language"
        }
}

As the SAP IAS service provider OAuth2 application must be configured with the authorization code with PKCE grant type, one needs to provide the following service bindings parameters:

 {
    "credential-type": "NONE"
 }

The resulting binding will contain both the clientid and the issuer url. These values can be used directly with the kyma cluster provisioning wizard.

{
    "clientid": "f61*************",
    "url": "https://***.trial-accounts.ondemand.com",
}

From now on, one can update/create the kyma environment settings, either from the BTP cockpit or using the btp cli with the below json parameters (saved to a local config.json file)

{
    "administrators": [
        "email1@domain.com",
        "email2@domain.com",
        "emailN@domain.com"
    ],
    "oidc": {
        "clientID": "f61********************",
        "groupsClaim": "groups",
        "issuerURL": "https://***.trial-accounts.ondemand.com",
        "signingAlgs": [
            "RS256"
        ],
        "usernameClaim": "sub",
        "usernamePrefix": "-"
    },
    "name": "quovadis"
}

Eventually, the below script shows how to create a new kyma environment using btp cli with BTP Trial account, namely:

btp create accounts/environment-instance --display-name quovadis --environment kyma --service kymaruntime --plan trial --parameters config.json

Creating an environment instance for subaccount e691b16b-**********...

environment id:     B1A10B19-************
environment name:   quovadis
environment:        kyma
landscape:          
state:              CREATING
state message:      Creating environment instance.

Command runs in the background. 
Use 'btp get accounts/environment-instance' to verify status.

OK


btp list accounts/environment-instance

Showing environment details for subaccount e691b16b-*************:

environment name   environment id                         environment type   state   state message                   landscape   
*******trial       AA23C91E-************   cloudfoundry       OK      Environment instance created.   cf-ap21     
quovadis           B1A10B19-************   kyma               OK      Environment instance created.               


OK

and then how to dispose of it:

btp delete accounts/environment-instance B1A10B19-**************
Do you really want to delete the specified environment instance and all content? [no]> yes

Deleting environment instance B1A10B19-******** and all its data in subaccount e691b16b-***********...

environment name:   quovadis
environment id:     B1A10B19-***************
environment type:   kyma

Command runs in the background. 
Use 'btp list accounts/environment-instance' to verify status.

OK

Alternatively, a kyma environment update can be performed as well, for instance:

btp update accounts/environment-instance B1A10B19-******** --plan trial --parameters config2.json

Updating environment instance with ID B1A10B19-***********

OK

Please note it is not possible to amend the list of modules via a kyma environment update.

Mistral gagnant. Mistral AI and SAP Kyma serverless.

2024-04-20T17:53:48.035000+02:00

Mistral gagnant. Mistral AI and SAP Kyma serverless (nodejs) story.

Let me tell you my story.

I have come across Mistral AI as an alternative to OpenAI/SAP AI core.

And, very naturally, I wanted to be able to consume the Mistral Javascript Client from a backend service running on SAP BTP, Kyma runtime (which is the SAP's managed and business-friendly kubernetes offering) as a serverless function.

And here is how the story unfolded...

Table of Contents

Mistral gagnant.

Voila. C'est le mistral gagnant:)

PS.

Prompts examples:

MistralAI prompt: what is the best French dish?
The "best" French dish can depend on personal taste, but some of the most popular and renowned French dishes include:

1. Coq au Vin: This is a classic French dish where chicken is slow-cooked with wine, lardons (small strips or cubes of pork fat), mushrooms, and possibly garlic.

2. Bouillabaisse: Originating from the port city of Marseille, this is a traditional Provençal fish stew.

3. Escargots: Snails cooked in a garlic, butter, and parsley sauce, often served as an appetizer.

4. Ratatouille: A vegetable stew from Nice, usually made with eggplant, zucchini, bell peppers, tomatoes, and sometimes potatoes and onions.

5. Crème Brûlée: A rich custard base topped with a contrasting layer of hard caramel.

6. Tarte Tatin: A caramelized apple tart where the apples are cooked first in butter and sugar before the tart is baked.

7. French Onion Soup: Made with onions, beef broth, and usually topped with croutons and cheese.

8. Quiche Lorraine: An open pie with a filling consisting of a savoury custard with smoked lardons or bacon.

9. Steak Frites: A simple yet classic dish of a grilled or fried steak served with French fries.

10. Croissants: A buttery, flaky, crescent-shaped pastry that originated in Austria but became very popular in France.

MistralAI prompt: How to implement mTLS with SAP Kyma
Mutual Transport Layer Security (mTLS) is a method of authentication that uses digital certificates to verify the identity of both the client and server during a communication session. Implementing mTLS with SAP Kyma involves several steps, including creating a certificate authority (CA), generating and distributing certificates, and configuring your applications to use mTLS.

Here are the general steps to implement mTLS with SAP Kyma:

1. Set up a certificate authority (CA) to issue and sign the certificates. You can use a public CA, or set up your own private CA using tools such as OpenSSL or Certbot.
2. Generate a private key and certificate signing request (CSR) for each service or application that will use mTLS. You can use OpenSSL or Certbot to generate the private key and CSR.
3. Submit the CSR to the CA to obtain a signed certificate. The CA will verify the identity of the requestor and issue a signed certificate.
4. Configure your application or service to use the private key and signed certificate. This typically involves setting environment variables or configuration files in your application to point to the location of the private key and certificate.
5. Configure SAP Kyma to use mTLS. This involves setting up a custom domain for your application, configuring the Istio service mesh to enforce mTLS, and configuring any ingress gateways to require client authentication.
6. Test your mTLS implementation to ensure that it is working correctly. You can use tools such as curl or OpenSSL to test the connection between your client and server, and verify that the certificates are being exchanged and validated correctly.

SAP Kyma provides a built-in certificate authority called the Kyma Certificate Service (KCS) which can be used for generating and managing certificates for mTLS. You can find more information on how to use KCS in the SAP Kyma documentation.

Additional reading:

Piet Mondrian's artwork powered with AI with little or no code.

Real time access management with SAP BTP Kyma serverless workloads

2024-04-21T11:09:46.265000+02:00

Real time access management with SAP BTP Kyma workloads

Using kyma functions to handle the promotional events from campaigns defined in the SAP BTP Omnichannel Promotion Pricing integrated with SAP Commerce Cloud may be a rather challenging endeavour.The main reason being, the promotional events must be handled in a sequence and are subject to draconian time processing constraints (less than 600 milliseconds per event).

Let's see how this can be done.

Table of Contents

Further reading

PS.

IoT - Ultimate Data Cyber Security - with Enterprise Blockchain and SAP BTP 🚀

2024-04-22T11:07:39.454000+02:00

It wasn't that long ago that Cyber Security and Resilience translated to High Availability and Disaster Recovery. Driven by the Sensitivity, Confidentiality, and Availability requirements of the Data, Systems and Applications were built to have the highest possible availability. That requirement came from the times when an entire end to end Business Process ran in a single standalone Application.

Fast forward to today, end to end Business Processes can begin in one Application on one side of the world and pass through Applications somewhere else in the world and finish in Applications in an altogether different location in the world. The beginning of the Business Process can be Sensors and Things at the Edge, producing Data, Events, something has happened and triggered the Business Process.

This creates several problems:

Protect the Originality & Integrity of the Data - When the Thing, the IoT Sensor, let's say critical infrastructure, something like a Base Station in a Telco Network, or a piece of the Electrical Grid for a Utility Company, when the Thing, the IoT Sensor creates the piece of Data, a Record of something that just happened we need to make sure that piece of Data cannot be modified or destroyed and therefore protect the originality and integrity of the Data

Moving the Data from the Edge to the SAP Application in the Cloud or DataCenter and at the same time Protect the Originality & Integrity of the Data - we need to get the Data from the Thing, the IoT Sensor, to the SAP Application in the Cloud or DataCenter and we need to be sure, to have surety that the Data which arrives in the SAP Cloud or DataCenter is exactly the same Data that was created at the Edge at the Thing, the IoT Sensor. If this Data gets changed in any way, we won't be able to trust the Business Processes and Insights which are depending on that Data. And so, in the activity of moving the Data we need to make sure that that piece of Data cannot be modified or destroyed and therefore protect the originality and integrity of the Data

And so, here we are, the biggest threat to Enterprise SAP Applications is no longer the High Availability, the Server crashing, that's all under control and possible to take care of,

The biggest threat to IoT & Enterprise SAP Applications is Cyber Security and Cyber Attacks

A common thought is that a hacker, or cyber attacker wants to modify Data for their own financial benefit, for example change the destination bank account number for invoice payments, yes those threats are still there, but biggest threat is that a hacker or cyber attacker deletes or modifies Master and Transaction Data resulting that the Master and Transactional Data does not have integrity and cannot be used, and if the attacker succeeded to modify the Backup as well, then the Enterprise could be out of business for a long time trying to pick up the pieces and get up and running again.

The biggest threat to IoT & Enterprise SAP Applications is Cyber Attacks rendering the Master and Transaction Data un-trustworthy

And that's where the Enterprise Blockchain comes in, and this blog is going to explain why.

Ok let's go🚀

Welcome to the eighth blog in this series on Enterprise Blockchain and SAP. If you have been following the previous blogs then you'll be familiar with the blog template. We'll begin by talking about and framing the problem, in this case Data Cyber Security for IoT and SAP and then go in to identifying the enabling technology which will have the best capabilities and be the most appropriate to solving the problem all the way through to the reference solution architecture to be able to implement the solution.

The blog is going to break the subject down in to three sections:

Section 1.0: The What is it of IoT & SAP, and Enterprise Blockchain

Section 2.0: The Why is it, of IoT & SAP, and Enterprise Blockchain

Section 3.0: The How is it, of IoT & SAP, and Enterprise Blockchain

tl:dr

If you want to protect the originality and integrity and confidentiality of IoT data, from the Edge to Insights and SAP Business Processes, then the answer is an Enterprise Blockchain Database, where the Enterprise Blockchain Tenants are running on Edge Hosts/Servers and in the SAP BTP Business Technology Platform, enabling Enterprise Blockchain Database to protect the Data from the Edge Hosts/Servers to the SAP BTP.

IoT Internet of Things Edge Data Cyber Security and SAP Asset Performance Management BTP Protected by Enterprise Blockchain - atkrypto.io

[the finer technical details of getting the data from the Enterprise Blockchain to SAP Asset Management and S/4HANA will be clearer possibly after Sapphire Orlando in June. In the mean time there are a number of ways to get the Data in and out of the Enterprise Blockchain running on the SAP BTP Kyma Service]

Enterprise Blockchain is both:

. a Secure Store

. a Secure Communication Channel

Enterprise Blockchain is the Cyber Security for Enterprise IoT Data from the Edge to Insights 🚀

and now.... the long answer...

Section 1.0: The What is it of IoT & SAP, and Enterprise Blockchain

What is IoT Internet of Things ?

History of IoT

In 2021, there were over 10 billion IoT devices in the world, and by 2025, the IDC expects global data generation to exceed 73 zettabytes – which is equal to 73 trillion gigabytes. Although we can’t really quantify digital data in physical terms, we can say that if all that data were converted into 1990s floppy disks – and they were laid out end to end – they could go to the moon and back over 5,000 times.

[Source: What is IoT? The Future of Business | SAP]

What are some IoT applications?

Looking at IoT applications, which are sometimes described as use cases, can help ground the discussion about what IoT is. Broadly, IoT applications occur in one of nine settings.

Human health. Devices can be attached to or inserted inside the human body, including wearable or ingestible devices that monitor or maintain health and wellness, assist in managing diseases such as diabetes, and more.
Home. Homeowners can install devices such as home voice assistants, automated vacuums, or security systems.
Retail environments. Devices can be installed in stores, banks, restaurants, and arenas to facilitate self-checkout, extend in-store offers, or help optimize inventory.
Offices. IoT applications in offices could entail energy management or security for buildings.
Standardized production environments. In such settings, including manufacturing plants, hospitals, or farms, IoT applications often aim to gain operating efficiencies or optimize equipment use and inventory.
Custom production environments. In customized settings like those in mining, construction, or oil and gas exploration and production, IoT applications might be used in predictive maintenance or health and safety efforts.
Vehicles. IoT can help with condition-based maintenance, usage-based design, or presales analytics for cars and trucks, ships, airplanes, and trains.
Cities. IoT applications can be used for adaptive traffic control, smart meters, environmental monitoring, or managing resources.
Outside. In urban environments or other outdoor settings, such as railroad tracks, autonomous vehicles, or flight navigation, IoT applications could involve real-time routing, connected navigation, or shipment tracking.

Other real-world examples abound. IoT solutions are being used in myriad settings: in refrigerators, to help restaurants optimize their food-compliance processes; in fields, to track livestock; in offices, to track how many and how often meeting rooms are used; and beyond.

What is the economic impact of IoT?

The potential value of IoT is large and growing. By 2030, we estimate it could amount to up to $12.5 trillion globally. That includes the value captured by consumers and customers of IoT products and services.

The potential economic value of IoT differs based on settings and usages, with factory settings and human health applications representing outsize shares of this total. Factory settings could generate $1.4 trillion to $3.3 trillion by 2030, or just over a quarter of the total value potential. IoT economic impact in human health settings could reach around 14 percent of the total estimated value.

Another way of looking at IoT’s value is to explore use-case clusters (similar uses adapted to different settings). Some of the most common use cases account for a sizable share of IoT’s potential economic value:

operations optimization, which is basically making the various day-to-day management of assets and people more efficient (41 percent)
health (15 percent)
human productivity (15 percent)
condition-based maintenance (12 percent)

Other clusters include sales enablement, energy management, autonomous vehicles (the fastest-growing cluster), and safety and security.

[Source: What is IoT: The Internet of Things explained | McKinsey]

Like everything else we do in Enterprise IT,

IoT Internet of Things is about Data

What is Enterprise Blockchain ?

Enterprise Blockchain is both:

. a Secure Store

. a Secure Communication Channel

In these previous blogs, I made a deep dive in to what Enterprise Blockchain is and why we should be positioning it in our Enterprise Architecture:

Why I love SAP and Blockchain Databases and why you should too🚀

SAP Enterprise Architecture: Positioning Blockchain Database as an Enterprise Technology Standard🚀

SAP Enterprise Architecture: Let the Use Case find the Blockchain 🚀

IoT Internet of Things and SAP - Enterprise Blockchain is the next generation Data Cyber Security Protection - atkrypto.io

and in a nutshell, Enterprise Blockchain is:

. The Digital Transformation of Information Security into Cyber Security

. The Next Generation Data Integrity, Originality, Confidentiality Protection

. Re-imagining Information Security

. Natively, out of the box, due to its special characteristics the strongest, hardest, most resilient Enterprise Database product

To wrap up this section:

. Iot Internet of Things is about Data

. Enterprise Blockchain is about Cyber Security of Data

Section 2.0: The Why is it, of IoT & SAP, and Enterprise Blockchain

So, why does IoT, Internet of Things, in the Enterprise IT, when implemented in conjunction with SAP Applications need Enterprise Blockchain ?

IoT is about Data, and the Data in most cases originates from the Edge and outlying parts of the Network.

The problem is the Cyber Security of getting the Data from the Edge and outlying parts of the Network to the safe zones of the SAP Cloud and yours or SAP's DataCenters.

IoT's biggest risk is that the Data coming from the IoT Devices is not trustworthy. In the same way as asking the wrong person for directions can leave you going all around the houses, if the Data coming from the IoT Devices, has been changed/contaminated/modified/poluted/made unreliable, whether purposefully through malicious acts or cyber attack, or accidentally, the result will be IoT's Data insights which cannot be trusted, and the result of that could be catastrophic. Just imagine not being able to trust the temperature of refrigeration during pharmaceutical and food production !

If we cannot protect and the originality and integrity of IoT Data, secure it, then how can we trust IoT Data ?

As Mckinsey & Company say:

IoT is about the Data

So, if we are going to do IoT and include IoT Data in our Business Processes and Insights, then we need to care for and protect the Data that is coming from IoT Devices.

Imagine, as described in the previous blog, when we let the Use Case find the Enterprise Blockchain, we have a Business Requirement, a Business Demand, to make IoT Data trustable.

Comparison Enterprise Blockchain Database and Traditional Legacy Database - atkrypto.io

IoT is about Data

IoT is about the Data that goes in to the SAP Applications in the Cloud and Data Centers

This means IoT Device Data depends on a Database or a Datastore

What kind of Database do IoT Devices produces ? What capabilities does the Database for the IoT Devices Data need to have ?

1. It must not be possible to modify the Data in the Database which comes from the IoT Devices - the Database needs to be immutable

2. The Data in the Database, the integrity and originality of that Data must be protected to the highest level that is technically possible

3. The Data must be available with the highest availability, the Database must be resilient to attack

When we look in our Enterprise Technology Standards we find 1 Technology Standard in the Enterprise which has those capabilities, and that is..... Enterprise Blockchain

Enterprise Blockchain ticks those three boxes...

Immutable - tick that box

Integrity must be protected to the highest level - tick that box, thanks to the Enterprise Blockchain Hash Mechanism and the Enterprise Blockchain Consensus Mechanism

Highest level of resilience and availability - tick that box thanks to the Distributed and Decentralised nature of the Enterprise Blockchain

This is why, Enterprise Blockchain is the enabler of trustable outcomes from Enterprise IoT Devices' Data.

atkrypto.io what is a blockchain

But there's more than that, IoT Devices can produce a lot of data, and the volumes of data can be big.

And this is why, in this blog we take the Enterprise Blockchain Technology story one level further and we introduce the:

Enterprise Blockchain Wallet

Off-Chain Data Storage

In the Enterprise Blockchain Platforms, the Enterprise Blockchain Wallet is used for Off-Chain storage of big data and in the following paragraphs we will explain why.

What is the Enterprise Blockchain Wallet, and what is Off-Chain Data Storage and why would we use them and why do we need them ?

Blockchain is a very simple form of database atkrypto.io

But, IoT Devices can produce a lot of Data, for example, there could be photographs proving that general waste was tipped at the correct certified location, photographs and in large volumes would be too big to be stored on the Enterprise Blockchain Database itself.

And that's ok, Enterprise Blockchain Platforms are ready for that, and have been designed to store both Structured Data and Data which is in files which are so big that they cannot be stored in the Enterprise Blockchain Database itself, for example the photographs from a Waste Truck's onboard camera proving that waste was responsibly tipped in the correct location and taken at the same time as recording GPS location coordinates proving the location of the Waste Truck.

So, if we can't store the large photographs files in large quantities to the Enterprise Blockchain Database, then how, in an Enterprise Blockchain Platform do we store large files of Data ?

The Enterprise Blockchain Wallet enables us to store large Data, like large Files safely and securely off the chain, or 'Off-Chain'.

But if we store the large Data files Off-Chain in the Enterprise Blockchain Wallet, then how do we also have them some how on the Enterprise Blockchain Database ?

The configurable Enterprise Blockchain Wallet of the Enterprise Blockchain Platform looks like this:

Enterprise Blockchain Platform - Enterprise Blockchain Wallets - Configurable Enterprise Wallets - atkrypto.io

Ok, so we've got the IoT Data stored in the (configurable) Enterprise Blockchain Wallet, but what about securing the IoT Data ? Obviously the Enterprise Blockchain Wallet storage location has built in security, for example the SAP HANA Cloud, the AWS S3 Buckets, but we need more than the out of the box security of these products, the reason we are using the Enterprise Blockchain Database is because of the amazing security strengths that it natively out of the box has, and so, what about the Enterprise Blockchain Wallet, doesn't the Enterprise Blockchain Platform have some cool super hard way of protecting the data in the Enterprise Blockchain Wallet ?

Well yes it does, this is the magic of Enterprise Blockchain Database 'Off-Chain' storage in the Enterprise Blockchain Wallet. This is so unique to Blockchain Technologies.

The data or the file in the Enterprise Blockchain Wallet gets hashed, and then, that hash is stored in the Enterprise Blockchain Database.

On the other hand, if just before we load the data in to the SAP Enterprise Applications, eg SAP Asset Performance Management and SAP S/4HANA, from the Enterprise Blockchain Wallet, if we run a hash over the data and the hash result is the same as we have in the Enterprise Blockchain Database, then we will know we can trust the Data and we can use it in our SAP Applications and we will have trustable IoT Data.

Enterprise Blockchain Wallet Data Hashes Stored in the Enterprise Blockchain Database - atkrypto.io

And this is why, for all of these reasons,

Trustable Enterprise IoT Data depends on Data being stored in the Enterprise Blockchain

But that's not the end of the Why IoT Data needs Enterprise Blockchain.

As we showed at the beginning of the blog in this picture:

IoT Internet of Things Edge Data Cyber Security and SAP Asset Performance Management BTP Protected by Enterprise Blockchain - atkrypto.io

As the picture shows, we have an Enterprise Blockchain Database Tenant installed on a Server Host at the Edge of the Network AND we have an Enterprise Blockchain Data Tenant installed on the SAP BTP Kyma Runtime.

The consequence of this is that we have a distributed Enterprise Blockchain Database table which stretches from the Edge of the Network where the IoT Devices are all the way across the Network to the SAP BTP and DataCenter.

This means we have Enterprise Blockchain Data Protection from the source where the IoT Devices are to the Insights and Business Processes where the SAP Applications are.

We have taken the Enterprise Blockchain to the Data at the source at the IoT Devices instead of taking the IoT Device's Data across all of the Networks to the safety of the SAP BTP and DataCenter. This is because we need to store the Data in the Enterprise Blockchain as close as possible to the source of the Data. The closer the Enterprise Blockchain Tenant is to the source of the Data, the safer the Data will be, it's as simple as that. Enterprise Blockchain is the next generation Cyber Security for IoT Data, and we need to minimise the amount of exposure IoT Data has to previous generation security technologies and approaches.

And this is why we say, Enterprise Blockchain is a Secure Communication Channel, because instead of integrating Applications sending and replicating Data across Networks, we are sharing the Data across the Enterprise Blockchain and the Enterprise Blockchain is the Secure Communication Channel.

IoT Internet of Things and SAP - Enterprise Blockchain is the next generation Data Cyber Security Protection - atkrypto.io

To conclude this section, the Why to, of IoT and Enterprise Blockchain, IoT Data needs to Trustable.

Enterprise Blockchain, due to its native super strong security strength when used as a store of Data enables IoT Data to be Trustable, and the Enterprise Blockchain Software needs be installed as close as possible to the source of the IoT Data, as close as possible to the IoT Devices.

Section 3.0: The How is it, of IoT & SAP, and Enterprise Blockchain

Now that we know why trustable Enterprise IoT needs the Enterprise Blockchain Database to protect the integrity and originality of the Data, how do we implement it today ?

Well that's easy, here are the ingredients and the recipe...

Ingredients, you're going to need:

Data Source(s) eg

IoT Devices which are either REST or MQTT (this could be other protocols and transfer mechanisms depending upon the required Adapters)

SAP and IoT IoT Devices sending Data to MQTT Broker in the Edge Host Instance of the Enterprise Blockchain Platform Database Tenant - atkrypto.io

SAP and IoT IoT Devices sending Data to REST Endpoint in the Edge Host Instance of the Enterprise Blockchain Platform Database Tenant - atkrypto.io

Large Storage for Large Data and the Enterprise Blockchain Wallet

SAP HANA Cloud (Data Lake)

Enterprise Blockchain Platform and specifically one which is capable of running Tenants as close to the Source of the IoT Data as possible at the Edge. We do NOT want to send the IoT Data across the Internet to a Blockchain somewhere in the Cloud, that would defeat the object of the exercise.

These are the basic ingredients, the data from the IoT Devices will be stored either Off-Chain in the SAP HANA Cloud (Data Lake) which will also be the Enterprise Blockchain Platform (configurable) Wallet, or On-Chain in the Enterprise Blockchain Platform Database Ledgers, this Enterprise Blockchain Database Ledger will be running from the Edge to the SAP BTP and DataCenters and then SAP Applications like SAP Asset Performance Management and SAP S/4HANA will be able use the Data in Business Processes and Insights.

And your Technical Reference Architecture will look something like this:

IoT Internet of Things Edge Data Cyber Security and SAP Asset Performance Management BTP Protected by Enterprise Blockchain - atkrypto.io

And that's how you do it.

Wrapping up, conclusions:

. Trustable Enterprise IoT depends on Data being stored in the Enterprise Blockchain at the Edge and in the SAP BTP

Enterprise Blockchain is:

. The Digital Transformation of Information Security to Cyber Security

. The Next Generation Data Integrity, Originality, Confidentiality Protection

. Re-imagining Information Security

. Natively, out of the box, due to its special characteristics the strongest, hardest, most resilient Enterprise Database product

Enterprise Blockchain is both:

. a Secure Store

. a Secure Communication Channel

The configurable Enterprise Blockchain Wallet enables you to store Big Data 'Off-Chain' and the hashes of the IoT Data are stored safely and securely on the Enterprise Blockchain Database.

So what are we waiting for ? Oh yeah, more use cases, ok, that will be the next blog.

What do you think, are the words IoT, Blockchain, Web3, Distributed Ledger Technology, starting to appear in your Company's visions and technology visions ? What use cases are you looking at ? Let's chat about it in the comments.

For now, over and out.

Andy Silvey.

Independent SAP Technical Architect and CEO of atkrypto.io

Author Bio:

Andy is also co-Founder of atkrypto inc, an startup whose ambition is to make Blockchain easy for Enterprise.

atkrypto.io's flagship product is the atkrypto Enterprise Blockchain Platform for SAP, and atkrypto.io is a SAP Partner Edge Open EcoSystem Partner.

All of this makes atkrypto,io the DePIN Decentralised Physical Infrastructure Network solution for Enterprise.

atkrypto is one of the Next20 startups being featured at TM Forum's DTW Ignite in Copenhagen in June

If you will be at DTW24 come and talk to us about Cyber Security of SAP Data with Enterprise Blockchain.

B2B Business Processes - Ultimate Cyber Data Security - with Blockchain and SAP BTP 🚀

2024-05-07T09:54:43.546000+02:00

B2B Business Processes - there are many Business Processes which cross Company and Organisation boundaries.

What has that got to do with Enterprise Blockchain and Cyber Security ? Let's find out.

This is a great Enterprise Blockchain story, it's one of my favourites, like the BCP one, it's so easy to implement and so effective and protects Data and Systems and Business Partners across so many dimensions, read on to find out why.

So buckle up and enjoy the ride...

B2B Business Processes, also known as, Multi-Party Collaboration, the following common Business Processes and others can all include elements of 3rd Party Organisation integration:

Order-To-Cash
Procure-To-Pay
Plan-To-Produce/Plan-To-Inventory
Record-To-Report
Source-To-Pay
Idea-To-Offering
Count-To-Reconcile
Forecast-To-Monitor
Inspect-To-Comply
Cradle-To-Grave/Acquire-To-Retire

Where ever you have a Business Process which includes sending your Data to a 3rd Party Organisation, to another Company, your Data is being put at risk. When ever you send or replicate or integrate your Company's Data to another Company your Data is at risk, and this means your Business Process is at risk and therefore your Business is at risk.

This blog is going to be talking about and showing is the weakness of the current approach of working with Data across multiple Organisations which collaborate together on a Business Process.

An easy example is 3PL 3rd Party Logistics.

Your Company needs something delivered and your S/4HANA system sends an instruction to the 3rd Party Logistics company to make a collection and a delivery.

This all looks very normal and very common, but what is actually happening when your Company sends an instruction from the S/4HANA system to the Delivery Planning System at your Partner Company the 3PL 3rd Party Logistics Company ?

Data, it's all about Data, your S/4HANA system is sending Data to your Business Partner the 3rd Party Logistics Company instructing them on where to collect from or deliver to.

And this is the problem, as soon as your Data leaves your network, it's no longer your Data, and you lose control of the Data.

This is a classical Integration scenario, the S/4HANA is Integrated to the 3rd Party Logistics Company's System and you send them your Data. What happens to that Data at your Business Partner is beyond your control, you can only trust that they will care for your Data the same way as they would care for their own Data.

This is how you are doing it today, with IDOCS and API's, this is legacy Data Integration through Replication:

Cyber Security Risk SAP Customers have to share Master Data with Partners Legacy Integration through Data Replication atkrypto.io

This creates several problems including:

Trust between Partners: The more Partners in a Business Transaction or Business Process, the less trust there is between Partners. This is a very simple graph, as the number of Partners in a Business Transaction or Business Process goes up, so the trust between the Partners goes down. What is trust in a Business Transaction or Business Process, doing what you said you would, data, instruction, confirmation. I will deliver the parcel to the address you gave me, but what if somebody in my Team changes the delivery address for their own benefit ?

Protect the Originality & Integrity of the Data - When your S/4HANA sends the Data to your Business Partner's System we need to make sure that the Data cannot be modified or destroyed and therefore protect the originality and integrity of the Data

Replicating & Integrating the Data from your S/4HANA to your Business Partner's System and at the same time Protect the Originality & Integrity of the Data - we need to get the Data from the S/4HANA to the Business Partner's System and we need to be sure, to have surety that the Data which arrives at the Business Partner's System is the same Data as was sent from your S/4HANA. If this Data can be changed in any way, we won't be able to trust the Business Processes and Insights which are depending on that Data. And so, in the activity of moving the Data we need to make sure that that piece of Data cannot be modified or destroyed and therefore protect the originality and integrity of the Data

and it doesn't end there, it's often the case that a 3rd Party Organisation will be getting Data directly from your S/4HANA (as the Source) or posting Data to your S/4HANA (as the Target), in both cases it could be an API which through your Integration Technologies is ultimately exposed to the Internet and where the system calling the API needs to have a User on your S/4HANA.

And 3rd Party Logistics is only the tip of the iceberg when it comes to Multi-Party Collaboration and Business Transactions and Business Processes. You know how integrated your Systems are with your Business Partners how the data is flowing in and out of your network to and from your Partner's networks.

And so, here we are,

The biggest threat to B2B Business Processes is Cyber Security and Cyber Attacks

The biggest threat to Multi-Party Collaboration is Cyber Security and Cyber Attacks

And that's where the Enterprise Blockchain comes in, and this blog is going to explain why.

This blog will be less about deep dives into Use Cases and more about how Enterprise Blockchain is:

. A Secure Store of Data

. A Secure Communication Channel for Data

. A Common Shared Single Source of Truth in your Organisation and across Organisations

. The next generation Data Integration is about having a Common Shared Single Source of Truth

Subsequent blogs will deep dive individual use case by use case, this one will focus on the principle of Enterprise Blockchain already today being the next generation Secure Store and Secure Communication Channel for Data and how and why.

Ok let's go 🚀

Welcome to the ninth blog in this series on Enterprise Blockchain and SAP. If you have been following the previous blogs then you'll be familiar with the blog template. We'll begin by talking about and framing the problem, in this case Data Cyber Security for B2B Business Processes and then go in to identifying the enabling technology which will have the best capabilities and be the most appropriate to solving the problem all the way through to the reference solution architecture to be able to implement the solution.

The blog is going to break the subject down in to three sections:

Section 1.0: The What is it of B2B Business Processes and SAP, and Enterprise Blockchain

Section 2.0: The Why is it, of B2B Business Processes and SAP, and Enterprise Blockchain

Section 3.0: The How is it, of B2B Business Processes and SAP, and Enterprise Blockchain

In case you missed them, the previous blogs in this series are here:

Why I love SAP and Blockchain Databases and why you should too 🚀

SAP Enterprise Architecture: Positioning Blockchain Database as an Enterprise Technology Standard 🚀

SAP Enterprise Architecture: Let the Use Case find the Blockchain🚀

Oil & Gas - Ultimate Data Security - Blockchain Data Backbone from OT to SAP IT🚀

The What Is... The Why To... The How To... of: ESG & SAP & Enterprise Blockchain 🚀

BCP: Business Continuity Planning for SAP S/4HANA - made easy with Enterprise Blockchain 🚀

Trustable AI thanks to - SAP AI Core & SAP HANA Cloud & SAP S/4HANA & Enterprise Blockchain 🚀

IoT - Ultimate Data Cyber Security - with Enterprise Blockchain and SAP BTP 🚀

tl:dr

Enterprise Integrations and Integration Architecture centered around sending and replicating Data to Business Partners results in you losing control of your Data, and losing surety that the Business Partner is looking at the same Data as you are.

The Digital Transformation of Enterprise Integrations is to have a shared common single source of truth for data with your Business Partners.

Enterprise Blockchain is the answer, Enterprise Blockchain enables both Business Partners, you and your Business Partner to share the same Distributed Ledger and consequently have a common shared single source of truth for data across multiple Companies.

That's one thing, the next thing is that thanks to the special characteristics of the Enterprise Blockchain Distributed Ledger, namely, Immutable, Hash Mechanism, Consensus, Distributed, when you or your Business Partner write data to the Enterprise Blockchain, you know, that nobody can modify the Data for their own gains, your know that natively, out of the box you have the highest level of Data Cyber Security and Resilience of any commercial database product available.

In the 3PL scenario, this is what your SAP Technical Architecture would look like:

Enterprise Blockchain as a Shared Common Single Source of Truth for Master and Transactional Data across Organisations with SAP BTP and atkrypto.io

[the finer technical details of the Technical Solution Architecture will be elaborated in the rest of the blog]

The Future of Enterprise Collaboration and Cross Organisation Data Integration and B2B Business Processes (and this is possible today with the SAP BTP and SAP Partner Edge Open EcoSystem Partner Enterprise Blockchain Products).

And as will be explained later in the blog, it's not only about the Enterprise Blockchain being a common shared source of truth across organisations, it's about digitally decoupling the S/4HANA from 3rd Party System Integrations and gradually ring fencing the S/4HANA away from being directly accessed by 3rd Party Systems as it is today with API's.

This is like pick your own strawberries, instead of sending your Partners the strawberries, you tell your Partner the strawberries are ready and which field they are in and you let your Partners pick the strawberries themselves from the Enterprise Blockchain.

S/4HANA Data Events write the Data to the Enterprise Blockchain and S/4HANA Notification Events notify the Partner that something has happened, then, instead of calling an API on your SAP S/4HANA, the Partner then calls the API of the Enterprise Blockchain and Reads the Data from there.

The Enterprise Blockchain Database software is running on your SAP BTP Kyma Runtime and in your Partner's Servers, therefore, creating natively, out of the box, the most secure and resilient common shared single source of truth. Your have a Distributed Ledger running from your SAP BTP to the Partner's Servers.

Enterprise Blockchain Multi Party Business Processes Data Sharing atkrypto.io

Therefore, S/4HANA Data Event Writes to the Enterprise Blockchain as the Common Shared Single Source of Truth across the Organisations, and the S/4HANA Notification Event notifies the Partner that something has happened and that they should call the Enterprise Blockchain API to get the Data of what has happened.

Enterprise Blockchain is:

. a Secure Store

. a Secure Communication Channel

. a Shared Common Single Source of Truth for Master and Transactional Data across Organisations

Enterprise Blockchain is the Cyber Security for Enterprise B2B Business Processes and Multi Party Collaboration.

and now.... the long answer...

Section 1.0: The What is it of B2B Business Processes and SAP, and Enterprise Blockchain

What are B2B Business Processes, what is Multi-Party Collaboration, what are 3rd Party Integrations, what is it all and why do we need it ?

B2B Business Processes, Multi-Party Collaboration, in the context of this subject, these are any Business Process in your Company which includes your Master and Transactional S/4HANA Data being used by another Company, and results in the other Company needing access to your Data.

There are many examples, in today's world of outsourcing that which is not considered part of the core Business, Multi-Party Collaboration is very common across most lines of the Business. Another easy and common one is outsources Payroll.

As described in this blog, by @mert_turan , your Company is using a 3rd Party Payroll provider to take care of your Payroll, the process and the integration can look like this:

Payroll Process by Mert Turan

This is a classic example of a B2B Business Process, where your Company is sending highly sensitive and highly confidential Data, transferring that Data to a 3rd Party Company, in this case a 3rd Party Payroll Provider. Look at all of the Data transfers which are going on in that Payroll Business Process.

Just look at the sensitivity and confidentiality of the Data which is being transferred to the 3rd Party Company, Personal and Business Sensitive Master and Transactional Data.

What could possibly go wrong ?

What could possibly go wrong with any of these Multi-Party Collaborative Business Processes, Payroll, Supplier Network Collaboration, 3rd Party Logistics, Contract Manufacturing ?

What is the biggest risk ?

The Data, again, it's all about the Data, and keeping the Data safe, and reducing the chance that somebody can mess with the Data.

What about the Enterprise Blockchain, what is Enterprise Blockchain ?

Enterprise Blockchain is both:

. a Secure Store

. a Secure Communication Channel

In these previous blogs, I made a deep dive in to what Enterprise Blockchain is and why we should be positioning it in our Enterprise Architecture:

Why I love SAP and Blockchain Databases and why you should too🚀

SAP Enterprise Architecture: Positioning Blockchain Database as an Enterprise Technology Standard🚀

SAP Enterprise Architecture: Let the Use Case find the Blockchain 🚀

Enterprise Blockchain Multi Party Business Processes Data Sharing atkrypto.io

and in a nutshell, Enterprise Blockchain is:

. The Digital Transformation of Information Security into Cyber Security

. The Next Generation Data Integrity, Originality, Confidentiality Protection

. Re-imagining Information Security

. Natively, out of the box, due to its special characteristics the strongest, hardest, most resilient Enterprise Database product

To wrap up this section:

. B2B Business Processes are about Data

. Enterprise Blockchain is about Cyber Security of Data

Section 2.0: The Why is it, of B2B Business Processes and SAP, and Enterprise Blockchain

So, why B2B Business Processes in the Enterprise IT, when implemented in conjunction with SAP Applications need Enterprise Blockchain ?

Multi-Party Collaboration is about replicating Data to 3rd Party Company, and the Data, this is your Company's Data and in most cases highly sensitive and highly business and personally confidential.

The problem is the Cyber Security of getting the Data from the your Company's SAP S/4HANA to the 3rd Party Company's Application, and ensuring the originality and integrity of the highly sensitive and confidential Master and Transactional Data which you are replicating to the Partner Company remains intact.

As we talked about earlier, and this is worth repeating because this is the problem of Multi-Party Collaboration:

ITSecurityWire.com, in their article, Best Practices to Secure Data Integration, put it like this:

The LinkedIn Community describe the risks of Data integration like this:

Those are the problems with today's legacy ways of making your S/4HANA Master and Transaction Data available for 3rd Party Companies in your B2B Business Processes.

And what's the solution ?

The solution is the Enterprise Blockchain as the Common Data Back Bone across Companies.

Instead of replicating and sending the Data to your Business Partner, you write the S/4HANA Data to the Enterprise Blockchain.

Imagine, as described in the previous blog, when we let the Use Case find the Enterprise Blockchain, we have a Business Requirement, a Business Demand, to make Data for B2B Business Process the safest it can be, the most trustable that it can be.

Comparison Enterprise Blockchain Database and Traditional Legacy Database - atkrypto.io

B2B Business Processes are about Data

B2B Business Processes are about the Data that goes from your S/4HANA outside the boundaries of your Company and your Network and to Partner Company's Applications and Networks and Databases.

This means B2B Business Processes are about Data and the Data depends on a Database or a Datastore

What kind of Database do B2B Business Processes Data need ? What capabilities does the Database for the B2B Business Processes Data need to have ?

1. It must not be possible to modify the Data in the Database ]- the Database needs to be immutable

2. The Data in the Database, the integrity and originality of that Data must be protected to the highest level that is technically possible

3. The Data must be available with the highest availability, the Database must be resilient to attack

4. The Database must be running simutaneously in your DataCenter and your Business Partner's DataCenter

5. S/4HANA must not expose any API's to Business Partner Companies

When we look in our Enterprise Technology Standards we find 1 Technology Standard in the Enterprise which has those capabilities, and that is..... Enterprise Blockchain

Enterprise Blockchain ticks those boxes...

Immutable - tick that box

Integrity must be protected to the highest level - tick that box, thanks to the Enterprise Blockchain Hash Mechanism and the Enterprise Blockchain Consensus Mechanism

Highest level of resilience and availability - tick that box thanks to the Distributed and Decentralised nature of the Enterprise Blockchain

DeCouples S/4HANA from the process, no need to S/4HANA API's to be exposed to 3rd Party Business Partner's Applications

This is why, Enterprise Blockchain is the enabler of trustable outcomes from Enterprise B2B Business Processes.

atkrypto.io what is a blockchain

But there's more than that, B2B Business Processes can produce a lot of data, and the volumes of data can be big.

And this is why, in this blog we take the Enterprise Blockchain Technology story one level further and we introduce the:

Enterprise Blockchain Wallet

Off-Chain Data Storage

In the Enterprise Blockchain Platforms, the Enterprise Blockchain Wallet is used for Off-Chain storage of big data and in the following paragraphs we will explain why.

What is the Enterprise Blockchain Wallet, and what is Off-Chain Data Storage and why would we use them and why do we need them ?

Blockchain is a very simple form of database atkrypto.io

But, Payroll can produce a lot of Data, and in large volumes which would be too big to be stored on the Enterprise Blockchain Database itself.

So, if we can't store the large photographs files in large quantities to the Enterprise Blockchain Database, then how, in an Enterprise Blockchain Platform do we store large files of Data ?

The Enterprise Blockchain Wallet enables us to store large Data, like large Files safely and securely off the chain, or 'Off-Chain'.

But if we store the large Data files Off-Chain in the Enterprise Blockchain Wallet, then how do we also have them some how on the Enterprise Blockchain Database ?

The configurable Enterprise Blockchain Wallet of the Enterprise Blockchain Platform looks like this:

Enterprise Blockchain Platform - Enterprise Blockchain Wallets - Configurable Enterprise Wallets - atkrypto.io

Ok, so we've got the large volumes of Data stored in the (configurable) Enterprise Blockchain Wallet, but what about securing the Data ? Obviously the Enterprise Blockchain Wallet storage location has built in security, for example the SAP HANA Cloud, the AWS S3 Buckets, but we need more than the out of the box security of these products, the reason we are using the Enterprise Blockchain Database is because of the amazing security strengths that it natively out of the box has, and so, what about the Enterprise Blockchain Wallet, doesn't the Enterprise Blockchain Platform have some cool super hard way of protecting the data in the Enterprise Blockchain Wallet ?

Well yes it does, this is the magic of Enterprise Blockchain Database 'Off-Chain' storage in the Enterprise Blockchain Wallet. This is so unique to Blockchain Technologies.

The data or the file in the Enterprise Blockchain Wallet gets hashed, and then, that hash is stored in the Enterprise Blockchain Database.

Enterprise Blockchain Wallet Data Hashes Stored in the Enterprise Blockchain Database - atkrypto.io

And this is why, for all of these reasons,

Trustable Enterprise B2B Business Processes depends on Data being stored in the Enterprise Blockchain

But that's not the end of the b2B Business Processes need Enterprise Blockchain.

As we showed at the beginning of the blog in this picture:

Enterprise Blockchain Multi Party Business Processes Data Sharing atkrypto.io

As the picture shows, we have an Enterprise Blockchain Database Tenant installed on a Server Host at the in your DataCenter, in your Network on your SAP BTP Kyma Service AND we have an Enterprise Blockchain Database Tenant installed on your B2B Business Partner's Network, if they are a SAP Customer then like you they can put it on the SAP BTP Kyma Service, if not they can run it on Kubernetes.

The consequence of this is that we have a distributed Enterprise Blockchain Database table which stretches from your DataCenter and Network where your S/4HANA is writing Data to it and stretches all the way across the Network to your Business Partner's DataCenter.

This means we have Enterprise Blockchain Data Protection from the source from your S/4HANA to the target your B2B Business Partner's It infrastructure enabling the trusted resilient reliable Business Processes to be completed.

At the same time, we are not exposing S/4HANA or the API's on the S/4HANA to any 3rd Party Applications.

We have digitally decoupled the S/4HANA from the Business Process.

Enterprise Blockchain as a Shared Common Single Source of Truth for Master and Transactional Data across Organisations with SAP BTP and atkrypto.io

To conclude this section, the Why to, B2B Business Processes and Enterprise Blockchain, B2B Business Process Data needs to safely replicated and trustable.

Enterprise Blockchain, due to its native super strong security strength when used as a store of Data enables B2B Business Processes to be both Secure, and Trustable.

And as we will see in the next section, it's not only about the Enterprise Blockchain being a common shared source of truth across Organisations, it's about digitally decoupling the S/4HANA from 3rd Party System Integrations and gradually ring fencing the S/4HANA away from being directly accessed by 3rd Party Systems as it is today with API's.

Section 3.0: The How is it, of B2B Business Processes and SAP, and Enterprise Blockchain

The goal of this blog was to show how instead of using the legacy fire and forget approach of replicating data to 3rd Party Business Partners, the Enterprise Blockchain can be deployed as a common shared single source of truth running, with an Enterprise Blockchain Tenant running close to your S/4HANA and another Enterprise Blockchain Tenant running close to your Business Partner's Application.

In this section of the blog we will show all of the possible potential Technical Solution Architectures which will enable you to implement this next generation approach to sharing Data with the highest level of Cyber Security already today.

As described above one of the many beauties of this approach is your S/4HANA writes to the Enterprise Blockchain and your Business Partner's Application reads from the same Enterprise Blockchain. This achieves a number of things including:

. Total Control - you have total control over the Data you are sharing with the Business Partner, and you know that as long as your Business Partner's Application reads the Data from the common shared source, the Enterprise Blockchain

. Ultimate Cyber Security - then you know the maximum has been done to minimise the chance for Cyber Security risks and the maximum has been done to protect originality, integrity, and confidentiality of the Data

. S/4HANA Digitally DeCoupled from the Business Process - and on top of this, the S/4HANA has been digitally disconnected from the Business Process, because no longer do any 3rd Party Applications directly call API's on the S/4HANA

In the Technical Solution Archecture there would be two main ways for getting the data from the S/4HANA and writing it to the Enterprise Blockchain, these would be:

. API's

. Events

In these Technical Solution Architecture examples we will prioritise using S/4HANA Events to write the Data to the Enterprise Blockchain, we will be sending the Event Notification and the Event Payload, we could of course draw the same Technical Solution Architecture with API's, but we prefer the Events for the simplicity and reduced call backs to the S/4HANA and therefore making the S/4HANA more Digitally DeCoupled and therefore, enabling the S/4HANA to be protected to the higher security level and exposed to less Cyber Security risk.

Ok, let's go with the Technical Solution Architectures, in these examples we will focus on the OutSourced Payroll as the integration and B2B Business Process Example.

What do we have and what do we need:

Your Company will need:

. S/4HANA

. SAP EM and preferably SAP AEM since it has richer Security and Event Payload size capabilities and can Publish Events from Non-SAP Enterprise Applications and connect to your Enterprise Event Mesh

. SAP BTP

. SAP BTP Kyma Runtime Service - this is where the Enterprise Blockchain Container will run

. Enterprise Blockchain Platform Software which can run on Kubernetes

. If there will be larger Data objects then you will need Large Storage for Large Data and the Enterprise Blockchain Wallet in the form of SAP HANA Cloud (Data Lake)

Your Business Partner will need:

. Obviously their Payroll Application

. Either SAP BTP with Kyma Runtime, or Servers which can run Kubernetes Containers

. n.b. there is an Optional Technical Solution Architecture where you simply allow your Business Partner to read data from your Enterprise Blockchain where the Enterprise Blockchain Platform is running exclusively on your BTP, we will show that Option as well

Technical Reference Solution Architecture for SAP S/4HANA and SAP SuccessFactors and OutSourced 3rd Party Payroll Provider using Enterprise Blockchain as a Common Shared Single Source of Truth for Data and the Ultimate Cyber Data Security for B2B Business Processes...

OutSourced Payroll Process B2B Business Processes with S4HANA and Ultimate Data Cyber Security thanks to Enterprise Blockchain atkrypto.io

In the next example, we have the same basic Technical Solution Architecture as the previous example, except, this Reference Use Case is ready for the Enterprise Blockchain needed to be able to handle large volumes of data and brings the Enterprise Wallet in to the picture. In the Enterprise Blockchain Platform the Enterprise Wallet storage is configurable and therefore could be SAP HANA Cloud (DataLake) or AWS S3 Buckets or other HyperScaler Data stores.

All of the other Cyber Security characteristics remain the same, S/4 is digitally decoupled from the Business Partner, Enterprise Blockchain is used as a common shared single source of truth for Master and Transactional Data, and the Enterprise Blockchain Tenants are running in both your DataCenter (AnyPremise) and the Business Partner's DataCenter (AnyPremise):

OutSourced Payroll Process B2B Business Processes with S4HANA and Ultimate Data Cyber Security thanks to Enterprise Blockchain & Enterprise Wallet atkrypto.io

The next example Reference Technical Solution Architecture is a little bit different, let's assume, for their own reasons, your Business Partner is not going to run an Enterprise Blockchain Tenant in their (AnyPremise) DataCenter.

This is still fine, you will set up the Enterprise Blockchain Platform in your DataCenter(s) (AnyPremise) and your B2B Business Partner, in this case the outsourced 3rd Party Payroll Vendor will simply use API's to read and write to and from your Enterprise Blockchain.

All of the other benefits of the design remain the same, all of the other next generation Data sharing Cyber Security characteristics are still there, S/4 is digitally decoupled from the Business Partner, Enterprise Blockchain is used as a common shared single source of truth for Master and Transactional Data.

Here it is:

OutSourced Payroll Process B2B Business Processes with S4HANA and Ultimate Data Cyber Security thanks to your Enterprise Blockchain atkrypto.io

Finally, we have the same Reference Technical Architecture as above, but to be able to cater for large volumes of Data we include the Enterprise Wallet in the design:

OutSourced Payroll Process B2B Business Processes with S4HANA and Ultimate Data Cyber Security thanks to Enterprise your Blockchain & Enterprise Wallet atkrypto.io

Ok let's wrap this up, the conclusions:

Ultimate Cyber Security for B2B Business Processes is Enterprise Blockchain, where the Enterprise Blockchain acts a common shared single source of truth for Data across Organisations

Enterprise Blockchain is:

. A Secure Store of Data

. A Secure Communication Channel for Data

. A Common Shared Single Source of Truth in your Organisation and across Organisations

. The next generation Data Integration is about having a Common Shared Single Source of Truth

The next generation Integrations don't replicate Data, that's legacy, the next generation Integrations use Enterprise Blockchain as a common shared single source of truth.

The configurable Enterprise Blockchain Wallet enables you to store Big Data 'Off-Chain' and the hashes of the Data are stored safely and securely on the Enterprise Blockchain Database.

So what are we waiting for ? Oh yeah, deep dive in to more use cases, ok, that will be the next blog.

For now, over and out.

Andy Silvey.

Independent SAP Technical Architect and CEO of atkrypto.io

Author Bio:

Andy is also co-Founder of atkrypto inc, an startup whose ambition is to make Blockchain easy for Enterprise.

atkrypto.io's flagship product is the atkrypto Enterprise Blockchain Platform for SAP, and atkrypto.io is a SAP Partner Edge Open EcoSystem Partner.

All of this makes atkrypto,io the DePIN Decentralised Physical Infrastructure Network solution for Enterprise.

atkrypto is one of the Next20 startups being featured at TM Forum's DTW Ignite in Copenhagen in June

If you will be at DTW24 come and talk to us about Cyber Security of SAP Data with Enterprise Blockchain.