VO2 Max - Nov 2024	VO2 Max - Oct 2025

I used to dislike running very much. I just didn’t get it. To me it seemed like such a boring activity that I had zero interest in getting involved with. That changed when I decided to start training for a HYROX event (April 2025). HYROX combines both running & functional workout stations, where you run 1km, followed by 1 functional workout station, repeat that eight times. In the end, you spend most of the time running as part of the race. If I wanted to do a HYROX, I had to start running, so I started researching how to get into running.

At the beginning, I was just like… ok I’ll go for a 30 min run. I read a lot of how you need to do Zone 2 training as part of your running and with the help of my Apple Watch and a heart rate monitor strap, I was able to see my heart rate while running. What a surprise it was to see that even though I was running slowly my heart rate was already high and to keep it in Zone 2 I had to run very slow, like jogging speed. That first training session was tough and boring hehe. My average running speed was 8.2 km/hr and my Apple Watch stated that my VO2 Max was 41. Fortunately, I knew that with consistent training, my cardiovascular system would improve with time and I would get better at it.

First run	Stats

To keep me motivated, I decided to sign up for a half-marathon (March 2025) and I was fortunate enough to have my good friend Cesar running with me. He didn’t just ran with me but also help clarify the 1000s questions that I had related to running. I started a half marathon training plan and did my best to follow it.

As time went by I started to see improvements. My VO2 max started to increase, my pace was faster for my Zone 2 and best of all, I started to enjoy running. Podcasts and audiobooks help a lot with that :-).

March 2025, We ran the Movistar Half Marathon in Madrid with Cesar. It was my first half marathon and I completed it in 1:43:10. I only managed to make that time as Cesar paced me and kept me motivated in that last km which lasted an eternity hehe.

Movistar Madrid Half Marathon

April 2025, HYROX event day arrived. Although I got sick the week before the event, I was able to complete the race in 1:28:03. Not bad but although I did run a lot to prepare for it, I knew that I just need to run a lot more to be able to run better while fatigued after the functional stations.

Completed my 1st HYROX	Time

Since then, I have been running consistently. Now, I look forward to my runs and even feel a bit disappointed if I have to miss one. I’m following a running training program focused on HYROX, which involves running in combination with functional workouts, as I’m preparing for another race soon. I’m quite happy to see how my running has improved significantly. My average pace for Zone 2 runs is now below 5:40 min/km and my VO2 max is 51.7 - I got this tested in a proper lab with the face mask and everything.

Support Crew

Honestly, none of this would be possible if it wasn’t for the support of those around me 🧑‍🧑‍🧒‍🧒. I’m now looking forward to my next year of running and see how, slowly but surely, I keep progressing and improving my running performance.

Fiori preview error

Based on the network requests that I was able to see in the Developer Tools, I knew it was using version 1.132.0 of SAP UI5. Then I thought… let’s force the project to use a different version to see if the error would go away. I debugged the CAP project and I knew exactly where was the version of SAP UI5 being set. I set the variable to 1.130.0 and the preview worked fine. Nice!

Debug forcing version

Now, I don’t want to debug the project every time and manually set the version…. digging deeper, I found out that the @sap/cds-fiori module has a package.json, where the version of SAP UI5 is set. It is well known that you can set project-specific configuration via a .env file. So, I created a .env file in the root of the project and set the following content:

cds.fiori.preview.ui5.version=1.130.0

By setting that environment variable I’m forcing the project to use version 1.130.0 of SAP UI5 when running the Fiori preview. I restarted the project and the preview worked fine.

Fiori preview running specific version

Whenever I’ve written technical documentation using Markdown, there have been instance where I wanted to communicate something extra and for that I normally use blockquotes. Although a blockquote does give special emphasis to the text from the rest of the content, I’ve found myself wanting to do particular emphasis on something. For that, I’ve used different methods like using bold text, italic text, or emojis (📝, 🧭, 🚨). That said, I’ve never been quite satisfied with it. Fortunately, I bumped into GitHub Alerts today - https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#alerts, thanks to how Vadim Klimov is using it in his repo - CPI Navigator.

[!NOTE] Alerts are a Markdown extension based on the blockquote syntax that you can use to emphasize critical information.

What I like about it is that it is such a simple change that can make a big difference. It is a great way to highlight something and communicate importance of the information to the reader. I’m looking forward to using it in future content I create and I’ve started updating existing content to include this. Check out how it is being used in this exercise - https://github.com/SAP-samples/event-driven-integrations-codejam/tree/main/exercises/01-events-sap-ecosystem.

