Integrated platform protocol endpoint parsing framework

Through the collaborative work of entry components and endpoint selectors, dynamically parsing and connecting appropriate endpoints solves the challenge of parsing custom endpoints across components in an integrated environment, enabling efficient, flexible, secure and accurate endpoint resolution.

CN119629260APending Publication Date: 2025-03-14SAP SE
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202411276563.3
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Priority Date
2023-09-14
Filing Date
2024-09-12
Publication Date
2025-03-14

AI Technical Summary

Technical Problem

In an integrated environment, an efficient, flexible, secure and accurate way to resolve customized endpoints across components to handle inbound network requests and communications between multiple components is needed.

Method used

The ingress component receives HTTP URL and HTTP header information, and the endpoint selector dynamically parses the appropriately deployed endpoints and outputs a parsing instruction. The runtime components of the integration platform are connected to the appropriately deployed endpoint interface to execute incoming protocol messages.

Benefits of technology

Efficient, flexible, secure and accurate custom endpoint parsing across components ensures the accuracy and efficiency of the integrated platform when handling inbound network requests.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119629260A_ABST
    Figure CN119629260A_ABST
Patent Text Reader

Abstract

The ingress component may receive HTTP URL and HTTP header information for incoming protocol messages (e.g., AS2 messages) from a client. An endpoint selector may determine HTTP header information and an endpoint address associated with an incoming protocol message. Based on the incoming HTTP header information and the endpoint address of the incoming protocol message, the endpoint selector may dynamically parse the appropriately deployed endpoint and output an indication of the dynamically parsed appropriately deployed endpoint. The runtime component of the integration platform may then execute incoming protocol messages and interface connections with the appropriately deployed endpoints.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present disclosure relates to an integrated platform protocol endpoint resolution framework. Background Art

[0002] An enterprise may use an integration platform to communicate with other parties. An integration platform may represent a collection of integrated software products that allow users to develop, secure, and manage integration flows that connect various applications, systems, services, and data stores. An integration platform may also enable rapid application programming interface (“API”) creation and lifecycle management. In some cases, electronic data interchange (“EDI”) information may be exchanged by sending business documents (e.g., purchase orders or invoices) between companies in a standard format.

[0003] Information can be exchanged according to various data transmission specifications or protocols. By way of example only, Applicability Statement 2 ("AS2") defines a way to securely and reliably transmit structured business-to-business data over the Internet using digital certificates and encryption. AS2 is specified in Request for Comments ("RFC") 4130 from the Internet Engineering Task Force ("IETF") and is based on Hypertext Transfer Protocol ("HTTP") Uniform Resource Locators ("URLs") and Secure / Multipurpose Internet Mail Extensions ("S / MIME") encryption. Files can be encoded as "attachments" in standardized S / MIME messages (AS2 messages), and the file content is in a standardized format, such as Extensible Markup Language ("XML"). Typically, AS2 can be used so that documents can be encrypted / decrypted, compressed / decompressed, signed / verified, etc.

[0004] In an integration environment, components such as HTTP, Simple Object Access Protocol ("SOAP"), Representational State Transfer ("REST"), etc. can provide partners with the ability to connect to fixed endpoints. In addition, protocols such as AS2 not only utilize fixed endpoints, but also use dynamic headers. Integration developers can model multiple scenarios, and partners can call the desired endpoint by calling the same fixed endpoint or using the same endpoint and dynamically setting additional headers in the request. However, during the integration runtime, the correct integration scenario needs to be identified to handle the inbound network request. In addition, in some systems, there will be multiple components (with separate responsibilities). Therefore, it is expected that the system provides a common framework to resolve custom endpoints across components in an efficient, flexible, secure and accurate manner. Summary of the invention

[0005] According to some embodiments, methods and systems may include an entry component that receives an HTTP URL and HTTP header information for an incoming protocol message (e.g., an AS2 message) from a client. An endpoint selector may determine the HTTP header information and an endpoint address associated with the incoming protocol message. Based on the incoming HTTP header information and the endpoint address of the incoming protocol message, the endpoint selector may dynamically resolve an appropriately deployed endpoint and output an indication of the dynamically resolved appropriately deployed endpoint. A runtime component of the integration platform may then execute the incoming protocol message and interface with the appropriately deployed endpoint.

