Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
| 2500_config_apps:0500_add_edit_objects:0600_intelligent_bo [2026/08/13 03:35] – localdev | 2500_config_apps:0500_add_edit_objects:0600_intelligent_bo [2026/08/13 07:20] (current) – external edit 127.0.0.1 | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | {{tag> | + | {{tag> |
| [< | [< | ||
| ====== Defining Intelligent Business Objects ====== | ====== Defining Intelligent Business Objects ====== | ||
| Line 33: | Line 33: | ||
| To discover services press the Discover button next to the Services table. Discovered services (if any) will be displayed in the Services table. You can now define a process that would call the discovered services using the REQUEST SERVICE action of the // | To discover services press the Discover button next to the Services table. Discovered services (if any) will be displayed in the Services table. You can now define a process that would call the discovered services using the REQUEST SERVICE action of the // | ||
| - | <callout | + | <alert type=" |
| + | **note** | ||
| - | <callout type=" | + | |
| - | ==== Setting Properties of the URL Channel ===== | + | <alert type=" |
| + | **note** | ||
| + | |||
| + | If the service provider changes definitions of services the services may be re-discovered in the same way as described above. The Configuration Tool will automatically replace all services and business objects declared as service input and replies with the new definitions.</ | ||
| + | |||
| + | ===== Setting Properties of the URL Channel ===== | ||
| Communication with an intelligent business object via the URL channel assumes that // | Communication with an intelligent business object via the URL channel assumes that // | ||
| Line 66: | Line 72: | ||
| This is the same as the previous parameter except that the return URL indicates failure rather than success. If this parameter is not specified // | This is the same as the previous parameter except that the return URL indicates failure rather than success. If this parameter is not specified // | ||
| - | ===== Setting Properties of the REST Channel ====== | + | ===== Setting Properties of the REST Channel ===== |
| Communication through the REST channel involves sending an HTTP call to a particular URL. Unlike the URL channel no user interface is involved in the call – the service returns straight away and the execution of the rules continues. Services exposed by an intelligent object through the REST channel can be discovered if the provider supplies a file in an Open API format describing exposed services. They can also be added manually as described below. | Communication through the REST channel involves sending an HTTP call to a particular URL. Unlike the URL channel no user interface is involved in the call – the service returns straight away and the execution of the rules continues. Services exposed by an intelligent object through the REST channel can be discovered if the provider supplies a file in an Open API format describing exposed services. They can also be added manually as described below. | ||
| Line 77: | Line 82: | ||
| The following properties can be specified when adding/ | The following properties can be specified when adding/ | ||
| - | ===== Name ===== | + | ==== Name ==== |
| Specify the name of the service. The name must be unique among other services of the business object. The name must start with a character or underscore symbol and contain characters, digits or underscore symbols. Spaces are not allowed in the name. | Specify the name of the service. The name must be unique among other services of the business object. The name must start with a character or underscore symbol and contain characters, digits or underscore symbols. Spaces are not allowed in the name. | ||
| - | ===== Description | + | ==== Description ==== |
| The optional description of the service: what it does, how it is used etc. | The optional description of the service: what it does, how it is used etc. | ||
| - | ===== Base URL ===== | + | ==== Base URL ==== |
| The URL to call when the service is requested. This URL should not include any URL parameters. You can use tag expressions to refer to attributes of the objects in Context here. | The URL to call when the service is requested. This URL should not include any URL parameters. You can use tag expressions to refer to attributes of the objects in Context here. | ||
| - | ===== HTTP Verb ===== | + | ==== HTTP Verb ==== |
| HTTP verb to use when the service is called – usually '' | HTTP verb to use when the service is called – usually '' | ||
| - | ===== Parameters | + | ==== Parameters ==== |
| Parameters of the service can be specified in different ways depending on what the provider requires. | Parameters of the service can be specified in different ways depending on what the provider requires. | ||
| Line 120: | Line 125: | ||
| If your service provider requires that you provide binary content as a parameter along with some primitive values (for example, text or number) you should specify each parameter in its own part. For example, if you need to provide a binary value and a number, you should define two parts – the first part (binary) should have “application/ | If your service provider requires that you provide binary content as a parameter along with some primitive values (for example, text or number) you should specify each parameter in its own part. For example, if you need to provide a binary value and a number, you should define two parts – the first part (binary) should have “application/ | ||
| - | <callout | + | <alert type=" |
| + | **note** | ||
| + | |||
| + | If you are referring to the entire object in Context and this object has an attribute of the Picture or Document type, the picture or document will be automatically encoded without you having to define an additional part.</alert> | ||
| + | |||
| + | <alert type=" | ||
| + | **note** | ||
| + | |||
| + | If a provider requires that the value of some attribute is an array of primitive values and you are referring to the entire object in Context, make sure that the value of the “array” attribute is a string that concatenates all array members delimited by the “#” symbol, for example <code aim> | ||
| - | <callout | + | <alert type=" |
| + | **note** | ||
| - | <callout type=" | + | If a provider requires that the value of some attribute is a dictionary and you are referring to the entire object in Context, make sure that the value of the “dictionary” attribute is a string containing pairs of key/values separated by the " |
| To add a part, click on the “Add” button above the list of the defined parts. | To add a part, click on the “Add” button above the list of the defined parts. | ||
| - | ===== HTTP Headers | + | ==== HTTP Headers ==== |
| Click on the “HTTP Headers” link to define one or more optional HTTP headers that will be added to the HTTP request if the provider requires them. For each header provide its name and value. Note that the value may refer to the current Context of the process when the service is called. To do this, enclose the value in “tags” (double angular brackets), for example: <code aim><< | Click on the “HTTP Headers” link to define one or more optional HTTP headers that will be added to the HTTP request if the provider requires them. For each header provide its name and value. Note that the value may refer to the current Context of the process when the service is called. To do this, enclose the value in “tags” (double angular brackets), for example: <code aim><< | ||
| - | ===== Reply ===== | + | ==== Reply ==== |
| If the REST call returns a reply that you need to handle in your application, | If the REST call returns a reply that you need to handle in your application, | ||
| Line 140: | Line 154: | ||
| - For JSON and XML replies you can get // | - For JSON and XML replies you can get // | ||
| - | ===== OAuth Support | + | ==== OAuth Support ==== |
| Many vendors providing REST services support OAuth protocol that mandates that the caller of the service authenticates himself using a special protocol before a call to the service is made. If this is the case you need to tick the “OAuth Supported” checkbox underneath the services table and then click on the “Details” button to provide further details: | Many vendors providing REST services support OAuth protocol that mandates that the caller of the service authenticates himself using a special protocol before a call to the service is made. If this is the case you need to tick the “OAuth Supported” checkbox underneath the services table and then click on the “Details” button to provide further details: | ||
| Line 171: | Line 185: | ||
| This value is only for OAuth 1.0. Refer to the documentation of the vendor as to which signature type you need to provide | This value is only for OAuth 1.0. Refer to the documentation of the vendor as to which signature type you need to provide | ||
| - | === Request for request token === | + | ==== Request for request token ==== |
| The values in this section are only for OAuth 1.0 that requires that the system first sends a request for a " | The values in this section are only for OAuth 1.0 that requires that the system first sends a request for a " | ||
| - | === Request for access token === | + | ==== Request for access token ==== |
| A call to the service using OAuth can only be done if the vendor issues an " | A call to the service using OAuth can only be done if the vendor issues an " | ||
| - | === Token expiry === | + | ==== Token expiry |
| Access tokens may expire. If a call to the service is made with an expired token an error message will be returned. The error message is specific to the vendor. If you help // | Access tokens may expire. If a call to the service is made with an expired token an error message will be returned. The error message is specific to the vendor. If you help // | ||