My last interactions with SAP Build Process Automation revolve around how you can trigger process by using events. We know that when configuring a process, one of the triggers can be set to start it is an event - Create an event to start a process. At the moment, the UI only let’s you select the events from a dropdown this is limited to some predefined business events.

By looking under the hood (Web browser, developer tools) I noticed that when setting an event trigger, there is an HTTP request made to the API. This request contains a payload with the following structure:

{
    "name": "MyCustomEventName",
    "identifier": "mycustomeventname",
    "description": "",
    "header": {
        "triggerableArtifactUids": [
            "$.436i6204-0818-3t8o-q0if-h55t46k016gh"
        ],
        "sourceArtifactUid": "sap.s4.beh.businesspartner.v1.BusinessPartner.Created.v1"
    }
}

The sourceArtifactUid field is set to sap.s4.beh.businesspartner.v1.BusinessPartner.Created.v1. This is the event that triggers the process. I’ve seen this value before when dealing with the SAP S/4HANA Cloud Business Partner events…. this is the value set in the type field of the event payload. Remember that SAP has embraced the CloudEvents specification and the type field will be included in the header (context) part of the event message. This got me wondering, what would happen if I set a different value in the sourceArtifactUid field in the request? Will it accept it as a trigger? Let’s try it.

{
    "name": "MyCustomEventName",
    "identifier": "mycustomeventname",
    "description": "",
    "header": {
        "triggerableArtifactUids": [
            "$.436i6204-0818-3t8o-q0if-h55t46k016gh"
        ],
        "sourceArtifactUid": "my.custom.event.v1"
    }
}

Will it work? Unfortunately, no. The service validates the value set as sourceArtifactUid. If it doesn’t match any of the predefined values, it will not accept it. This is a good thing, as it prevents you from setting a trigger that doesn’t exist. That said, it would be nice to have the ability to handle custom events that can trigger processes. I imagine that the custom event will need to be follow the CloudEvents specification but that wouldn’t be a big problem. It will be great to have this type of functionality as it would allow for more flexibility and automation in the platform, e.g. events from custom applications.

Dev Container running remotely

Dev Containers

The Visual Studio Code Dev Containers extension lets you use a container as a full-featured development environment. It allows you to open any folder inside (or mounted into) a container and take advantage of Visual Studio Code’s full feature set¹. In essence, you develop locally and your code runs in a local containerised environment.

Dev Container running locally

I created a devcontainer.json and specified that it should run on the amd64 architecture.

FROM --platform=linux/amd64 mcr.microsoft.com/devcontainers/python:1-3.12-bullseye

CMD ["echo", "The python:3.12.2-slim-bullseye image is working!"]

Now, I was able to install the library and run the program using the local Dev Container running on the amd64 architecture (–platform=linux/amd64) but a new issue arrived. I was unable to install VS Code extensions in this local Dev Container. No matter what, not a single extension was installed in it. It wasn’t an issue with internet connectivity (proxies) and I wasn’t able to find an explanation on why this was happening. I’ve worked with Dev Containers in others projects and installing extensions on it just works.

After wasting more hours than what I would like to admit ⏳⏳⏳……

This new issue got me thinking…. can the problem be that the Dev Container is running on a different architecture (amd64) than my local architecture (arm64)? What if the Dev Container runs on the same local architecture (amd64 on amd64)? In the past, I’ve used the Remote Development using SSH functionality to develop on a Raspberry PI and it works just fine… but you require SSH access and your code needs to live on that machine. That said, you can use this mechanism to run a Dev Container there as well.

Now, I recently learnt about an alternative….having your code locally but running a Dev Container remotely by using a tunnel. Enter Remote Tunnels.

Remote Tunnels

The Visual Studio Code Remote - Tunnels extension lets you connect to a remote machine, like a desktop PC or virtual machine (VM), via a secure tunnel. You can connect to that machine from a VS Code client anywhere, without the requirement of SSH². The tunnel uses Microsoft dev tunnels to establish the communication between your local VS Code and the VS Code in the remote machine. For this, you will need to authenticate using a GitHub or Microsoft account.

Dev Container running remotely

In order to set this up you need to have access to a remote machine/VM. In my case, a remote VM that runs the desired architecture (amd64). Fortunately, I have an Unraid server at home, where I spun up a Debian VM and I can run a remote tunnel by using the VS Code CLI. It was a matter of downloading the CLI, install it, authenticate and of you go.