[0006] Some embodiments include: a component for receiving, by an entry component, an HTTP URL and HTTP header information for an incoming protocol message from a client; a component for determining, by a computer processor of an endpoint selector, the HTTP header information; a component for determining, by the computer processor, an endpoint address associated with the incoming protocol message; a component for dynamically resolving, by the computer processor, an appropriately deployed endpoint based on the incoming HTTP header information and the endpoint address of the incoming protocol message; a component for outputting, by the computer processor, an indication of the dynamically resolved appropriately deployed endpoint; and a component for executing the incoming protocol message by a runtime component of an integration platform coupled to the entry component through an interface connection with the appropriately deployed endpoint.

[0007] Some technical advantages of some embodiments disclosed herein are improved systems and methods for resolving custom endpoints across components in an efficient, flexible, secure, and accurate manner. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1 is a high-level block diagram of a custom endpoint resolution system according to some embodiments.

[0009] Figure 2 is a custom endpoint resolution method according to some embodiments.

[0010] Figure 3 is an example of an AS2 implementation of an endpoint resolution system according to some embodiments.

[0011] Figure 4 is an integrated platform information flow according to some embodiments.

[0012] Figure 5 is an apparatus according to some embodiments.

[0013] Figure 6 is part of the endpoint parsing data store according to some embodiments.

[0014] Figure 7 is an example of an operator or administrator display according to some embodiments.

[0015] Figure 8 is a tablet computer illustrating an integrated ambient display in accordance with some embodiments. DETAILED DESCRIPTION

[0016] In short, some embodiments help provide a framework for resolving custom endpoints across components associated with an integration platform in an efficient, flexible, secure, and accurate manner. In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the embodiments. However, one of ordinary skill in the art will appreciate that the embodiments may be practiced without these specific details. In other instances, well-known methods, processes, components, and circuits are not described in detail to avoid obscuring the embodiments.

[0017] One or more specific embodiments of the present invention will be described below. In order to provide a concise description of these embodiments, all features of the actual implementation may not be described in the specification. It should be understood that in the development of any such actual implementation, as in any engineering or design project, many implementation-specific decisions must be made to achieve the specific goals of the developer, such as meeting system-related and business-related constraints, which may vary from implementation to implementation. In addition, it should be understood that such development work may be complex and time-consuming, but it is still a routine task of design, manufacturing and manufacture for ordinary technicians who benefit from this disclosure.

[0018] Figure 1 1 is a high-level block diagram of a custom endpoint resolution system 100 according to some embodiments. The system 100 includes a client 110, which can access a runtime component 160 of an integration platform 150 via an entry component 120. In addition, an endpoint selector 122 can be located at the entry component 120. The endpoint selector 122 can be part of the entry component 120 or separate from the entry component 120. According to some embodiments, devices (including devices associated with the system 100 and any other devices described herein) can exchange data via any communication network, which can be a local area network ("LAN"), a metropolitan area network ("MAN"), a wide area network ("WAN"), a private network, a public switched telephone network ("PSTN"), a wireless application protocol ("WAP") network, a Bluetooth network, a wireless LAN network, and / or an Internet Protocol ("IP") network (such as the Internet, an intranet, or an extranet). Note that any device described herein can communicate via one or more such communication networks.

