Converting blockquotes to GitHub alerts

exercises/01-events-sap-ecosystem/README.md

@@ -49,6 +49,7 @@ As an example, let's use the [`Marketing Campaign Events`](https://hub.sap.com/e
 }
 ```
 
+> [!NOTE]
 > In the [Explore the Business Partner events available in SAP S/4HANA Cloud](#explore-the-business-partner-events-available-in-sap-s4hana-cloud) section below, we share an example of another notification event, this time from the Business Partner object produced by an SAP S/4HANA Cloud system.
 
 ### Data events
@@ -135,7 +136,8 @@ As part of this CodeJam, we will interact with the Business Partner data from an
 
 The event shared above would be considered a notification event, as it only contains the Business Partner ID that has been changed. As we can see it doesn't contain any information about the Business Partner itself, just the ID. If we would like to get more information about the Business Partner, we would need to call the [Business Partner (A2X) API](https://hub.sap.com/api/API_BUSINESS_PARTNER/overview), available in SAP S/4HANA Cloud, to get the details.
 
-🧭 Take some time to explore what's documented on the [Business Partner events - Overview page](https://hub.sap.com/event/CE_BUSINESSPARTNEREVENTS/overview). You will be able to find lots of valuable information here, e.g. [event reference](https://hub.sap.com/event/CE_BUSINESSPARTNEREVENTS/resource), event specifications (in JSON and YAML format), and a link to the [documentation](https://help.sap.com/docs/SAP_S4HANA_CLOUD/3c916ef10fc240c9afc594b346ffaf77/a75345282ddd4054a1e5ce7687e4b088.html?locale=en-US&state=PRODUCTION&version=2402.500).
+> [!IMPORTANT]
+> 🧭 Take some time to explore what's documented on the [Business Partner events - Overview page](https://hub.sap.com/event/CE_BUSINESSPARTNEREVENTS/overview). You will be able to find lots of valuable information here, e.g. [event reference](https://hub.sap.com/event/CE_BUSINESSPARTNEREVENTS/resource), event specifications (in JSON and YAML format), and a link to the [documentation](https://help.sap.com/docs/SAP_S4HANA_CLOUD/3c916ef10fc240c9afc594b346ffaf77/a75345282ddd4054a1e5ce7687e4b088.html?locale=en-US&state=PRODUCTION&version=2402.500).
 
 Now, you might have noticed that the event samples shared in this exercise are in JSON format and follow a specific format. They all contain a similar structure, some header information (metadata) describing the message, e.g. `id`, `type`, `specversion`, `source`, `type`, `datacontenttype` and a `data` node, which includes the actual payload. This is because SAP has adopted the CloudEvents specification as the common format for its systems/applications to publish events. In the next exercise, we will explore the CloudEvents format, which is a specification for commonly describing event data.
 

exercises/02-cloudevents/README.md

@@ -32,6 +32,7 @@ Below is an example of what a CloudEvent message will look like:
 
 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.
 
+> [!NOTE]
 > For more information on the history, development and design rationale behind the specification, see the [CloudEvents Primer](https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/primer.md) document.
 
 ## CloudEvents message format
@@ -97,6 +98,7 @@ A CloudEvent message may include a payload but this is not required. If included
 
 Now that we are familiar with the CloudEvent format, let's proceed to create our first CloudEvent message. For this, let's use as an example the ticket website included in the diagram of our event-driven integration scenario. Let's imagine that the ticket website generates an event after a customer purchases a ticket. The event generated includes customer information (BusinessPartner) and the number of tickets it wants to purchase. 
 
+> [!NOTE]
 > The goal of this exercise is to get familiar with the message format and create a sample event message that we can use in the future.
 
 👉 Create a CloudEvent message manually, that follows the CloudEvent specification, simulating the ticket website when a ticket is purchased. To validate your message use the JSON Schema Validator online service - [https://www.jsonschemavalidator.net/](https://www.jsonschemavalidator.net/). The CloudEvents schema is available in the repository - [https://raw.githubusercontent.com/cloudevents/spec/a15821bd345933de1971db333e9e37307d77c31f/cloudevents/formats/cloudevents.json](https://raw.githubusercontent.com/cloudevents/spec/a15821bd345933de1971db333e9e37307d77c31f/cloudevents/formats/cloudevents.json).
@@ -135,6 +137,7 @@ Below is an example of an event message that follows the CloudEvent specificatio
 }
 ```
 
+> [!IMPORTANT]
 > Did you notice that there is an error in the example above? Can you spot it? 🧐. It is not valid according to the schema. 
 
 To summarize, CloudEvents is a specification for describing event data in common formats. The goal is to provide interoperability across services, platforms and systems.
@@ -143,6 +146,7 @@ To summarize, CloudEvents is a specification for describing event data in common
 
 Event Formats specify how to serialize a CloudEvent with certain encoding formats. Depending on our requirements it is possible that we might need to use a specific format to encode our CloudEvent message. We might need to send the data in something different than the JSON format, e.g. [AVRO](https://github.com/cloudevents/spec/blob/main/cloudevents/formats/avro-format.md), [Protobuf](https://github.com/cloudevents/spec/blob/main/cloudevents/formats/protobuf-format.md). Check out the specification document if you want to learn more about these [different formats](https://github.com/cloudevents/spec/blob/main/cloudevents/formats/).
 
+> [!NOTE]
 > For simplicity purposes we will stick to the [JSON Event format](https://github.com/cloudevents/spec/blob/main/cloudevents/formats/json-format.md) as it is the most common and easiest to interact with.
 
 ## Summary

exercises/03-cloudevents-at-sap/README.md

@@ -46,6 +46,7 @@ SAP's flagship ERP products, SAP S/4HANA Cloud Public edition and SAP S/4HANA, e
 
 If you are curious about how to configure a connection between SAP S/4HANA Cloud and SAP Integration Suite, advanced event mesh, you can find the step-by-step guide at help.sap.com - [Integration with Advanced Mesh Service Plan for Service Cloud](https://help.sap.com/docs/SAP_S4HANA_CLOUD/0f69f8fb28ac4bf48d2b57b9637e81fa/9b34c841dfba4f82af0825a2f3196ecf.html?locale=en-US). This was recently introduced in the [SAP S/4HANA Cloud 2402 release](https://help.sap.com/docs/SAP_S4HANA_CLOUD/ee9ee0ca4c3942068ea584d2f929b5b1/5fd69458026d47f7bcc11837b42c5371.html?locale=en-US&version=2402.500).
 
+> [!TIP]
 > Prefer watching a step-by-step video ? Check out the [SAP Tech Bytes: Configuring SAP S/4HANA Cloud and SAP Integration Suite, advanced event mesh](https://www.youtube.com/watch?v=6hb9l0ss5ec) 📺.
 
 ### Cloud Application Programming model
@@ -69,6 +70,7 @@ CAP messaging has built-in support for formatting event data compliant with the
 
 With this setting, all mandatory and some more basic header fields, like `type`, `source`, `id`, `datacontenttype`, `specversion`, `time` are filled in automatically. The event name is used as `type`. The message payload is in the `data` property.
 
+> [!IMPORTANT]
 > Although we will be using CAP in this CodeJam, we will not be able to leverage this built-in support as we will be using the SAP Integration Suite, advanced event mesh to publish and consume events. Also, we will be using the CloudEvents SDK to create CloudEvents programmatically.
 
 ### Kyma
@@ -115,6 +117,7 @@ If all your event needs are within the SAP cloud world, e.g. exchange events bet
 
 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](https://help.sap.com/docs/event-mesh/event-mesh/event-mesh-default-plan-concepts?locale=en-US "https://help.sap.com/docs/event-mesh/event-mesh/event-mesh-default-plan-concepts?locale=en-US") service part of SAP BTP.
 
+> [!IMPORTANT]
 > SAP Event Mesh is intended to move into SAP Integration Suite, as a new capability, in Q2 2024. You can find more details in [https://roadmaps.sap.com](https://roadmaps.sap.com/board?PRODUCT=000D3A47875C1EDB98A8A910864AC24B&range=FIRST-LAST#;INNO=C1FBB5A935A51EDDA5E7942074F76CBC).
 
 ![event-mesh-diagram.png](assets/event-mesh-diagram.png "event-mesh-diagram.png")
@@ -136,10 +139,12 @@ 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.
 
+    > [!NOTE]
     > 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.
 
+    > [!NOTE]
     > 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](https://hub.sap.com/event/CE_MARKETINGCAMPAIGNEVENTS/overview "https://hub.sap.com/event/CE_MARKETINGCAMPAIGNEVENTS/overview") 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.

exercises/04-event-driven-architectures/README.md

@@ -36,6 +36,7 @@ We mentioned before how target systems can subscribe to events by specifying a t
 
 In some other cases, the event broker will allow the subscriber to specify which messages they want to receive, based on the attributes or content of the message. For example, the message sent to the event broker can contain attributes that describe the message and we can do some filtering based on the values of those attributes. *Note: An example is shared later, on how attributes in a message (CloudEvent) can be used to define filters.*
 
+> [!NOTE]
 > SAP offers different services that can act as event brokers. These were discussed in the previous exercise.
 
 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? This is why we discussed [CloudEvents](https://CloudEvents.io/) previously.

exercises/05-explore-aem/README.md

@@ -147,6 +147,7 @@ Just as a quick test, let's use the CodePen projects section to quickly establis
     <i>Try Me! - Message exchange</i>
 </p>
 
+> [!NOTE]
 > We will dive deeper into the message exchange in the next exercise.
 
 #### Event broker service as part of Cluster
@@ -195,6 +196,7 @@ Insights provide us with a centralised place where we can monitor various aspect
 
 From here, you will also be able to access dashboards available in Datadog if [Insights advanced monitoring has been enabled](https://help.pubsub.em.services.cloud.sap/Cloud/Insights/Advanced-Monitoring/access-datadog.htm). We will not cover it in this CodeJam but you can learn more about it in the [documentation](https://help.pubsub.em.services.cloud.sap/Cloud/Insights/Advanced-Monitoring/using-dashboards.htm). One thing to highlight here is that if you already use Datadog, it will be possible to [forward the Insights data](https://help.pubsub.em.services.cloud.sap/Cloud/Insights/insights_data_forwarding.htm) to your own Datadog account.
 
+> [!TIP]
 > 💡 An idea.... once we start exchanging messages in SAP Integration Suite, advanced event mesh, remember to visit the Insights section so that you can see how the number of messages
 
 ## Summary

exercises/06-publish-and-subscribe-events/README.md

@@ -7,6 +7,7 @@ In a previous exercise, we learned more about Event-Driven Architecture and we a
   <i>Try Me! with Queue functionality</i>
 </p>
 
+> [!IMPORTANT]
 > 🚨 You might have noticed that the `Try Me!` page in the screenshot above has more functionality than the one we used in the previous exercise. To differentiate between both of them I will refer to the one in the screenshot as "**`Advanced Try Me!`**" and to the one used in the previous exercise as "`CodePen Try Me!`". 🚨
 
 ## Topics
@@ -22,10 +23,12 @@ Example: `sap/S4HANAOD/E4L/ce/sap/s4/beh/businesspartner/v1/BusinessPartner/Crea
 - */Created*: This is the action that took place in the source system. In this case, it is notifying us that a BusinessPartner was created. Many actions can take place in a system, e.g. this could be `/Updated`, `/Deleted`. In other cases, if we were dealing with a business object like a PurchaseOrder, there could be an event raised when it is `/Cancelled` or `/Rejected`.
 - */v1*: Version of the message. If a new version of the message is made available, e.g. adding new fields to the payload, then this will change.
 
+> [!NOTE]
 > In our case, we've defined levels on our topic string based on the week, SAP Community username and action, e.g. `codejam/edi/ce/ajmaradiaga/notification`.
 
 Now, by knowing the topic on which a message type will be published, we can create a consumer program/service that subscribes to the topic directly and processes the messages sent to it. Generally, you can subscribe to a topic by specifying the entire topic string when establishing the connection, e.g. *sap/S4HANAOD/E4L/ce/sap/s4/beh/businesspartner/v1/BusinessPartner/Created/v1*. But what if we want to subscribe to all actions (Created, Updated, Deleted) that occur on a BusinessPartner object? Luckily, in the case of SAP Integration Suite, advanced event mesh we can subscribe to the topic by using wildcards (\*). For example, by subscribing to the topic sap/S4HANAOD/E4L/ce/sap/s4/beh/businesspartner/v1/BusinessPartner/*/v1 I will be able to get all messages for different actions (Created, Updated, Deleted) whose version is v1. In AEM, the > character can be used at the last level of a subscription to indicate a "one or more" wildcard match for any topics, e.g. by subscribing to the topic *sap/S4HANAOD/E4L/ce/sap/s4/beh/>* will bring all objects that are published under that prefix, independent of type, action, and version.
 
+> [!TIP]
 > In the example above we can see how the topic level granularity can allow a consumer program/service to subscribe only to the information it needs. To learn more about wildcard characters in topic subscriptions 👉: [https://help.pubsub.em.services.cloud.sap/Messaging/Wildcard-Charaters-Topic-Subs.htm](https://help.pubsub.em.services.cloud.sap/Messaging/Wildcard-Charaters-Topic-Subs.htm)
 
 If our consumer program/service subscribes to a topic, we will receive all messages for that topic subscription. That said, a direct topic subscription lasts only as long as the consumer is connected. The problem here is that our consumer needs to be online to receive a message. If the consumer becomes unavailable then we will end up losing the message. In some scenarios, this is unacceptable and we need to ensure that we receive and process all messages published. Fortunately, there is a mechanism to retain messages without the need for a consumer service to be online 100%. Then, the consumer can process the messages asynchronously or whenever it is available. Enter Queues.
@@ -150,10 +153,12 @@ As explained previously, we can subscribe to a topic directly and so far we've c
 
 ## Create a Queue
 
+> [!IMPORTANT]
 > 🚨 Before we create a queue, make sure you open the `Queues` link in a new tab, so that you don't have to re-enter the credentials in the `Advanced Try Me!` page and connect again to the event broker.
 
 👉 Select the `Queues` link on the right-hand side to see the queues in the event broker service. Click the `+ Queue` button and enter a name, e.g. `codejam/edi/ce/[your-sap-community-username]/tickets`. Leave the default settings and add as a subscription the following: `codejam/edi/ce/[your-sap-community-username]/tickets/*`.
 
+> [!NOTE]
 > You'll notice that we are "adding levels" in the queue name. This is not really necessary and similar to topic names, it is a string and it can be anything. We are just following a pattern to make it easier to understand what the queue is for.
 
 <p align = "center">
@@ -178,17 +183,17 @@ If you've published a message after creating the queue, some messages would have
 
 In the examples above we've not changed the Delivery Mode. Two delivery modes are possible in AEM, Direct and Persistent. By default, the delivery mode will be `Direct` which can have some limitations in terms of message delivery. For example, the message doesn't require acknowledgment of receipt by subscribing clients and messages aren't retained for a client when it's not connected to an event broker. This means that we can end up losing messages and in some scenarios, this is perfectly fine and acceptable but that might not be the case always. Fortunately, we are also able to change the delivery mode to `Persistent` which ensures that messages are retained in the event broker until they are acknowledged by the consumer. It keeps a copy of the message until successful delivery to all clients and downstream event brokers has been verified. This will be a more reliable way to ensure that messages are not lost.
 
-🧭 Take some time to explore further what we've learned in this exercise. Some ideas:
-
-- Publishing:
-  - Try publishing some additional messages on the topic and see how they are received in the subscriber section.
-  - Change the delivery mode before publishing a message and see how it affects the message delivery. 
-  - Changing the topic where it is published.
-- Manage your queue:
-  - Add new topic subscriptions to your queue.
-  - Look at the stats of your queue.
-  - When consuming messages from the Advanced Try Me! page, check the Consumers listed in the Queue.
-- Stop consuming messages from the queue and see how the messages are accumulated in the queue. Check the queue stats in `Queues`.
+> [!TIP]
+> 🧭 Take some time to explore further what we've learned in this exercise. Some ideas:
+> - Publishing:
+>   - Try publishing some additional messages on the topic and see how they are received in the subscriber section.
+>   - Change the delivery mode before publishing a message and see how it affects the message delivery. 
+>   - Changing the topic where it is published.
+> - Manage your queue:
+>   - Add new topic subscriptions to your queue.
+>   - Look at the stats of your queue.
+>   - When consuming messages from the Advanced Try Me! page, check the Consumers listed in the Queue.
+> - Stop consuming messages from the queue and see how the messages are accumulated in the queue. Check the queue stats in `Queues`.
 
 ## Clean-up