sudo apt install ./<file>.deb

# Run tunnel
code tunnel

# Run tunnel as a service
code tunnel service install

# Check tunnel logs
code tunnel logs

What’s great about this approach is that you don’t need SSH access in the remote machine and you can run the Dev Containers in the right architecture on the remote machine.

Steps:

• Enter about:debugging in the URL bar.
• In the left-hand menu, click This Firefox.
• Click Inspect next to the extension.

Debugging Brief Firefox extension

Check out why it was failing… https://community.sap.com/t5/what-s-new/additional-sap-community-feeds/bc-p/13633765/highlight/true#M416.

You can find more details regarding the SAP Community feeds here: Exploring the RSS feeds of the new SAP Community platform and Additional SAP Community feeds 📡.

Below is the GitHub action that I added to the feeds repo.

name: Issue assignment
on:
  issues:
    types: [opened, unassigned]
jobs:
  auto-assign:
    runs-on: ubuntu-latest
    permissions:
      issues: write
    steps:
      - name: "Auto-assign issue"
        uses: pozil/auto-assign-issue@v1
        with:
          assignees: your_username
          numOfAssignee: 1
          allowSelfAssign: true

Dockerfile

FROM --platform=linux/amd64 python:3.12.2-slim-bullseye

CMD ["echo", "The python:3.12.2-slim-bullseye image is working!"]

.devcontainer.json

{
	"name": "Python 3 DockerHub",
	// Or use a Dockerfile or Docker Compose file. More info: https://containers.dev/guide/dockerfile
	// "image": "mcr.microsoft.com/devcontainers/python:1-3.12-bullseye",

	"build":{
		"dockerfile": "Dockerfile"
	},

	// Features to add to the dev container. More info: https://containers.dev/features.
	// "features": {},

	// Use 'forwardPorts' to make a list of ports inside the container available locally.
	// "forwardPorts": [],

	// Use 'postCreateCommand' to run commands after the container is created.
	"postCreateCommand": "pip3 install --user -r requirements.txt",

	// Configure tool-specific properties.
	// "customizations": {},

	// Uncomment to connect as root instead. More info: https://aka.ms/dev-containers-non-root.
	// "remoteUser": "root"
}

CloudEvents at SAP

Before we dive into how CloudEvents have been adopted within SAP, we might need to talk a bit about what an Event-Driven architecture is and what a CloudEvent is as well. Let’s get started.

Event-Driven Architectures

Long gone are the days when a system (aka target system) will constantly poll to check if there are any changes in another system, e.g. a new customer created in a master data system. Traditionally, the target system will only know this by programming a routine that will poll a file share and check for any files produced by this system or a web service exposed in the source system, every X minutes/hours/days. The expectation nowadays is that systems are integrated and that the data exchanged between these systems will be immediately available in the target system(s) if any data is created/changed in the source system. Enter Event-Driven architectures.

An Event-Driven Architecture is a software architecture paradigm concerning the production and consumption of events. An event can be defined as a significant change in the state of an object within a system¹. For example, when a customer/supplier/employee (business object) is created/updated/deleted (action) in a system. Translating this to the SAP world, when a Business Partner is created/changed in SAP S/4HANA (source system), SAP S/4HANA can notify that there was a change in a business object and target system(s) interested in the Business Partner object can then react (do something about it) if they need to. This could be create/update/delete the object in their systems.

How do source and target systems communicate?

Now, if the source system lets other systems know of any changes happening in its business objects, it will not be sustainable to create a new programming routine within the source system every time we want to notify a new target system of any changes. Traditionally we would have some form of middleware, e.g. SAP Cloud Integration, and configure our source system, an SAP S/4HANA system, to send notifications of these events to the middleware and then use the middleware to distribute these messages, e.g. we would add target system(s) as needed. Now, we are moving the problem from the source system to a sort of middleware but ideally, there will be a way for the source system to notify others without the need to make any changes. Enter the event broker.

An event broker is message-oriented middleware that enables the transmission of events between different components of a system, acting as a mediator between publishers and subscribers. It is the cornerstone of event-driven architecture, and all event-driven applications use some form of event broker to send and receive information².