[0019] Elements of system 100 may store and / or retrieve data in various data stores, which may be stored locally or remotely from portal component 120 and / or integration platform 150. Figure 1A single endpoint selector 122 is shown in FIG. 1 , but any number of such devices may be included. Furthermore, the various devices described herein may be combined according to embodiments of the present invention. For example, in some embodiments, the endpoint selector 122 and the endpoint resolution data store ( Figure 1 100 may include a single component or device. Some or all of the system 100 functions may be performed by a constellation of networked devices, such as in a distributed processing or similar cloud-based architecture.

[0020] An operator (e.g., a system operator or administrator) may access the system 100 via a remote device (e.g., a personal computer (“PC”), tablet, or smart phone) to view data about operational data in accordance with any of the embodiments described herein and / or to manage operational data in accordance with any of the embodiments described herein. In some cases, an interactive graphical user interface display may allow the operator or administrator to define and / or adjust certain parameters (e.g., set or adjust various endpoint resolution parameters, generate status reports, etc.) and / or provide or receive automatically generated recommendations, results, and / or alerts from the system 100. As will now be described, the system 100 may provide a software framework to facilitate parsing of custom endpoints and headers to select desired deployment endpoints in the integration platform 150. In this manner, the framework may help ensure separation of concerns, wherein one component (e.g., endpoint selector 122) is responsible for dynamic parsing, while another component (runtime component 160) is responsible for core functionality.

[0021] Figure 2 is an endpoint resolution method according to some embodiments. The flowcharts described herein do not imply a fixed order of steps, and embodiments of the present invention may be practiced in any feasible order. Note that any method described herein may be performed by hardware, software, automated scripts of commands, or any combination of these methods. For example, a computer-readable storage medium may store instructions thereon that, when executed by a machine, result in performance according to any embodiment described herein.

[0022] At S210, the ingress component may receive the HTTP URL and HTTP header information of the incoming protocol message from the client. According to some embodiments, the ingress component is an API gateway processor. In addition, according to some embodiments, the ingress component may also set business rate limits, implement authentication policies, etc. According to some embodiments, the incoming protocol message is associated with the AS2 protocol. In this case, the HTTP header information may include an AS2 "from" address, an AS2 "to" address, a subject, an AS2 identifier, etc. In other embodiments, the incoming protocol message is alternatively associated with the Applicability Statement 4 ("AS4") protocol, (ii) the Open Data ("OData") protocol, or a similar transmission standard.

[0023] At S220, a computer processor of the endpoint selector may determine HTTP header information. Similarly, at S230, the endpoint selector may determine an endpoint address associated with the incoming protocol message. Based on the incoming HTTP header information and the endpoint address of the incoming protocol message, at S240, the endpoint selector may dynamically resolve an appropriately deployed endpoint. For example, the HTTP URL and the HTTP header information may define an endpoint proxy, and the appropriately deployed endpoint is associated with a sender channel.

[0024] At S250, the endpoint selector may output an indication of a dynamically resolved appropriately deployed endpoint. Thus, at S260, a runtime component of the integration platform (coupled to the ingress component) may execute the incoming protocol message by interfacing with the appropriately deployed endpoint.

[0025] Figure 3 is an example of an AS2 implementation of an endpoint resolution system 300 according to some embodiments. As previously described, the system 300 includes a client 310, which can access a runtime component 360 of an integration platform 350 via an entry component 320. In addition, an endpoint selector 322 can be located at the entry component 320. The endpoint selector 322 can be part of the entry component 320 or separate from the entry component 320. According to some embodiments, devices (including devices associated with the system 300 and any other devices described herein) can exchange data via any communication network, which can be one or more of a LAN, a MAN, a WAN, a private network, a PSTN, a WAP network, a Bluetooth network, a wireless LAN network, and / or an IP network (such as the Internet, an intranet, or an extranet). Note that any device described herein can communicate via one or more such communication networks.

[0026] Elements of system 300 may store and / or retrieve data in various data stores, which may be stored locally or remotely from portal component 320 and / or integration platform 350. Figure 3 A single endpoint selector 322 is shown in FIG. 3 , but any number of such devices may be included. Furthermore, the various devices described herein may be combined according to embodiments of the present invention.

[0027] In an integration environment, protocols such as AS2 can provide partners with the ability to connect not only via fixed endpoints but also via dynamic headers. Integration developers can model multiple scenarios, and partners can call the desired endpoint by dynamically setting the headers in the request. Introducing a new system with an on-premises runtime engine can help provide cross-cloud and public integration platforms (e.g., Edge Integration Cell) TM). In this case, there may be multiple components with separate responsibilities. Therefore, a common framework may be required to resolve custom endpoints across all components.

[0028] Some embodiments described herein may provide a software framework to facilitate parsing of custom endpoints and headers. In addition, endpoints that are desired to be deployed in the integration platform may be selected. In this way, the framework may help ensure separation of concerns, where one component is responsible for dynamic endpoint parsing (e.g., entry component 320 and endpoint selector 322), while another other component is responsible for core functionality (e.g., integration platform 350 and AS2 runtime component 360).

