Framework to resolve protocol endpoints in integration platform

1 . A system, comprising:

an ingress component to receive, from a client, a HyperText Transfer Protocol (“HTTP”) Uniform Resource Locator (“URL”) and HTTP header information for an incoming protocol message;

an endpoint selector, including:

a computer processor, 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 an endpoint address associated with the incoming protocol message, wherein the endpoint selector supports incoming protocol messages associated with multiple types of message protocols, including all of the Applicability Statement 2 (“AS2”) protocol, the Applicability Statement 4 (“AS4”) protocol, and the Open Data (“OData”) protocol,

based on the incoming HTTP header information and the endpoint address of the incoming protocol message, dynamically resolve an appropriate deployed endpoint, and

output an indication of the dynamically resolved appropriate deployed endpoint to an integration platform; and

a runtime component of the integration platform, coupled to the ingress component, to execute the incoming protocol message and interface with the appropriate deployed endpoint;

an integration studio that communicates with a deploy controller; wherein the deploy controller communicates with a policy engine and an integration runtime;

wherein integration studio creates an iFlow object that models integration processes;

wherein the iFlow object is transformed into a data format that includes both: (i) a first part understood by the policy engine to generate inbound endpoint addresses, and (ii) a second part that contains instructions and processing logic executed by the integration runtime.

2 . The system of claim 1 , wherein the ingress component is an Application Programming Interface (“API”) gateway processor.

3 . The system of claim 2 , wherein the ingress component is further to set a traffic rate limit and implement an authentication policy.

4 . The system of claim 1 , wherein the HTTP URL and HTTP header information define an endpoint proxy and the appropriate deployed endpoint is associated with a sender channel.

5 . A method, comprising:

receiving, by an ingress component, from a client, a HyperText Transfer Protocol (“HTTP”) Uniform Resource Locator (“URL”) and HTTP header information for an incoming protocol message;

determining, by a computer processor of an endpoint selector, the HTTP header information, wherein the endpoint selector supports incoming protocol messages associated with multiple types of message protocols, including all of the Applicability Statement 2 (“AS2”) protocol, the Applicability Statement 4 (“AS4”) protocol, and the Open Data (“OData”) protocol;

determining, by the computer processor, 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, dynamically resolving, by the computer processor, an appropriate deployed endpoint;

outputting, by the computer processor, an indication of the dynamically resolved appropriate deployed endpoint to an integration platform; and

executing, by a runtime component of the integration platform coupled to the ingress component, the incoming protocol message by interfacing with the appropriate deployed endpoint;

an integration studio that communicates with a deploy controller; wherein the deploy controller communicates with a policy engine and an integration runtime;

wherein integration studio creates an iFlow object that models integration processes;

wherein the iFlow object is transformed into a data format that includes both: (i) a first part understood by the policy engine to generate inbound endpoint addresses, and (ii) a second part that contains instructions and processing logic executed by the integration runtime.

6 . The method of claim 5 , wherein the ingress component is an Application Programming Interface (“API”) gateway processor.

7 . The method of claim 6 , wherein the ingress component is further to set a traffic rate limit and implement an authentication policy.

8 . The method of claim 5 , wherein the HTTP URL and HTTP header information define an endpoint proxy and the appropriate deployed endpoint is associated with a sender channel.

9 . A non-transitory, machine-readable medium comprising instructions thereon that, when executed by a processor, cause the processor to execute operations to perform a method, the method comprising:

receiving, by an ingress component, from a client, a HyperText Transfer Protocol (“HTTP”) Uniform Resource Locator (“URL”) and HTTP header information for an incoming protocol message;

determining, by a computer processor of an endpoint selector, the HTTP header information, wherein the endpoint selector supports incoming protocol messages associated with multiple types of message protocols, including all of the Applicability Statement 2 (“AS2”) protocol, the Applicability Statement 4 (“AS4”) protocol, and the Open Data (“OData”) protocol;

determining, by the computer processor, 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, dynamically resolving, by the computer processor, an appropriate deployed endpoint;

outputting, by the computer processor, an indication of the dynamically resolved appropriate deployed endpoint to an integration platform; and

executing, by a runtime component of the integration platform coupled to the ingress component, the incoming protocol message by interfacing with the appropriate deployed endpoint;

an integration studio that communicates with a deploy controller; wherein the deploy controller communicates with a policy engine and an integration runtime;

wherein integration studio creates an iFlow object that models integration processes;

wherein the iFlow object is transformed into a data format that includes both: (i) a first part understood by the policy engine to generate inbound endpoint addresses, and (ii) a second part that contains instructions and processing logic executed by the integration runtime.

10 . The medium of claim 9 , wherein the ingress component is an Application Programming Interface (“API”) gateway processor.

11 . The medium of claim 10 , wherein the ingress component is further to set a traffic rate limit and implement an authentication policy.

12 . The medium of claim 9 , wherein the HTTP URL and HTTP header information define an endpoint proxy and the appropriate deployed endpoint is associated with a sender channel.