By introducing an event broker in our landscapes, we can configure our source systems to publish their events to this message-oriented middleware. The source system will specify the class of the message (aka topic). Then, systems interested in the changes happening, e.g. in a particular business object in the source system, can subscribe to the event(s), via the event broker, by specifying the topic they are interested in. There are two keywords important here, publish and subscribe (PubSub), this is a well-known messaging pattern used to decouple systems/applications and allow asynchronous communication between them.

What is the PubSub messaging pattern?

Publish-subscribe is a communication pattern that is defined by the decoupling of applications, where applications publish messages to an intermediary broker rather than communicating directly with consumers (as in point-to-point)³. In a way, publishers and consumers do not need to know each other; they simply publish (produce) or consume (receive) the events. When following this messaging pattern we move from, the traditional polling mechanism to know if there have been any changes in the source system, to reacting to real-time events (notifications) the moment something happens in the source system.

PubSub messaging pattern

We mentioned before how target systems can subscribe to events by specifying a topic they are interested in…. some event brokers will allow subscribers to subscribe to topics by using wildcards (*) and they will be able to receive events for different topics. For example, let’s assume we have an SAP S/4HANA with the name S4D and it publishes the Business Partner create and change on the following topics: sap/S4HANAOD/S4D/ce/sap/s4/beh/businesspartner/v1/BusinessPartner/Created/v1 and sap/S4HANAOD/S4D/ce/sap/s4/beh/businesspartner/v1/BusinessPartner/Changed/v1. A subscriber system could subscribe to both topics using a wildcard, e.g. sap/S4HANAOD/S4D/ce/sap/s4/beh/businesspartner/v1/BusinessPartner/*/v1 and receive the messages for both event types.

SAP offers different services that can act as event brokers. We will discuss this further in the SAP’s event-driven portfolio section.

With many systems in our landscapes and each one being developed by different vendors/teams, it would be good if there was a standard way of structuring these events to simplify how systems create/handle/process these messages right? Enter CloudEvents.

What is CloudEvents?

CloudEvents

Today’s system landscapes are very complex and we need to deal with many systems communicating with each other, ideally as close to real-time as possible. Nowadays, a system can publish events to notify other systems of the changes happening within the objects of their system. Given that we are talking of many systems, ideally, there will be a common way of describing the data produced by these systems. The CloudEvents specification can help us with this. We can leverage it to provide a consistent way for how our systems can communicate with others about these events.

As mentioned on the CloudEvents website… CloudEvents is a specification for describing event data in a common way. It’s goal is to simplify event declaration and delivery across services, platforms and beyond! The specification is now under the Cloud Native Computing Foundation.

Below is an example of what a CloudEvent message will look like:

{
  "specversion" : "1.0",
  "type" : "com.github.pull_request.opened",
  "source" : "https://github.com/cloudevents/spec/pull",
  "subject" : "123",
  "id" : "A234-1234-1234",
  "time" : "2018-04-05T17:31:00Z",
  "comexampleextension1" : "value",
  "comexampleothervalue" : 5,
  "datacontenttype" : "text/xml",
  "data" : "<much wow=\"xml\"/>"
}

You’ll notice that the example above is composed of many attributes. These attributes describe the event and are independent of the event data. Meaning that we can somehow process/inspect the event without needing to process its data. Now, let’s dive a bit into the message itself.

For more information on the history, development and design rationale behind the specification, see the CloudEvents Primer document.

CloudEvents message format

A CloudEvent message is mainly composed of context attributes and data.

Context Attributes

A number of attributes can be included within the message, these attributes are known as Context Attributes and the idea is that these context attributes can be used to describe the event. We can think of these context attributes as the header information of our event. Let’s explore some of the attributes available.

CloudEvent context attributes

Extension Context Attributes

A CloudEvent message may also include additional context attributes, which are not defined as part of the specification. These additional attributes are known as “extension attributes” and can be used by the producer systems to include additional metadata to an event, similar to how we can use HTTP custom headers.

For example, in the SAP Digital Vehicle Hub Business Events package, we can see that the event raised when a vehicle changes - sap.dmo.dvh.Vehicle.Changed.v1, contains the extension context attribute sappassport, which is an SAP specific tracing identifier.

{
  "specversion": "1.0",
  "type": "sap.dmo.dvh.Vehicle.Changed.v1",
  "source": "/eu10/sap.dmo.dvh",
  "subject": "808E6E30B65149978A443429B29FB300",
  "id": "a823e884-5edc-4194-a81a-f3a3632417ee",
  "time": "2018-04-08 08:31:00",
  "datacontenttype": "application/json",
  "sappassport": "string",
  ....
}

Data

A CloudEvent message may include a payload but this is not required. If included it will be in the format specified in the datacontenttype context attribute. Although it is not required, we will generally have a payload in messages. Below we can see an example of an event message that contains a payload. In this case, a Business Partner changed event generated by an SAP S/4HANA Cloud Public Edition.

{
    "type": "sap.s4.beh.businesspartner.v1.BusinessPartner.Changed.v1",
    "specversion": "1.0",
    "source": "/default/sap.s4.beh/244572008",
    "id": "63d6a150-c6a1-4c5b-bcc3-27d90c07941c",
    "time": "2024-02-26T10:53:06Z",
    "datacontenttype": "application/json",
    "data": {
        "BusinessPartner": "1000667"
    }
}

Check out the Business Partner changed event in the SAP Business Accelerator Hub - https://hub.sap.com/event/CE_BUSINESSPARTNEREVENTS/resource.

SAP’s adoption of CloudEvents

SAP is an active contributor to the CloudEvents specification and one of its many adopters. Evidence of that is the different products (event packages) that we can find documented in the SAP Business Accelerator Hub > Events category.

The products listed below document their events in the form of event packages in the SAP Business Accelerator Hub. All their events follow the CloudEvents specification:

• SAP Agricultural Origination Portal
• SAP Batch Release Hub for Life Sciences
• SAP Cell and Gene Therapy Orchestration
• SAP Cloud for Utilities Foundation
• SAP Digital Vehicle Hub
• SAP GRC Cloud - Issue Management and Remediation Service
• SAP Industry Process Framework
• SAP Intelligent Clinical Supply Management for Operations
• SAP Intelligent Clinical Supply Management for Planning
• SAP Landscape Management Cloud
• SAP Marketing Cloud
• SAP Order Management Foundation
• SAP S/4HANA
• SAP S/4HANA Cloud Public Edition
• SAP S/4HANA Utilities for Customer Engagement
• SAP S/4HANA for Procurement Planning Cloud
• SAP Subscription Billing

SAP’s flagship ERP products, SAP S/4HANA Cloud Public edition and SAP S/4HANA, expose more than 600+ events combined. As you might have noticed from the events that we use as examples above, these events follow the CloudEvents specification. Below we can see the Business Partner Created event generated by an SAP S/4HANA Cloud Public Edition and we can see how it follows the CloudEvents specification.

{
    "type": "sap.s4.beh.businesspartner.v1.BusinessPartner.Created.v1",
    "specversion": "1.0",
    "source": "/default/sap.s4.beh/244572008",
    "id": "194780e0-b5db-1ede-b58a-4550178dff9e",
    "time": "2024-02-26T09:50:00Z",
    "datacontenttype": "application/json",
    "data": {
        "BusinessPartner": "1000667"
    }
}

Kyma

Kyma runtime

Kyma contains an Eventing module, which provides functionality to publish and subscribe to CloudEvents. It follows the PubSub messaging pattern and all events in Kyma conform to the CloudEvents specification⁴. At the moment, NATS (provided by the NATS module) and SAP Event Mesh are supported as backends for eventing and it is recommended to use the CloudEvents specification for sending and receiving events. Even the legacy events are automatically converted to CloudEvents.

SAP’s event-driven portfolio

SAP event-driven portfolio

SAP offers various services that can help customers embrace event-driven architectures. The different offerings can meet customers where they are in their EDA adoption/implementation journey. These are:

• SAP Event Broker for SAP cloud applications
• SAP Event Mesh
• SAP Integration Suite, advanced event mesh

SAP Event Broker for SAP cloud applications

SAP Event Broker for SAP cloud applications

SAP Event Broker is the latest service released by SAP that focuses on event-driven architecture and it supports event-based integration between SAP cloud and BTP-based applications. It is a fully managed cloud service that allows SAP cloud applications to communicate asynchronously through events. Meaning it can be used to distribute events between SAP cloud applications. For example, this service can be leveraged to enable seamless integration between SAP S/4HANA Cloud public edition and SAP Subscription Billing. When an integration scenario leverages SAP Event Broker, it eliminates having to configure an event storage or infrastructure such as customer-defined topics or queues to enable the event-based integration between systems.

Integration between SAP S/4HANA Cloud and SAP Subscription Billing

CloudEvents are first-class citizens in SAP Event Broker, as events that are distributed between SAP cloud applications using SAP Event Broker all conform to the CloudEvent Specification⁵.

If all your event needs are within the SAP cloud world, e.g. exchange events between SAP cloud applications and SAP BTP, this service can fulfill your needs.

SAP Event Mesh

SAP Event Mesh

SAP Event Mesh allows applications to communicate through asynchronous events. It can be used to publish and consume business events from SAP and non-SAP sources across hybrid landscapes from the digital core (ERP products, e.g. SAP S/4HANA Cloud public edition and SAP S/4HANA) to extension applications through event-driven architecture. It is a fully managed centralised event-oriented service part of SAP BTP.

Centralised service

The service supports the use of REST APIs for Events, for publishing and consuming events that are compliant with the CloudEvents specification. Related to event-based integrations, events that flow through SAP Event Mesh between SAP applications must all conform to the CloudEvents specification.

You can check out how to enable the consumption of SAP S/4HANA Cloud public edition events in your SAP BTP account - https://youtu.be/4LspIL3NxqQ

SAP Integration Suite, advanced event mesh (AEM)

SAP Integration Suite, advanced event mesh

SAP Integration Suite, advanced event mesh (AEM) is a complete event streaming, event management, and monitoring platform that incorporates best practices, expertise, and technology for event-driven architecture (EDA) on a single platform. With AEM you can deploy event broker services, create event meshes, and optimize and monitor your event-driven system.

AEM offers these categories of services:

• Event Streaming: It provides event streaming services and gives you access to event broker services that provide advanced features like the publish-subscribe messaging pattern, queuing, streaming, replay, and request-reply, while doing all the heavy lifting to dynamically deploy, upgrade, patch, and operate the service. It extends beyond the cloud and supports infrastructure and EDAs across hybrid cloud solutions and your on-premises deployments.

  Event brokers can be deployed to: public clouds administered by SAP (Public Regions or Dedicated Regions) and customer’s own regions in the cloud or on-premises (Customer-Controlled Regions)

• Event Management: It provides event management services. The Event Portal provides powerful tools to create, design, share, and manage various aspects of your EDA based on event brokers or other streaming technologies. It fully supports the AsyncAPI 2.0.0 specification so that you can generate code, documentation, validate events, and apply API management policies for applications in your EDA.

  You might have noticed that some event specification in the SAP Business Accelerator Hub are documented using the AsyncAPI specification, e.g. Marketing Campaign Events part of SAP Marketing Cloud.

• Event Monitoring and Insights: Availability out-of-the-box of dashboards and easy-to-understand visualizations based on historical and real-time metrics, and timely notifications about the event broker services deployed.

Similar to SAP Event Mesh, it can be used to publish and consume business events from SAP and non-SAP sources across hybrid landscapes. Meaning, if your event data needs to exit the SAP cloud world, you can use any of these two services.

Thanks for making it this far, we’ve covered a lot in this blog post and I hope it gives you a general understanding of CloudEvents, its importance in the SAP world, how it can enable integration across SAP applications and the different SAP offerings that can enable your EDA journey.

In a previous blog post I shared the different RSS feeds that are available out of the box in the new SAP Community platform - Exploring the RSS feeds of the new SAP Community platform

Additional SAP Community RSS feeds

SAP Managed Tags (aka Topics)

The current platform doesn’t allow getting an RSS feed for an SAP Managed Tags, aka Topics. Not all topics available in SAP Community are included here. Below I’m sharing a sample of the topics available now and you’ll be able to see the full list here - topics.

You can suggest a new SAP Managed Tag feed by creating an issue in the GitHub repo.

SAP Community Members

Also, the current platform doesn’t allow getting an RSS feed for a community member. It will be quite an expensive task to generate a feed for every single member of the community, therefore I’m only including feeds for the Developer Advocates team and a couple of examples from SAP Mentors and SAP Champions. Below I’m sharing a sample of the community member feeds available now and you’ll be able to see the full list here - members.

You can suggest a new SAP Community Member feed by creating an issue in the GitHub repo.

I hope this helps filter out all the information that’s available in the SAP Community platform and that it can help you follow the information and members that you are really interested in.

Let’s keep the conversation going….

• LinkedIn: https://www.linkedin.com/posts/ajmaradiaga_additional-sap-community-feeds-activity-7165731257664884737-iarh
• Mastodon: https://fedi.ajmaradiaga.com/deck/@antonio/111964552620005324