[0029] The inlet component 320 may have a collection of AS2 endpoint proxies 330 (e.g., AS2 endpoint proxy 1 to AS2 endpoint proxy N). According to some embodiments, the inlet component 320 may include an API gateway processor that allows a user to set rate limits, implement authentication policies associated with endpoints, etc. The endpoint selector 322 may identify the exact AS2 endpoint based on the HTTP URL and HTTP headers. In addition, based on the set headers, it may identify the exact AS2 sender channel.

[0030] According to some embodiments, the AS2 endpoint selector 322 may be responsible for selecting the appropriate endpoint for AS2 based on the incoming headers. For example, the following incoming headers may be considered for the selection:

[0031] AS2-from,

[0032] AS2-to,

[0033] Theme, and / or

[0034] AS2-ID.

[0035] Along with these four headers, the endpoint address may also play a role in the selection.

[0036] The AS2 runtime component 360 of the integration platform 350 may include a processor associated with a set of AS2 endpoints 370 (e.g., AS2 endpoint 1 to AS2 endpoint N). The AS2 runtime component 360 may, for example, execute the actual message based on the AS2 protocol. Basically, the responsibility for this selection is thus separated out as a reusable entity. The integration platform 350 does not need to worry about endpoint selection, but can focus on performing the actual runtime execution. Note that the framework is reusable for any other protocol (such as AS4, OData, etc.), and the system can simply plug in the corresponding components when appropriate.

[0037] Figure 44 is an integration platform information flow 400 according to some embodiments. The integration studio 410 communicates with the deployment controller 430 via the generation and construction 420. The deployment controller 430 in turn communicates with the policy engine 440 and the integration runtime 450. The integration studio 410 can be used, for example, to create iFlow objects that model the integration process developed by the customer. The iFlow model can then be transformed into a special data format by the generation and construction 420 framework. The format can include, for example, two parts. The policy engine 440 can understand the first part of the format to generate inbound endpoints and policies that can be implemented by the engine. The second part can contain instructions and processing logic executed by the runtime engine. The second part can, for example, process the integration content during runtime. The deployment controller 430 deploys these two parts of the format on two different components. Inbound network business from customers can enter the runtime through the policy engine 440, and the policy engine 440 applies API management specific features on the worker, such as business rate limiting.

[0038] Thus, embodiments may provide AS2 adapter specific enhancements where HTTP headers are specified in the generated framework and then parsed by the policy engine 440 framework to appropriately route and associate inbound messages to the worker runtime.

[0039] Note that the embodiments described herein may be implemented using any number of different hardware configurations. For example, Figure 5 can be, for example, respectively Figure 1 and Figure 3 300 (and / or any other system described herein). The platform 500 includes a processor 510 (such as one or more commercially available CPUs in the form of a single-chip microprocessor) coupled to a communication device 520. The communication device 520 is configured to communicate via a communication network 522. The communication device 520 can be used to communicate with one or more integrated platforms 524, for example, via the communication network 522. The platform 500 also includes an input device 540 (e.g., a computer mouse and / or keyboard for inputting data regarding endpoint resolution) and an output device 550 (e.g., a computer monitor for presenting displays, transmitting recommendations or alerts, and / or creating monitoring reports). According to some embodiments, a mobile device and / or PC can be used to exchange data with the platform 500.

[0040] The processor 510 also communicates with the storage device 530. The storage device 530 can be implemented as a single database, or different components of the storage device 530 can be distributed using multiple databases (i.e., different deployment data storage options are possible). The storage device 530 can include any appropriate data storage device, including a combination of a magnetic storage device (e.g., a hard drive), an optical storage device, a mobile phone, and / or a semiconductor memory device. The storage device 530 stores a program 512 and / or an endpoint resolution engine 514 for controlling the processor 510. The processor 510 executes the instructions of the programs 512 and 514, thereby operating according to any embodiment described herein. For example, the processor 510 can determine HTTP header information and an endpoint address associated with an incoming protocol message (e.g., an AS2 message). Based on the incoming HTTP header information and the endpoint address of the incoming protocol message, the processor 510 can dynamically resolve the endpoints of the appropriate deployment and output the indication of the endpoints of the appropriate deployment that are dynamically resolved. Then, the runtime component of the integration platform can execute the incoming protocol message and interface with the endpoints of the appropriate deployment.

[0041] Programs 512, 514 may be stored in compressed, uncompiled, and / or encrypted formats.Programs 512, 514 may also include other program elements, such as an operating system, a clipboard application, a database management system, and / or device drivers used by processor 510 to interface with peripheral devices.

[0042] As used herein, data may be “received” or “sent” to, for example: (i) platform 500 from another device; or (ii) a software application or module within platform 500 from another software application, module, or any other source.

[0043] In some embodiments (such as Figure 5 In the embodiment shown in FIG. 5 , the storage device 530 also stores policy and authentication 560 information and endpoint resolution data storage 600. Figure 6 An example of a database that can be used in conjunction with platform 500 is described in detail. Note that the database described herein is only one example, and additional and / or different data may be stored therein. Furthermore, the various databases or data repositories may be split or combined according to any of the embodiments described herein. For example, endpoint resolution data store 600 and endpoint resolution engine 514 may be combined into a single device.

[0044] refer to Figure 6, shows a table representing an endpoint resolution data store 600 that may be stored at the platform 500 in accordance with some embodiments. The endpoint resolution data store 600 may include, for example, entries that identify different incoming messages (e.g., AS2 messages). The endpoint resolution data store 600 may also define fields 602, 604, 606, 608 for each entry. In accordance with some embodiments, the fields 602, 604, 606, 608 may specify: an incoming message identifier 602, an HTTP URL and headers 604, from / to / subject / identifier 606 information, an endpoint proxy 608, and an AS2 endpoint 610. For example, the endpoint resolution data store 600 may be created and updated when a new incoming message is received, a custom endpoint is resolved, and the like.

[0045] Incoming message identifier 602 may include, for example, a unique alphanumeric label or link associated with a message received from a client (e.g., an AS2 message, an AS4 message, an OData message, etc.). HTTP URL and headers 604 may be obtained from the incoming message and used to determine from / to / subject / identifier 606 information. In this way, endpoint proxy 608 may be resolved to the appropriate AS2 endpoint 610 for use by runtime components of the integration platform.

[0046] Figure 7 is an example of an operator or administrator display according to some embodiments. Display 700 includes a graphical representation 710 or dashboard that can be used to manage or monitor custom endpoint resolution (e.g., associated with messages received from clients). In particular, selection of an element (e.g., via a touch screen or computer mouse pointer 720) may result in the display of a pop-up window containing configuration or mapping data. Display 700 may also include an "Edit System" icon 730 that is selectable by the user to request a system change (e.g., to investigate or improve endpoint resolution rules or logic, change data source mapping parameters, etc.).

[0047] Thus, embodiments may provide improved systems and methods for resolving custom endpoints across components in an efficient, flexible, secure, and accurate manner.

[0048] Various additional embodiments of the present invention are described below. These do not constitute a definition of all possible embodiments, and those skilled in the art will appreciate that the present invention is applicable to many other embodiments. In addition, although the following embodiments are briefly described for clarity, those skilled in the art will appreciate how to make any changes to the above-described apparatus and methods, if necessary, to adapt to these and other embodiments and applications, wherein modifications and variations are limited only by the spirit and scope of the appended claims.

[0049] Although specific hardware and data configurations have been described herein, note that any number of other configurations may be provided in accordance with some embodiments of the present invention (e.g., some data associated with the components described herein may be combined or stored in external systems). Furthermore, although some embodiments focus on specific types of protocols and messages, any of the embodiments described herein may be applied to other types of protocols and messages. Furthermore, the displays shown herein are provided only as examples, and any other type of user interface may be implemented. For example, Figure 8 A handheld tablet computer 800 is shown presenting an integrated platform display 810 that may be used to assist a user in establishing endpoint resolution parameters (eg, by entering and storing information via a “save” icon 820 ).

Claims

1. A system comprising: An entry component for receiving a Hypertext Transfer Protocol (HTTP) Uniform Resource Locator (URL) and HTTP header information for an incoming protocol message from a client; Endpoint selectors, including: Computer processors, and A computer memory coupled to the computer processor and storing instructions that, when executed by the computer processor, cause the endpoint selector to: Determine the HTTP header information, Determine the endpoint address associated with an incoming protocol message, Dynamically resolve the appropriately deployed endpoint based on incoming HTTP header information and the endpoint address of the incoming protocol message, and outputting dynamically resolved indications of appropriately deployed endpoints; as well as The runtime component of the integration platform, coupled to the ingress component, is used to execute incoming protocol messages and interface with appropriately deployed endpoints.

2. The system according to claim 1, wherein: The entry component is the application programming interface API gateway processor.

3. The system according to claim 2, wherein: The ingress component also sets business rate limits and implements authentication policies.

4. The system according to claim 1, wherein: The incoming protocol message is associated with the Applicability Statement 2AS2 protocol.

5. The system according to claim 4, wherein: The HTTP header information includes: (i) AS2 "from" address, (ii) AS2 "to" address, (iii) subject, and (iv) AS2 identifier.

6. The system according to claim 1, wherein: The incoming protocol message is associated with one of: (i) Applicability Statement 4AS4 protocol, and (ii) Open Data OData protocol.

7. The system according to claim 1, wherein: The HTTP URL and HTTP header information define the endpoint proxy, and the appropriately deployed endpoint is associated with the sender channel.

8. A method comprising: Receiving, by the entry component, a Hypertext Transfer Protocol (HTTP) Uniform Resource Locator (URL) and HTTP header information for an incoming protocol message from a client; determining, by a computer processor of the endpoint selector, the HTTP header information; determining, by a computer processor, an endpoint address associated with an incoming protocol message; dynamically resolving, by a computer processor, an appropriately deployed endpoint based on incoming HTTP header information and an endpoint address of an incoming protocol message; outputting, by a computer processor, an indication of a dynamically resolved appropriately deployed endpoint; as well as Incoming protocol messages are executed by a runtime component of the integration platform coupled to the ingress component by interfacing with appropriately deployed endpoints.

9. The method according to claim 8, wherein: The entry component is the application programming interface API gateway processor.

10. The method according to claim 9, wherein: The ingress component also sets business rate limits and implements authentication policies.

11. The method according to claim 8, wherein: The incoming protocol message is associated with the Applicability Statement 2AS2 protocol.

12. The method according to claim 11, wherein: The HTTP header information includes: (i) AS2 "from" address, (ii) AS2 "to" address, (iii) subject, and (iv) AS2 identifier.

13. The method according to claim 8, wherein: The incoming protocol message is associated with one of: (i) Applicability Statement 4AS4 protocol, and (ii) Open Data OData protocol.

14. The method according to claim 8, wherein: The HTTP URL and HTTP header information define the endpoint proxy, and the appropriately deployed endpoint is associated with the sender channel.

15. A non-transitory machine-readable medium comprising instructions thereon, which when executed by a processor, cause the processor to perform operations to perform a method, the method comprising: Receiving, by the entry component, a Hypertext Transfer Protocol (HTTP) Uniform Resource Locator (URL) and HTTP header information for an incoming protocol message from a client; determining, by a computer processor of the endpoint selector, the HTTP header information; determining, by a computer processor, an endpoint address associated with an incoming protocol message; dynamically resolving, by a computer processor, an appropriately deployed endpoint based on incoming HTTP header information and an endpoint address of an incoming protocol message; outputting, by a computer processor, an indication of a dynamically resolved appropriately deployed endpoint; as well as Incoming protocol messages are executed by a runtime component of the integration platform coupled to the ingress component by interfacing with appropriately deployed endpoints.

16. The medium according to claim 15, wherein The entry component is the application programming interface API gateway processor.

17. The medium according to claim 16, wherein The ingress component also sets business rate limits and implements authentication policies.

18. The medium according to claim 15, wherein The incoming protocol message is associated with the Applicability Statement 2AS2 protocol.

19. The medium according to claim 18, wherein The HTTP header information includes: (i) AS2 "from" address, (ii) AS2 "to" address, (iii) subject, and (iv) AS2 identifier.

20. The medium according to claim 15, wherein The incoming protocol message is associated with one of: (i) Applicability Statement 4AS4 protocol, and (ii) Open Data OData protocol.

21. The medium of claim 15, wherein: The HTTP URL and HTTP header information define the endpoint proxy, and the appropriately deployed endpoint is associated with the sender channel.