About Custom Endpoints

Endpoints designed in SBM Composer are "process app endpoints", which define a place in the design that a Web service is called. This contrasts with "environment endpoints", which represent the actual server locations and authentication information used for calling the service when the process app is used in an environment. Although process app endpoints do include server paths and authentication information, these values are only used as default values for environments where the corresponding environment endpoint does not exist. For more information about endpoints, refer to About Endpoints .

There are two types of process app endpoints, automatic and custom.

Custom endpoints can be used in the following ways:

  1. As an alternative way of configuring a REST Grid widget.
  2. As a source for mapping endpoint information that you want to provide to the inputs of a Web service like the RESTCaller service in orchestrations.

By using a custom endpoint to configure a REST Grid, you can control which endpoints are created and how they are reused between REST Grids on different forms and you can better name them to describe their purpose.

Each application and orchestration has its own Custom Endpoint Library in the Application Explorer. If you want to share a custom endpoint across applications and/or orchestrations, create them with the same name, default URL and authentication properties in each of the Custom Endpoint Libraries. If the name matches and other properties do not, a validation error will occur.

Some examples of how these custom endpoints can be used in SBM Composer are given in the following topics:

Custom Endpoints for REST Calls in Forms

After defining a custom endpoint, you can use it in the REST Grid widget configuration dialog by selecting it from the drop down list box. If you have already specified an URL for the REST Service, you can convert this into a Custom Endpoint by choosing the <Convert to Endpoint...> entry in the drop-down list box. If the URL matches an existing custom endpoint, you can select it from the drop-down list box and it will be converted to use it, preserving all trailing path and parameter information.

If you are calling a REST service from an HTML/JavaScript widget using the JavaScript API RESTServiceWrapper object, you can use the string builder to reference the Endpoint ID, URL, Authentication Type, User Name or Password using the {#EndpointName.PropertyName} syntax. For example, you can type "{WeatherMap.URL}" to obtain the environment endpoint URL for the runtime environment. A SecureRESTServiceWrapper object is also available that takes an endpoint ID for specification of authentication information.

For an example of using custom endpoints in the string builder tool, refer to Using the String Builder Tool.

For information on using custom endpoints in REST Grid widgets, refer to Using the REST Grid Widget.

For information on RESTServiceWrapper and SecureRESTServiceWrapper, refer to Querying REST Service Results.

Custom Endpoints in Orchestrations

In orchestrations, custom endpoints are used for mapping to the inputs of SOAP-based service steps (not for the SOAP service itself). They are important when the SOAP service implementation calls another Web service that needs to use different endpoint information in different environments. RESTCaller is one such service that calls a REST service specified by its restUrl argument with authentication also specified in its inputs. You can create a custom endpoint for the called REST service in the Custom Endpoint Library for the orchestration, and then map its URL and authentication properties into the RESTCaller service inputs. At runtime, the endpoint values specified for the current environment will be passed to the RESTCaller service step.

For more information, see Calling RESTful Web Services from an Orchestration Workflow.

Related Topics

Using the REST Grid Widget

Calling RESTful Web Services from an Orchestration Workflow

Using the String Builder Tool

About Endpoints