The number of internet connected devices continues to grow daily. But managing that huge increase in information is no easy task. That’s why I wanted to invite Mrinal Wadhwa, the CTO of Fybr, to join me on the show this week.
Fybr has been developing a number of IoT (Internet of Things) devices that are usually wireless low power units that can be installed in remote or hard to access places. One of the first devices they created was a hockey puck sized device that can be installed in individual parking spots. That device then connects to a central server to show if a parking spot is occupied or not. The devices don’t communicate with one another in the physical world because that would take too much power. Instead Fybr has developed the idea of a “digital twin”. The twin of the device exists on the server side and that allows all of the information collected by the individual devices to be shared across the network.
Developing those digital twins allows the user to create “business rules” for each device. You can tell the device when to go to sleep and when to wake up. You can also change the amount charged for a parking space during different times of the day. Whether those rules live on the server or on the device itself is decided based on the application.
One of the biggest issues in IoT development is over the air updates. A new business rule has been created and the company wants to push that code to the device. There is a fundamental problem, though. If you are constantly updating devices with new code and you make an error you run the risk of bricking the devices. Fybr has solved this problem by creating a tiny virtual machine that lives inside FybrLyn’s. Because it’s a virtual machine that is independent of the actual hardware code it functions as a sandbox. You can push business logic to the edge on a regular basis without fear of harming communication with the remote device.
Fybr’s system specializes in low power wireless devices but that’s not the only kind of IoT device. A customer may have powered devices or large manufacturing machines as well. The SAP Leonardo IoT is very well positioned to bring all that data into one place. The IoT created some required steps that should be performed. This could be to send a service technician to perform work, this would require a work order and here SAP would be integrated and handle those actions. Or it could be the new sales order to a printer ink that needs to be purchased and sent.
As IoT continues to expand there are huge hurdles to overcome. If Fybr’s parking sensors were deployed in every parking spot in America it would require hundreds of millions of devices. The scale of that information will be incredibly challenging to manage. There are also security challenges that have to be solved. A connected machine in a manufacturing facility is very well guarded. It’s very difficult to access that machine.
But a smart city sensors are installed on streets. Someone could spend hours trying to access the sensor without anyone knowing. The sensors will have to include some kind of encryption key. Anyone could steal the device and figure out the key. If a device cannot keep a secret than how can you trust if the device is providing accurate information? That is a huge challenge that is hard to solve for many smart infrastructure applications. Fybr has tried to solve it by carefully monitoring the life cycle of each key in each device.
Mrinal says IoT is a big challenging world. There are a number of unresolved problems. And there has not yet been very large scale deployments. There is tremendous possibilities in this space by combining traditional SAP knowledge with this new class of devices.
Today on the show I’m going to do something a little different. Instead of inviting a guest to join me today I’m going to talk a little about OPI or Operational Process Intelligence. SAP OPI is a product that…
“offers real-time end-to-end process monitoring combined with pattern detection, analytics, alerting, and response management. It gives business users real-time visibility into processes and the ability to respond swiftly – enabling better, faster decision-making to achieve greater agility in business operations.”
OPI is helping out with BAM(Business Activity Monitoring). I first encountered BAM back in 2006, when I was working on writing a bachelor assignment. The goal is to give better information into what is happening an organization. Which processes were taking too long time and where to improve them and give real-time monitoring if anything was failing. This is the goal of SAP OPI. So it was only in 2015 that I got a chance to work with OPI in practice at a customer site.
I also created a video on them as an alternative to the podcast. Same content just saved on youtube.
In this podcast I will cover the following things.
- BPM and show how runs
- Process phases and to identify what needs to be done
- Getting BPM process information – You need a Solman role in SAP PRO
- Reporting information from BPM requires the use of data source in the BPM flow
- Some KPI easy to use like a number of processes or duration of steps.
- Complex take bit more work like % of processes that worked.
- HANA development you will need to learn a lot of HANA to be a good developer
- No SP for 1½ year, so it does not seem like a tool that has a lot of future.
- It would make sense for SAP to move it to Cloud Platform in some form and then have integration tools to get data
- Process Miner – Celonis is SAP tool to understand what is going on in a process.
Today we are going to discuss API management with Bram Keijers who works as an SAP Integration Consultant with Proxellence. Most of the company’s clients are using integration middleware and so API management is just starting to be backed up by customers. It’s still a relatively new feature having only been released by SAP three years ago.
Bram tries to convince clients to use the API management feature for any services exposed to an SAP gateway. Suppose a customer has an SAP backend system like ECC that is providing employee data to third parties. If another third party needs to access the same data the old method was to create an entirely different interface and another integration flow. What you can do with API management is to create a central interface and there you can govern access to all third parties. That means it’s going to be a lot cheaper and easier to get your end point exposed.
The price is fairly affordable. There is a cloud platform pricing calculator that you can access here. €180 per month will cover a million calls per month. Bram really likes the new consumption based pricing. It’s cheap enough that new customers can try it out for a few months and experiment with it. SAP’s strategy is to allow customers to try different parts of the platform at a low price.
Recommended places to get started with SAP API management
API management overview:
Building & Consuming API’s:
part 1, configuration and API portal: https://blogs.sap.com/
part 2, Developer portal: https://blogs.sap.
OData services discovery in API Management:
If you have any other questions about SAP API management you can contact Bram here: