diff --git a/exercises/01-events-sap-ecosystem/README.md b/exercises/01-events-sap-ecosystem/README.md index ab172c8..741c01f 100644 --- a/exercises/01-events-sap-ecosystem/README.md +++ b/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. diff --git a/exercises/02-cloudevents/README.md b/exercises/02-cloudevents/README.md index 14b3e01..ad9e8ae 100644 --- a/exercises/02-cloudevents/README.md +++ b/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 diff --git a/exercises/03-cloudevents-at-sap/README.md b/exercises/03-cloudevents-at-sap/README.md index 686497c..a1dd96a 100644 --- a/exercises/03-cloudevents-at-sap/README.md +++ b/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. diff --git a/exercises/04-event-driven-architectures/README.md b/exercises/04-event-driven-architectures/README.md index 25b7588..fa19c49 100644 --- a/exercises/04-event-driven-architectures/README.md +++ b/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. diff --git a/exercises/05-explore-aem/README.md b/exercises/05-explore-aem/README.md index b696844..96cdd6b 100644 --- a/exercises/05-explore-aem/README.md +++ b/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 Try Me! - Message exchange

+> [!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 diff --git a/exercises/06-publish-and-subscribe-events/README.md b/exercises/06-publish-and-subscribe-events/README.md index 20e6ab6..4c50c35 100644 --- a/exercises/06-publish-and-subscribe-events/README.md +++ b/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 Try Me! with Queue functionality

+> [!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.

@@ -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 diff --git a/exercises/07-dynamic-message-routing/README.md b/exercises/07-dynamic-message-routing/README.md index 1b4cdd3..8342dbd 100644 --- a/exercises/07-dynamic-message-routing/README.md +++ b/exercises/07-dynamic-message-routing/README.md @@ -15,7 +15,6 @@ What's great about DMR is that the event brokers dynamically discover how to rou DMR is a key feature of the event mesh that allows you to scale your event mesh horizontally and across sites (multi-site). Let's explore this further. - - Horizontal Scaling: When we are creating an event broker service, we can define the DMR cluster name. By default, a new event broker service is set up as a single-node cluster but they can be part of a DMR cluster by specifying the same DMR cluster name. In a DMR cluster, each node is connected to every other node in the cluster. These connections within the same cluster are called internal links.

DMR - Horizontal scaling
@@ -28,6 +27,7 @@ DMR is a key feature of the event mesh that allows you to scale your event mesh DMR - Multi-site scaling

+> [!NOTE] > The EDI CodeJam mesh, configured in the AEM instance that we are using as part of the event, is composed of three event broker services, each in a different region and each event broker service is a single-node cluster. This will be an example of multi-site scaling. ## DMR in action diff --git a/exercises/08-cloudevents-sdk/README.md b/exercises/08-cloudevents-sdk/README.md index 191ec08..6af411c 100644 --- a/exercises/08-cloudevents-sdk/README.md +++ b/exercises/08-cloudevents-sdk/README.md @@ -90,10 +90,10 @@ npm install In this folder, we have a few files that we need to get familiar with: -- package.json: Contains the dependencies of our simple application. -- .env.sample: Contains the environment variables that we need to set. -- app.js: At the moment, the file is mostly empty. We are importing the CloudEvents SDK dependencies, loading some environment variables, and importing a module that is responsible for sending the CloudEvent message to a topic in SAP Integration Suite, advanced event mesh. This is the file that we will be working on. -- emitter.js: This file contains the code that sends the CloudEvent message to the topic in SAP Integration Suite, advanced event mesh. It uses the REST API available in AEM to send a message to a topic. +- `package.json`: Contains the dependencies of our simple application. +- `.env.sample`: Contains the environment variables that we need to set. +- `app.js`: At the moment, the file is mostly empty. We are importing the CloudEvents SDK dependencies, loading some environment variables, and importing a module that is responsible for sending the CloudEvent message to a topic in SAP Integration Suite, advanced event mesh. This is the file that we will be working on. +- `emitter.js`: This file contains the code that sends the CloudEvent message to the topic in SAP Integration Suite, advanced event mesh. It uses the REST API available in AEM to send a message to a topic. ๐Ÿ‘‰ Make a copy of the `.env.sample` file and name it `.env`. Place it in the same folder as where the `.env.sample` file resides. @@ -181,9 +181,11 @@ If everything went well, you should see the CloudEvent message printed in the co Output of program app.js

+> [!CAUTION] > Note: If you see an error message, make sure that you have set the environment variables correctly in the `.env` file. Also, a solution for this exercise is available in the `.sap/code/08-cloudevents-sdk` folder. -๐Ÿ’ก You can subscribe to the `codejam/edi/ce/[your-sap-community-username]/nodejs` topic, via the `CodePen Try Me!` page, to see the CloudEvent message being published. +> [!TIP] +> ๐Ÿ’ก You can subscribe to the `codejam/edi/ce/[your-sap-community-username]/nodejs` topic, via the `CodePen Try Me!` page, to see the CloudEvent message being published. ## Summary diff --git a/exercises/09-rest-delivery-points/README.md b/exercises/09-rest-delivery-points/README.md index df33a57..c4a60b0 100644 --- a/exercises/09-rest-delivery-points/README.md +++ b/exercises/09-rest-delivery-points/README.md @@ -6,10 +6,12 @@ Now that we are familiar with the SAP Integration Suite, advanced event mesh, ho There are scenarios where the target system/application can't consume messages directly from an event broker but we still want these systems/applications to be part of our event-driven world and react to events as they are produced. Fortunately, some of these systems might expose APIs (REST endpoints) through which we can notify them of an event. For these cases, we can leverage REST Delivery Points to forward messages from a queue to that system. For example, the integration between SAP S/4HANA Cloud and SAP Build Process Automation goes through SAP Event Mesh. In SAP Event Mesh we end up configuring a [webhook subscription](https://help.sap.com/docs/event-mesh/event-mesh/manage-webhook-subscriptions) to [forward the events received and start a process](https://help.sap.com/docs/build-process-automation/sap-build-process-automation/create-event-triggers) in SAP Build Process Automation. +> [!TIP] > It is now also possible to configure a REST Delivery Point in SAP Integration Suite, advanced event mesh to forward messages from a queue to SAP Build Process Automation and trigger a process. You can check out this [SAP Tech Bytes: SAP S/4HANA Cloud + SAP Integration Suite, AEM + SAP Build Process Automation](https://community.sap.com/t5/application-development-blog-posts/sap-tech-bytes-sap-s-4hana-cloud-sap-integration-suite-aem-sap-build/ba-p/13706661). If you remember the CodeJam's [integration scenario](../../../README.md#integration-scenario), we have an SAP S/4HANA Cloud System that generates events whenever a performer is added to the system (BusinessPartner) and we would like to trigger the "*Performer requirement checks*" process in SAP Build Process Automation. Although we will not be creating a process/interacting with SAP Build Process Automation in this CodeJam, it is important to understand the mechanism available to forward events to systems that expose REST endpoints. Therefore, we will forward messages from a queue to a REST consumer similar to how we would do it if we would like to forward the message to SAP Build Process Automation. From now on, we will refer to these types of systems as **REST consumers**. +> [!TIP] > If you are interested in exploring how you can configure the webhook subscription mentioned above in SAP Event Mesh, you can check out this [SAP Tech Bytes: Deliver events from SAP EventMesh to SAP Build Process Automation](https://community.sap.com/t5/technology-blogs-by-sap/sap-tech-bytes-deliver-events-from-sap-eventmesh-to-sap-build-process/ba-p/13574547). By the end of this exercise, we will achieve a communication scenario like the one below. @@ -51,6 +53,7 @@ You will be prompted to enter a name and if you want to clone its topic subscrip ๐Ÿ‘‰ Enter a name for the cloned queue, e.g. `S4HC/BP/Created_[your_sap_community_id]` and select the `Children to Clone - Subscriptions` check box. Finalise by clicking the **Apply** button. +> [!NOTE] > There is a separate service which is simulating the creation of BusinessPartner objects in SAP S/4HANA Cloud. It will also be publishing the events to the `sap/S4HANAOD/S4D/ce/sap/s4/beh/businesspartner/v1/BusinessPartner/Created/v1` topic. Meaning that once you've created the cloned queue, you should start seeing messages in the cloned queue. That said, it is very simple 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). ## Create a REST Delivery Point diff --git a/exercises/10-consume-message-from-CAP/README.md b/exercises/10-consume-message-from-CAP/README.md index 20be7a2..66e0873 100644 --- a/exercises/10-consume-message-from-CAP/README.md +++ b/exercises/10-consume-message-from-CAP/README.md @@ -53,6 +53,7 @@ We can use different protocols to connect with AEM, this will depend on our need Also, there are many connectivity options available depending on your favourite programming language. +> [!TIP] > Check out the tutorials available for the different programming languages - https://tutorials.solace.dev/.

@@ -75,6 +76,7 @@ We will start getting familiar with the CAP project that is included within the ๐Ÿ‘‰ Open the CodeJam repository in SAP Business Application Studio +> [!NOTE] > Instructions on how to clone the repository are included in the [prerequisites](../../../prerequisites.md#sap-business-application-studio).

@@ -166,6 +168,7 @@ If there are no messages in the queue then it will block until a message is rece If not, then it will process the messages available in the queue and at this stage, it will just print out the message in the terminal. +> [!NOTE] > Don't worry if we are "losing" this messages and not processing them properly. This is intended and we will add the logic to process the message in the next steps. ## Validate the message against a CloudEvents schema diff --git a/exercises/11-aem-cloud-integration-adapter/README.md b/exercises/11-aem-cloud-integration-adapter/README.md index daa05b2..57beb9c 100644 --- a/exercises/11-aem-cloud-integration-adapter/README.md +++ b/exercises/11-aem-cloud-integration-adapter/README.md @@ -13,6 +13,7 @@ Now, in this exercise, we will consume the events from AEM using the Cloud Integ Consuming and publishing messages from a Cloud Integration iFlow

+> [!NOTE] > The goal of this exercise is not to create an integration flow from scratch but to get familiar with the AEM integration adapter and understand the connectivity mechanism between AEM and Cloud Integration. Before we get started, make a note of the connection details for the Solace Messaging adapter available in the `EU-North-Broker` service, as we will be using these details in the integration flow configuration. @@ -52,6 +53,7 @@ Take note of the secure parameter name as we will be using it in the integration ### Import the Advanced Event Mesh adapter +> [!IMPORTANT] > Importing the Advanced Event Mesh adapter from the SAP Business Accelerator Hub to the tenant might not be always necessary, as the adapter might be already available in the tenant. For example, if you have already used the adapter in a different integration flow, then the adapter will be available in the tenant. Also, the first time you set up a Sender/Receiver to use the AdvancedEventMesh adapter, it will automatically get the adapter from the SAP Business Accelerator Hub and deploy it in the tenant. Not the case in this exercise as we are importing an existing integration flow and we aren't setting up the connections from scratch. The steps below are provided for the case when the adapter is not available in the tenant. ๐Ÿ‘‰ Go to your SAP Integration Suite instance and navigate to `Discover` > `Integrations`, search for `Advanced Event Mesh` and select the Advanced Event Mesh adapter for SAP Integration Suite. @@ -87,13 +89,13 @@ Once imported, you will see the integration flow in the `Artifacts` tab of the i As stated at the beginning, the integration flow is very simple, it consumes the purchased tickets events from the queue in AEM, enriches the message and publishes it to a topic. -๐Ÿงญ Take some time to explore the integration flow itself...Some ideas: - -- Check the tabs and configuration options available in the sender adapter (Connection, Processing). -- Check the tabs and configuration options available in the sender adapter (Connection, Processing, Message properties). -- What are we doing in the Groovy script that's enriching the message? -- Which is the Transport Protocol used by the adapters? -- Which is the Message Protocol used by the adapters? +> [!TIP] +> ๐Ÿงญ Take some time to explore the integration flow itself...Some ideas: +> - Check the tabs and configuration options available in the sender adapter (Connection, Processing). +> - Check the tabs and configuration options available in the sender adapter (Connection, Processing, Message properties). +> - What are we doing in the Groovy script that's enriching the message? +> - Which is the Transport Protocol used by the adapters? +> - Which is the Message Protocol used by the adapters? Now that you are familiar with the integration flow, let's configure it. diff --git a/exercises/README.md b/exercises/README.md index ac81a03..9d6a4db 100644 --- a/exercises/README.md +++ b/exercises/README.md @@ -2,6 +2,7 @@ During the CodeJam, you will complete each exercise one at a time. At the end of each exercise, questions are included to help you think about the content just covered and are to be discussed with the entire CodeJam class, led by the instructor, when everyone has finished that exercise. +> [!NOTE] > By the end of the CodeJam, we will achieve an Event-driven integration scenario like the one below in the diagram. >