Name: [Webinar] Event-Driven Integrations
Uploaded: 2025-09-03T10:16:04.415Z
Duration: 56 min 43 s
Description: [Webinar] Event-Driven Integrations

Transcript for "[Webinar] Event-Driven Integrations": Okay. I think we have a good amount of people who've joined us. So I'm very happy to welcome you all today to this webinar on event driven integrations. My name is Seenem. I'm marketing manager at SnapLogic, and I am joined today by Shashank, enterprise integration architect at Rocco, and Konstantin, principal solutions engineer at SnapLogic, who will be walking you through today's webinar. Before we get started, a couple of housekeeping points in advance as per usual. The first one is that the session will be recorded, which means that you will receive the recording afterwards. I would still encourage you to stay live, because you will have the opportunity to ask questions and interact with us, which brings me to the next point. We have the chat box, so feel free to say hi in the chat. And if you want to ask some questions, there is a q and a box right next to the chat box, and we will make sure to cover your questions at the end during the q and a session. Let's go on to the next slide, please. So who are we? I know that a couple of you already know who we are, but this is an introduction for everyone that's new, on who we are from SnapLogic's side and Ajo's side. So SnapLogic, connects data, apps, and AI to automate work and scale. We work with companies like AstraZeneca, Adobe, Sony, and also a couple of Siemens companies. Our mission is to basically make it easy for companies to build secure fast workflows with low code tools, and we have a long standing legacy and experience in AI. Wahoo, our partner today, brings deep ex experience and expertise in integration strategy and delivery. They help companies to modernize how they handle data end to end from initial planning all the way through to ongoing support. And with that, let's go into the agenda of today. So we will start off with a quick overview over SnapLogic, which is going to be a bit more technical than what I've mentioned earlier. Then we will have a look at integration domain modernization, and then we will have a couple of more, practical use cases, into master data synchronization and CRM data consolidation, and then a look at data mesh. And at the end, we're gonna wrap up the session with the q and a part. And with that, I'm happy to hand over to Konstantin and to Shashank. Fantastic, Seenem. Thank you for the great intro and also warm welcome from my side. Let us jump right into the overview of SnapLogic. This is especially helpful for everybody who doesn't know, or doesn't know our platform. As data is the absolute as absolute priority for most modern businesses, with our integration platform, we help you connect in different data sources in your enterprise. And for that, we have several main components. On the left side, you see our data integration capabilities, which help you to, connect any source system to a target system with the help of reusable components we, bring together in our prebuilt snaps. We have over 1,000 of those to help you really, integrate and link your various different systems you might have in your in your company. And, we allow this with a very easy tooling, which doesn't require any coding from your side. So you're free to go with configuring, SnapLogic to get the right data out of your systems, transform it, change it to your needs, combine maybe various different data sources together, and, save them or store them in the system of choice from your side. This goes without any coding or with very, very little coding. So, even citizen integrators, how we call them, are able to do so. App integration is a smaller subset of, data integration, which lays a strong emphasis on the, automation piece or the, the workflow behind data. So this means how do you, help and automate processes which span different applications? Let's say you start in your ERP system and you want to use the data there to create a quote in your CRM system. So you need to fetch this data. You need maybe to update it a little bit, change the format, and then, insert it in your quote so you can send this out to your customer. So that's what we understand on the app integration. It's automating your processes with your data in the context of a process. If you do both, data integration, app integration, you might come to a point where you want to, maybe share or, make the processes of the integrations you've built available to your customers, internal teams, partners. And that's where you need to, use, API management to securely share those endpoints with those parties so they can use it in a secure fashion. It's managed and, you can scale with the demand of the business. Across the whole platform, we offer you the capability to use our integrated copilot called SnapLogic GPT, which can help you with, analyzing any pipelines you've built with with the different, snaps. It can help you generate pipelines. It can also help you configure individual snaps and create expressions where you need them. So it, again, reduces the technical burden on the user so they can focus on what matters most, the process and the data they want to use. Quite recently, we also introduced with agent creator an additional set of capabilities which allow you to integrate, various different leading large language model providers, vector databases, but also brings, great tooling to really make it easy for the users to create agentic, applications or AI agents. So for example, we introduced the, prompt composer, which helps you create or customize prompts to to your needs, where you see side by side the data which is coming in your prompt an AI assistant to help you build this prompt and the actual result coming back from the AI, and also some other functionalities like the agent visual milestone. The whole platform, is, basically, all those components are in one platform. So you have a system wide governance, security, and observability in place. So it's a real enterprise solution to help you keep the administration effort low and bring a lot of value to your users. If you move on, we will see the, differentiators we can bring to the table to our customers and and prospects. Firstly, most prominently, I would say, is the ease of use with which you can build integrations with SnapLogic. It's, really, yeah, requires very little coding, if if not any at all. It can help your business users who have the best knowledge of of your processes to build their own integrations with some assistance maybe from, central teams which can help them and also ensures that you have the right security and governance in place. So they will manage, this centrally for all your business. And we have the capability before our SnapPaks to connect to any system you need during during execution. We have over 1,000 snaps available. And if you want a need, you can also build additional snaps and SnapPaks with our software development kit. Now what are the customers actually using this for? Right? So what can you do with SnapLogic? And here we see three main areas where we, bring value to our customers. The first one is basically, collecting and consolidating, data. Right? This is especially relevant because, with the numerous systems customers have in place, I think it's around 900 on average, an enterprise customer has in terms of applications. The data stored in those applications is is often kind of isolated. Right? Also, you might struggle with the distribution of data. The data needs to flow from one point to another in a streamlined fashion, or you sometimes lack relevant data. It's not accurate, or it's it's even old and outdated. Right? And here we have two use cases. The first one, this will, be covered by Shashank in the later parts of the presentation, so I will skip that one. With the second example, that's a typical case for data integration. You have multiple source systems, and you want to consolidate the data in one data warehouse or data lake. So we help you bring this data to, for example, system like Snowflake from various different source, Workday, Salesforce, or an SQL server. And once the data is there, you can use it to create your, BI dashboards and create reporting on top of that, which will help you to, create better reports and take better decisions afterwards and also provide the right and relevant data to your business partners. And second case is the whole context of process automation. In our modern times, the cost pressure is is quite high for for the companies operating there. You might face problems to hire skilled workers for the work. Right? So there is even more need for automating process because the existing workforce can't handle them if it grows. Also, if you think back on to COVID, where we had problems, like people getting sick or the supply chain gets disrupted, if you can automate your processes and increase capacity, right, with automation, you're better suited to handle those kind of situations and more resilient. And, also, it gives you a competitive edge. If you can be can do more with with less, it's always a little one touch here. Now, those two examples we have here, one is coming from a PLM system like Teamcenter. You might need to get product information, bring it to your ERP system in SAP, where you can then again use it to create, customer facing documents in your CRM system. So getting data over multiple applications in the context of a process, that's what is actually important here. When you think about AI, most of us have tried to check GPT and so on and and ask fancy questions. Right? We get good answers. But, in the context of a business or in an enterprise, that's not really value bring. Right? So where we can add value is when we provide the right context to those AI algorithms and solutions. So we need to bring data from our business and provide it to AI during run time. We can do this at scale and help you create the outcome you really desire from those, solutions and applications. This will help you boost employee productivity, increase the resiliency of the of the enterprise, and also increase your processes, improve your processes. Now when you do both of those areas, collecting data, automating processes at scale or try to. Right? You come to a point where you realize, connecting point a to b or maybe to c afterwards. It's not really, yeah, it it it has some challenges because you won't be able to reuse a lot of the stuff you're building. You might do redundant steps multiple times. So, data comps concept of composability comes in. Instead of doing everything in one pipeline, for example, getting data out of Salesforce, transforming it and sale and saving Snowflake, you can then basically chunk the process into several different layers. One would be the system and API layer. So getting data from Salesforce is just one one step here. Saving data to Snowflake is another one. And then, using, inter basically, the data from Salesforce and Snowflake would be done on a process layer, which can be, extended easily. And then you would have another layer on top of that where you decide, okay, who can use these kind of, functionalities. Are they only for professional developers in our enterprise? Are they for partners, for customers? Do we want to use them in our, on our home page, or can we also expose this to citizen developers? So you're able to have smaller building blocks like LEGO, and then you're able to, basically make them more reusable and reduce the amount of redundant work you you do in the integration space. Additionally, you will get some, great benefits that you can easily or more easily replace systems if the need is there. Let's say there's a fantastic new systems coming out and you want to change. But because you have those men and many integrations built and you would need to to change or update all those integrations, you now only need to update the, system APIs, which will get the data off the system. So that's a great solution to be able and more flexible. And, also, you can really focus on security, ease of use, and make reusable building blocks for your citizen developers. And with that, I conclude my overview of the platform and would like to pass over to Shankh with the use case section. Thank you, Constantine, for sharing, the overview of the platform along with the, the areas of application with some, examples of use cases. Now in this section, we will the, you know, dig deeper into the event driven, integrations, yeah, with some, real life use cases that we have implemented for our customers. But before we go to, go into the use cases, I think it's important, to understand a bit of the, event driven integration as well and what advantages and benefit an event driven integration pattern brings. Yeah? But before we go directly into the event driven integration, let's look at a landscape without an, event driven integration architecture implemented. So here in this picture, you see, an integration landscape, where for most of the companies where who do not have event, driven integration pattern implemented, this is how it looks like. Now in this landscape, it's a mix of technology and application from, different eras. There are, let's say, there could be modern day application ready to address the challenges, of, the companies that face today in, for handling increasing volumes of integration and data passing through different applications through the integration domain. But at the same time, there are legacy applications, that do not have the capability to support modern day integration need. They either need to be upgraded or need to be enabled, yeah, to support modern day integration approach. Yeah. Now if you look at this picture, there are different components. You know, on the left side, you have different applications, which are part of the integration chain, either sending data or receiving data, you know, through, different components in the, integration layer. Now, here, if we see, the applications are, connecting to each other, one on one. Yeah. So let's, talk about some of the challenges that such an integration landscape brings here. So there is a tie a very tight coupling between the system, which means every producer must know where exactly the data is being sent. Yeah. What it means is a system a on the left hand side, when sending the data through the integration layer, needs to know where the data has to land on the receiving side. So as a sender, I'm knowing I I should I should know where my data is going. Yeah. Now any changes because I'm producing my data for a specific consumer, any changes on the consumer side requires, as a producer, to update themselves. Yeah? What it means, there's a very tight coupling between the systems. Yeah. With this tight coupling, there are other challenges as well. Scalability is, not so good. Yeah. There's a lack of, flexibility, lack of decoupling. Yeah. Errors on one, application gets propagated, throughout the chain, yeah, and the systems get impacted. What it means is if a consumer goes down, since, you know, there's a direct connection to the consumer from the producer, yeah, the producer might also experience the impact of a consumer not being available. Yeah? Now, it also limits in reusability of data. What it means is yeah. As a producer, I'm sending the data to my, you know, consumer a. That data might not be directly used by a third consumer, which is consumer, c. Yeah. So which means that, you know, the reusability of that event or data becomes a bit of a challenge in in such an integration landscape. Yeah. So what it means is without a broker so this picture lacks a lacks a broker in between. So without a broker, integration becomes more rigid, harder to scale, and this becomes a major bottleneck in a fast growing data driven organization. Now these challenges, which we spoke about, can be addressed effectively by using an adopting to an integration, event driven architecture. Now here, let's look at, a modern integration landscape. So in this architecture, event broker is placed acts as a backbone of the communication enabling the decoupling between your producers and consumers. Yeah. Now when I say and and on top of it, SnapLogic is placed, in between, which plays a key role, when it comes to transformation, enriching, routing the data in transit. Yeah. On top of all this, there's a layer of governance, yeah, which is really a key to your event driven integration architecture to ensure visibility, control, and governance over your or, you know, compliance maintaining the compliance across your integration landscape. Yeah. Now on the left hand side, if you see in this picture, the challenges that we spoke about in the previous, slide about decoupling. The decoupling is achieved by the integration layer and the event broker in between so that the producers are not directly linked to the consumers. The producers can continue to produce the data even if my consumers are available to consume the data. Or if they are even down, the producers do not get impacted because of the availability of the consumers. So, as in when the consumers get become available, they start, consuming the data that has been produced. So that's basically what we say decoupling, is achieved in an event driven integration, pattern. Yeah? Now, the role of, SnapLogic in this picture yeah. If you see here, SnapLogic is plays a very, strategic role, in this, integration landscape. You can have your legacy application, which are not, let's say, capable of handling events or not capable of connecting, directly to your event driven, let's say, solution. SnapLogic can help you, connect to those applications. Yeah. Now we spoke about there are certain, you know, set of, around thousand, snaps which are available that helps establishing the connectivity to your applications using SnapLogic. Now your, data which is being produced, in one format might not be acceptable to your consumers in in that format. So that might require a transformation as well. So SnapLogic in this, case could be used to transform the data, yeah, from format a in a format which is understandable by your consumers. Yeah. Now the third, use case where, SnapLogic can play a key role is your enrichment, yeah, or orchestration, I would say. Yeah. What it means is, you have a producer a and a consumer b. But when a producer a produces the data before it is consumed by consumer b, it has to be enriched, with the data from application c. That means there has to be an integration in between with the application c to enrich the data, which is which could be, let's say, meaningful to a consumer. In that case, SnapLogic helps in, achieving those orchestrations and routing that are needed in the in the in the chain when the data is being processed. Yeah. Now if I have to, give a real life example, for example, let's say, when a new order is placed on an ecommerce, platform, the event is published to a broker. Yeah. SnapLogic, for example, picks up picks it up and reaches it with a customer data from the CRM system and routes it to ERP, yeah, for full and fulfillment system. So all automatically, it can be achieved using SnapLogic, you know, playing this role of an orchestrator in between. Yeah. Now focusing a bit more, going a bit deeper on the governance part, governance in this whole, event driven architecture plays a very crucial role. When I say governance, it it is about, establishing frameworks, processes, yeah, to manage, control, and guide implementation yeah, or operations as well of the event, platform. Yeah. The the key aspects around governance is, defining your policies, standards, naming convention, structuring of your, event, the modeling of your event, your best practices, design pattern, security and compliance. Yeah. How do you manage your data access, your data protection, monitoring and observability? Yep. How how would you achieve your distributed tracing? So these are normally your first step into your into the journey towards event driven, architecture where you would want to establish a very solid governance around your, you know, integration layer, how to use your, iPaaS, in combination with a broker, what are the different patterns, you know, what to use in, when building a different set of patterns. So all these you set up before you, you know, go into this journey of event driven integrations, architecture. Yeah. I hope with this, it gives a bit of clarity on what an event driven architecture looks like and what are the different components, what benefit it brings, what an event driven integration, what combination of platform could, let's say, comprise your event driven integration. Yeah. With this, we would go into, a use case, yeah, which is a customer use case where we will focus on master data synchronization, yeah, where, let's say, event driven integration platform was let's say, approach was implemented. But before we go there, let me just, give you a brief about the use case itself. Yeah. So, as most of you are aware, master data plays a very crucial role in businesses and processes that, many enterprise, of many enterprises and synchronization of this master data with different application plays a very vital role for the completeness and correct execution of your various business transactions and processes. Yeah. Therefore, organization must have a master data synchronizations approach and strategy that ensures up to date master data across your application. Yeah. Now why event driven architecture? Yeah. To enable the synchronization, event driven integration architecture can, is one of the way or or, you know, a very good approach to achieve it. Yeah. Now let us imagine that you have that's normally the case, yeah, when it is about master data. You have multiple applications who are interested in master data maintained in your SAP. Yeah. Now having a one to one connection with all your application creates a very a mesh like scenario and a very tight coupling between your source and target. Yeah. Now as a good integration design and a flexible model, it becomes crucial that your producers, in this case, your, application, which has a master data, is decoupled from your consumer. And here, your event broker will play a role in achieving this decoupled architecture. Yeah. Now in this, session, we'll share an experience based on customer scenario that uses SAP as the as a system of record for their material master data. And there are, SAP application in different country countries who are interested in receiving this master data, and their processes are actually dependent on the updates that, are, you know, published by the SAP, system, which acts as a, system of record. Now, what were the key challenges? Now, I I gave a background on the, use case. The key challenges that, we had was, this volume of product or the master data that are being pushed to this regional SAP system were very high. We are talking about millions. Yeah. So what it means if we have to, push all these millions, updates, yeah, to different, regional SAP system who are interested in in in in this data. So the central system was continuously at a very high load and, continuously processing the data for these, you know, interested applications. What it means with this high load, the processing time was, more, and it leads to an obsolete data. By the time the data reaches to the target system, there is the data is already obsolete. Yeah. And that causes challenges in the local processes. And what it means is, there are manual intervention needed in the local processes. Yeah. A lot of clarifications are are required then because the data is not up to date. The business users really, you know, lose the trust on the data. So which is very important in in in in today's world to have that trust in that data that, that is being pushed to the chain. Yeah. So these were the challenges that were, there. Now to solve these challenges, we implemented an event driven integration pattern. Now here, on the left hand side, we have the SAP, master data application, which holds all the, material master information. In the on the right hand side, we have these regional, ERP systems, which are interested in receiving these updates from the central system. Here in this picture, we have shown only, two, but there are, you know, close to, 50, 50 plus, actually, of them. But there are other applications as well who are interested in this, data. The middle integration portion comprises of, SnapLogic as an iPaaS solution, and, there's a event broker in the sorry. There's an event broker, in between. In this case, we are using Kafka as an event broker, and the data is distributed across different topics residing on this, Kafka, server. Yeah. Now what happens and on top of it, there's a there's a layer of observability to track all the transactions which are going through the integration platform. Now when a master data changes on the left, on the SAP system, events are triggered to which are received by SnapLogic here. The transformation, first of all, yeah, that helps in establishing connectivity. SnapLogic helps in establishing connectivity to the SAP system. SnapLogic receives the data. SnapLogic does the routing to the respective, topic. SnapLogic does, you know, whatever transformation is needed, to be done in the first leg of the process and pushes the data to the topic, respective topic. Now, these regional, ERP systems are interested in receiving the data in a very specific format, which is understandable by them. So in general, let's say, from this topic, the data is received by the second leg of the process, which actually picks from all these, different topics, does the required, transformation routing and, pushes to the regional ERP system in the format that they need. Yeah. Now if I talk about the benefits, the data as it is coming is being stored in this Kafka topic, what it means, not only these regional ERP systems, but any other application which is interested in receiving this data from, SAP, master data application can actually hook into these topics and start receiving this data. Yeah? So I from the producer point of view, they do not have to publish the data again. The data is already published in the topic. Now if the consumers get added, they just hook on to this, topic or the buckets that are created with, with data, and they start receiving, the in you know, data that they are interested in. So that's why we say it's a decoupled architecture. Producer can still continue to produce the data. The consumers, just in any case, if they are not available to produce, they can still, receive the data when they are available. If more consumers get added, they can directly if they have the capability to connect directly to the topic, they can directly connect to the topic. SnapLogic can be used as well to facilitate that connectivity. So there are lot of things that you can actually achieve by having a event driven approach and, decoupled, architecture. So it brings out a lot of benefits. Yeah. Now, talking, going moving forward, if we look at the benefits, that we achieved by this, event driven, integration architecture, Number one is reduced latency. Now the the applications the consumer applications receive data much faster. They are, you know, the period for within which the the data receive is received is much less. That reduces the entire latency of the process. Now the data is more up to date. The quality is, is better of the data because, the the data that they have in their consumer application, that is the most up to date data that they can have. Now when the data is most up to date and the quality has improved, it in let's say, it has a direct result or impact on the efficiency of the entire process. So there are less manual intervention that are needed. There's more trust on the data because the users know that this is the most updated data that can be, received and, which brings in the the trust in the data that is, being pushed through the chain and received on the consumer applications. Yeah. Now, just going a bit on the observability in the architecture, we showed that, there's a layer of observability on top of, the entire integration chain. So in this use case, we are monitoring all the different applications, all the transactions that are flowing through the chain. We have in this case, we are in, using Splunk. So we have different dashboards to track it where we are tracking how many transactions are being pushed through the layer, how many of it was successfully, how many of them were delivered to the target successfully, how many failed. And there are other statistics that we, let's say, derive out of the data that is going through the integration layer. Because, you can imagine the data that is, flowing through the integration layer, that's like a gold mine. You can derive a lot of statistics from the data that is that is flowing through the layer. Now we are also using, the observability layer to track, some trends, which helps us, let's say, do some predictions as well, you know, when the system is at a a higher load, when there are more, processing happening so that it helps us plan better, yeah, and also to take any corrective actions that are needed to be taken beforehand. Yeah. So all these things are being tracked through the chain, and, yeah, we use this data to, you know, build our analysis and take the necessary action that are required to be taken. So with this, actually, the first use case we come to the the end of the first use case. What I just wanted to show you briefly is, how you can, in a simple way, build an event driven integration in SnapLogic using, you know, the the tools that are available on the platforms. Yeah. We spoke about the snaps that are there. So let me just show you briefly, what you can actually how you can build. So here, this is the, landing zone of SnapLogic. Those who are not yet familiar or those who have seen it, they would know. But for those who haven't, let's say, are not very familiar, SnapLogic has three main sections. Designer is where you actually build your, integrations. Yeah. Manager, where you actually, manage your, things like user groups, roles, yeah, settings. Everything is in the manager, and monitor is where you actually monitor your integrations. Now to build a simple, related to the use case that I showed, it it includes, two different components. Yeah. SAP on one side, then you have, Kafka in between, as an event broker. So if if we have to just build a simple flow, here in the list of snaps, you can see there are a lot of snaps that are available. Now if I go and search for SAP with SAP, you can have, you see there are different, SnapLogic SnapLogic snap packs that are there. Within a SnapLogic snap pack, you have different, SnapLogic snap. Let me just drag one of them. This is the iDoc listener SnapLogic snap. Now if you have s four HANA, you can also use the s four HANA, SnapLogic SnapLogic snap packs, yeah, to, connect to your s four HANA systems. Now it's very straightforward. The moment you have your SnapLogic snap available on your screen, There are certain settings of related to your SAP systems that you need to do, and you can have your account, you know, configured here. Yeah. So once this is done then, basically, with with these settings, you should be able to connect to your, SAP system. Now in the middle, if you have any orchestration, if you have to do any mapping, there are different snaps available. I'll use a a a mapper SnapLogic snap. Let me just do this. Let me just you can do you can have multiple of of these mappers depending on your use case. Yeah. You can simply use it the way you want to do your, let's say, mapping, transformation, orchestration, or whatever you want to do. Now finally, when you are done, again, if I go here, and search Kafka. So with Kafka, you see there are there's a Kafka consumer, which actually reads the data from a Kafka topic and is a Kafka producer. In this case, let's say we have to write data to a Kafka topic. We use the Kafka producer. I'll just select one of them. Yeah. And here you can, put your settings, which topic you want to write the data to, partition how you form want to form your message key, yeah, and message value, yeah, and, the format in which your key should be. Yeah. Either string, JSON, and, similarly, you can have your value, as well. Yeah. Whether you are writing string, Avro, JSON, or whatever, you know, format you want to write depending on your use case. So in a very simple way, you can actually, drag and drop different, let's say, snaps from the pallet. You can configure them, and you, you would be ready to go. Now you can even, if you're talking about the best practices, you can even modularize your integration. Let's say you have certain set of, common pipelines, that you want to use. You can actually use them. Now if I with this pipeline, there's a pipeline execute snap, which is actually used to call a child pipeline. So you can use this pipeline execute snap to modularize your entire, flow into small, let's say, logical blocks and execute them using pipeline execute. In this snap, you have to just select which pipeline you want to execute. Yeah. I can select anyone. Does not matter. Yeah. So you can use this to modularize and, you know, follow the best practices for your development. So so that's what I I wanted to show. In very simple steps, you can actually build your integrations, yeah, with drag and drop and configurations. Yeah. The mapper could, would vary depending on your use case. But, yeah, this is, in essence, what it is. Yeah. Now going back to the slides. Yeah. The second use case, that, we wanted to touch is around data mesh, yeah, and how modern integration pattern can help, in the in this journey of, of data mesh. So as organizations scale and data is no longer centralized, but it it increasingly distributed across domain. Yeah. Now the traditional way where you have a data centralized, at a centralized place and, you know, you have, you know, the data management, becomes a challenge, yeah, because of this, centralized nature of data, storage. Yeah. Now there's with with this data mesh, there's a increased need of decentralize it and pass on the ownership of your, data to different, let's say, domains. For example, the data, for finance team can be owned by the finance domain. They become responsible for owning the data for, for their domains. Yeah? That's where the concept of data product come ownership comes for this, data mesh concept. Yeah? And to enable this data mesh concept, event driven integration architecture can play a very vital role because then, we are not we are talking about, an approach where the data gets distributed and the ownership also gets distributed as data products. Yeah. So event driven architecture can play a very crucial role in having, fueling your, data mesh, journey. Yeah. Now a simple integration, event driven integration pattern that can be used to, support your event mesh journey is, if you see here in this picture, in this architecture on left hand side, you can have different application, Salesforce, SAP, any database. Yeah. In the, on the right hand side, you have your, let's say, analytics platform, your, data warehouse, Snowflake. You can have your AI related products, which require data from all these applications, so that, you know, you can build your analytics use case. You can build your AI related, products on top of it. Yeah. You can train your, LLM models. All this can be achieved. Now in between, in the middle there, it's, can SnapLogic along with an event driven, let's say, event broker that collectively forms your event driven integration, pattern. Yeah. Event driven integration architecture. Yeah. In a way. Now on top of it, you can have your observability layer, whatever observability layer you have to track all your transactions flowing through different, platforms. Yeah. And once all this data is, moved to your consumer application, either Snowflake or any other, platform or AI related products, analytics related use cases can be built, you know, your AI related use cases can be built on top of it. So this is how, let's say, I just wanted to show you briefly how you can use different platforms in your integration layer with an event driven concept to fuel your, journey of event mesh. Yeah. With this, we conclude the use cases. Now, just quickly, if you want to get a free expert session, feel free to write us, on this, email address. We'll be more than happy to jump in and, you know, discuss, with you and enable you for your event driven integration, strategy journey, yeah, or assessment if needed. Yeah. With this, I would pass it back to, Sinem. Over to you. A bit of promo from our side as well. We have some upcoming events. You can see them here, and I will also drop the links in the chat later on. We have our virtual stop in Frankfurt that is coming up on on September 17 where we will focus on smart data product products, generative AI, and practical use cases. We have our Gen AI hands on workshop, which will be virtual on September 23. It's a two hour focused workshop introducing our agent creator. And then on September 24, we have a you've have an event with Hoho together in Zurich focusing on data streaming, data mesh, and event driven architecture. So if you're interested, feel free to check out, the links, and I will also post them in chat. And with that, I think we can move on to the q and a. So I already saw a couple of questions come in, and I think this one is for you, Konstantin. Which LLM providers can be connected with SnapLogic? Okay. Yeah. Thank you for the question. So, we have prebuilt Snap Packs for all the major ones, for example, from Azure, OpenAI, from AWS Bedrock, but also from GCP, Vertex AI, and so on. And, also, you're able to, use our generic connectors to connect to any kind of LLM you want to use because they all offer, API endpoints you can you can call and use. So for example, you could also leverage an on premise LLM for your, integration needs or AI needs. Thank you, Konstantin. Also for for the audience or everyone who's still here, feel free to drop your questions in the q and a if you have any more. There is another one, quite relevant today. How can we ensure that people using AI agents can only access the data they are authorized to? Mhmm. Here, our API management can help. We can, make sure that people need to authenticate through their, authentication provider for businesses. It's usually like something like SAML two dot o. So Azure, enter AD, for example, or something similar for AWS. And and then this, this token which will get generated will be used for the, retrieval of data or calling functions with OAI agents to make sure we keep the user context and that, people are only allowed to see what they should see and not more. We have some other questions coming in. One of the questions is what types of companies or industries benefit most from adopting, EDA, event driven architecture? I I think, Harrison, I can take this one. Yeah. So, when we talk about this is very generic, actually. Yeah. When we talk about industries, there are, different industries who are actually either in in their journey of implementing event driven integration or they've already, you know, way ahead in the game. Yeah. Now we know from the financial sectors, banks are heavily using, this pattern for, let's say, fraud detection cases. Yeah. Now, in terms of, ecommerce, and retail, The companies are are using it for their, order management, processes. So I think it's very difficult to pin down into a specific industry that gets benefited out of it. All the industry it's it's like a concept. Like, whoever uses the event driven integration, pattern gets the benefit of this EDA approach here. And all the sectors from what we have seen, all the different sectors are are are using or moving towards event driven integration architecture, yeah, to take the benefits, of this, pattern. Yeah. Thank you, Shashank. There's another question. How big of a learning curve is there for teams new to EDA? Okay. When we talk about, learning curve, I think when it depends on the maturity level, yeah, where you are in your event driven integration journey. Yeah. Now the main challenge is the adoption of it. Yeah. Now what we have experienced from our different customer base, especially, explaining this or, you know, making the business adopt this new way of working. That's where because for business, it's basically they are receiving the data, whether it comes via a a point to point integration pattern or an event driven integration pattern. So they, at the end, from business point of view, they see the data arriving. Yeah. But the real benefit is it still needs to be explained to them. And, let's say, they they buy that's where we see the challenge coming in to get in the buying of the business here in this, event driven integration approach. So that's basically the first challenge. But in terms of the technical part of it, it's not very complicated. Yeah. It's about getting used to it. Yeah. And adopting it, where you need to actually analyze where you are at this moment and what is your short term or medium term goal when it comes to event driven integration approach. Yeah. Based on that, the journey can be defined. And, what I have seen work works out well is, taking a a simple use case, one of the use case which we think that could add real value, implement event driven integration in that use case, get the benefits out of that implementation to explain to others that, you know, implementing going the event driven approach has, certain benefits that it brings. And then, you know, from there, you'd, in in include your other, let's say, use cases. Yeah. Now something that I would like to add here is I spoke about governance. Yeah. In this event driven integration journey, as I said, governance will play a very crucial role. How you set up your, approach, how you define your patterns, which platforms, to use, in in your event driven integration approach. So all these, initial setup, are crucial, and I think that would also be a defining point in your in the the entire, event driven architecture journey. Yeah. So I think, it's a it's a very broad question in a way, but, we can narrow it down. If anyone has any specific questions, we can still connect and, you know, discuss that. But that's what it would look like when it comes to your learning and how you can go about with your event driven integration implementation journey. Yeah. There is one question. Another question. The transfer of data is using the blockchain. Question mark, can we use SnapLogic to clean data automatically for the use of AI? Constantine would there are several yeah. Let me take the question. So, there are several, snaps which can help with, data quality or reduction of data, which can can be helped. So you can, for example, define a pattern. You can use a kind of search to find specific sequences and so on. So there are different options. Of course, this is a little bit dependent of of your use case. In terms of blockchain, and I'm not sure about how this is exactly meant, but, happy to go into more detail if you if you have some more in-depth question on that topic. Right? So Okay. With that, I would say we can close the session. Thank you everyone for joining. If you still have questions coming up, I will make sure to include Shashank's and Constantine's contact information in the follow-up email so you can reach out for questions as well. Thank you for joining, and, I wish you a good and productive rest of the day. Bye. Thank you. Bye. Thank you. Bye. Bye.