You can create a service connector by defining properties and specifying functions and variables. You can also define the actions associated with a service connector.
To create a service connector, perform the following steps:
1In Application Integration, click New > Service Connectors.
2In the New Asset dialog box, click Service Connector using Form, and then click Create.
Defining Properties
To create a service connector and define the properties, perform the following steps:
1In Application Integration, click New > Service Connectors.
2In the New Asset dialog box, click Service Connector using Form, and then click Create.
3Define the following basic properties for the service connector on the Definition tab:
- Name: The name by which the service connector is made available for processes. The name must start with a letter or number, and can contain only alphanumeric characters, multibyte characters, spaces, underscores (_), and hyphens (-). The name must not exceed 128 characters. This is a required field.
- Location: Specify the project or folder to save the service connector.
- Description: Enter a description for the service connector.
- Agent Only: Check if this service connector should only be available to run on the Secure Agent.
4Click + to add the connection properties to connect to this service. Specify the following details for each connection property in the Connection Properties section:
- Name: The connection property name. The name must start with a letter or number, and can contain only alphanumeric characters, spaces, underscores (_), and hyphens (-). This is a required field.
- Description: Enter a description for the connection property.
- Test With: Enter a value that Process Designer will use to test the connection.
- Type: Select an appropriate data type for the connection property.
- Required: Select this check box to set the connection property as a required property.
- Encrypt: Select this check box to encrypt the connection properties. In the Developer Console, the values entered in the fields are visible when you save the connector. The value appears encrypted after you save, close, and reopen the connector.
The following image shows a sample service connector:
5To edit the connection properties, click anywhere on the row that contains the connection property.
Returns a response header value. If the header parameter is not defined, this function returns the optional default value.
getResponseHeaderNames
svc:getResponseHeaderNames( $ResponseHeaders ) : list of strings
Returns a list that contains the names of all the parameters within a response header.
Defining Actions
On the Actions tab, you can create and describe one or more actions associated with a service connector.
The following image shows the Actions tab:
Choose the row you want to edit and then enter the following information in the Action details tab:
Click + to add a new row.
•Action Name: Enter the name that appears in lists when referencing this action in service connectors and connections. The name must start with a letter or number, and can contain only alphanumeric characters, spaces, and underscores (_). This is a required field.
•Category: If you have many service connectors, each with multiple actions, you can create categories to help users navigate within processes.
•Fail on HTTP error: Check this option if you want Process Designer to acknowledge that an error occurred when you send a request to a server using this action. For more information see Checking for HTTP Errors.
•Max Redirects: Specifies the maximum number of redirects that an action can make. When an action accesses an endpoint, the endpoint might redirect the action to another endpoint. Enter a value to control the number of redirects.
The default Max Redirects value is 100.
Enter 0 to disable redirects.
For example, if you enter 3, the service connector action makes a maximum of three redirects and receives three redirect responses from the endpoint. If the endpoint requests a fourth redirect response, you see an error message.
•Preemptive Auth: Sends authentication details, that is, user credentials, along with a request to an endpoint. Select Preemptive Auth when you know that an endpoint requires authentication. If you do not select Preemptive Auth and the endpoint requires authentication, the following events occur:
1The service connector sends a request to the endpoint.
2The endpoint requests authentication.
3The service connector sends user credentials to the endpoint.
If you select Preemptive Auth and the endpoint requires authentication, you avoid an extra request.
•Action Type: You can select one of the following action types for each action. Refer to Shared Service Actions for more information.
- General actions are published for use only with a particular service connector.
- Abstract actions are not published but can be shared with other actions, that is, made available for reuse as a template for other actions.
- Inherited actions inherit properties from an Abstract action.
•Description: Enter a description or notes about this action.
For each action, specify additional details on the Input, Binding, Output, and Test Results tabs.
Shared Service Actions
Using shared service actions, you can define common inputs, bindings, and outputs, then reuse these definitions in other actions that "inherit" from the parent "abstract" action.
For example, you might have multiple actions which all share the same:
•Input parameter session-id
•HTTP Header such as content-type
•Binding method (GET/POST) and URL
•Authentication Credentials
•Output fields
In that case, you can:
1Define an Abstract type action that contains all of the common definitions:
2Create multiple Inherit type actions that use those common definitions and extend or add to certain parameters.
3For example, an Inherit action can:
- Define a new input parameter (for example, $messageId).
- Extend the binding URL and append the new parameter to the base with "/{$messageId}".
For example:
Notes on Usage
Shared service actions:
•Are not available at design time within IPDs and Guides.
•Inherit inputs, bindings, and outputs from a single parent (Abstract) action.
•Do not allow abstract actions to inherit from other abstract actions.
•Allow each Service Connector to have multiple abstract actions.
After you specify the Inherit Action Type, many fields are disabled.
However, for specific Binding and other options, you can choose to:
• Inherit: Use all input parameters from the Abstract action, as is. This is the default.
• Exclude: Exclude the parameter so it is not available to the action at design time or runtime.
• Overwrite: Specify parameters to overwrite what was inherited.
Input Tab
Use the Input tab to define input data items that are unique to the service to which you are sending data.
For example:
Depending on the service, you might have no data items or many.
For each item, enter the following properties:
•Name: The name of the input data item. The name must start with and can contain letters, numbers, or the special characters .@$^_. The name can also contain spaces. This is a required field.
•Label: The name of the item to display within a process. If not specified, the Name is displayed.
•Type: Select the data type of the item from the list. If you select the Reference or Object List type, you can select a Process Object.
You can also set a list of simple type such as text, integer, number, check box, date, date time, or time for an input field. For the initial values, use a sequence of values based on the list of simple type as shown in the following examples:
- List of text: ("Bob","John","Valery")
- List of integer: (1,2,3)
- List of number: (22.5, -23.654, -45.876500)
- List of check box: (true, false, true)
- List of date: ("2022-01-03", "2021-12-11", "2020-03-04")
- List of date time: ("2022-01-03T11:23:01Z", "2021-12-11T23:11:55", "2020-03-04T22:10:45")
- List of time : ("12:30:00", "22:45:23", "05:01:02")
To set the type as a list of simple type, select the Text, Integer, Number, Checkbox, Date, Date Time, or Time type as required, and then select the This is a list check box.
•Required: Select if a value must be set for this parameter.
•Description: Enter a description of the parameter.
•Parameter: When selected, the service connector passes this parameter to the service. If the parameter is only used when constructing another parameter and does not need to be passed to the service, clear this field. For example, the service might expect a date to be in the RFC 1123 format but you want the process that calls it to pass an XSD date in the Process Designer's normal format. This option is enabled for all data types except XML.
•Test with: Enter a value that Process Designer will use to test the action. If the input is an attachment, you can also upload a sample attachment file.
You can also test the input fields in the JSON format with the values set to a list of simple type as shown in the following example:
After you enter a value in the input field, you must click anywhere outside the row to save the value.
Use the + icon to add a new item. Click X to delete the current row.
Service Connector Bindings
For each action in a service connector, the Binding options enable you to specify the interface and parameters required to communicate with a service.
Binding Properties
Specify values for these options:
•URL: Enter the URL of the REST Service.
•Verb: Choose how to send data to the service:
- GET, HEAD, OPTIONS, and TRACE: Process Designer automatically generates the query parameters.
- POST, PUT, PATCH, and DELETE: Process Designer adds a Binding Type field from which you can then select the value as JSON, JSON Unwrapped, Form, URL, or Custom. If you select Custom, a Body field appears where you can type the request that is sent to the service. By default, JSON is selected for the POST, PUT, and PATCH verbs, and None is selected for the DELETE verb. Consult the API documentation to determine what you should enter.
•Multi Using: This option determines how query string parameters are generated when you need to specify multiple values for a parameter. Choose one of the following:
- Semicolon separated: for a semicolon-separated multi-select list, Process Designer adds input parameter values as a single string. (For example, ?param=a;b;c). This is the default.
- Comma separated: for a comma-separated multi-select list, Process Designer adds input parameter values as a single string. For example, ?param=a,b,c.
- Append brackets: for a semicolon-separated multi-select list, Process Designer maps semicolon-separated values to multiple query parameters of the same name, and appends [] to the parameter name. For example, colors[]=red&colors[]=blue&name=JW.
- Append numbers: for a semi-colon separated multi-select list, Process Designer maps semicolon-separated values to multiple query parameters of the same name and adds a number to the end of the field name, that is, 1..N. For example, colors1=red&colors2=blue&name=JW.
•Authentication Type: You have two options to define the authentication information that the service requires: Basic or Custom. If you choose:
- Basic, enter the user name and password, if required.
Enter text or an XQuery expression in the user name and password fields. If you enter an XQuery expression, you can pass the password value through a connection instead of hard coding it in the service connector. Click the glass icon to view the password.
Select the Expression in Password check box to retain the password that you enter and also export the password when you export the service connector.
Note: If the password contains an ampersand (&) character, when you test the service connector, the action fails. Additionally, if you use the same service connector in an app connection and process, the process invocation also fails.
- Custom, add the security parameters based on the service requirements. For example, you might need to send signed data using an HTTP header.
•HTTPS/Mutual Authentication: Select this check box if the action must use a custom client certificate for mutual authentication. You can configure one custom client certificate for each action. If selected, the Keystore File Path and Keystore Password fields appear. You must place the keystore file on the Secure Agent machine.
Note: You can configure custom client certificates for service connectors that run on Secure Agents. When you configure a custom keystore file for a service connector and also specify a client certificate using the javax.net.ssl.keyStore property in the Process Server properties, the custom keystore file configured in the service connector takes precedence. If the service connector authentication fails, the client certificate configured in the javax.net.ssl.keyStore property is ignored and the request fails.
•Keystore File Path: Enter the path and file name of the Java KeyStore (JKS) file on the Secure Agent machine.
•Keystore Password: Enter the password to open the keystore file.
Other Parameters
Use this section to add input parameters required by the service. The value may be specified as a literal or expression. Refer to documentation from the service you are using.
To add a row and enter multiple parameters, click the + sign. To remove a row, click the X.
For each row, enter:
•Name: the name of the parameter as specified within the service being called.
•Content: the value to specify for the parameter, if any.
Click Show Advanced to select these optional parameters for the Binding:
•Sign With: The value that is computed will first be signed using SHA1, and the result of the signature will be this value.
•Sign Using: Choose to sign the field using SHA1 or SHA256.
•Encode Using: Choose to encode the field as Base64 and Hex64Upper.
•Temp: If checked, Process Designer will not generate a parameter when using GET or POST. For more information, see the Parameters described here: Input Tab.
•Attachment Base64: The base64 encoding of the attachment associated with the <inputName>.
•Attachment Name From: The file name of the attachment associated with the <inputName>.
Click Hide Advanced to hide the fields.
HTTP Headers
If the service requires one or more HTTP headers, enter the Name and Content (value of the parameter) for each header in this section.
To define a SOAP-based service connection, you must add both the "SOAPAction" and "Content-Type" headers. The value of SOAPAction can be empty, dynamically set using GET, or defined in the WSDL.
If the service does not set the content-type in the response header, the service connector attempts to infer the content type from the payload. For example, if the response starts and ends with either "{...}" or "[...]", the response is parsed as JSON. If the response payload starts with an angle bracket ("<"), it is treated as XML. If the response payload cannot be parsed due to malformed JSON or XML, it is processed as a regular string.
If the response Content-Type header contains the term application in the first part and the term json in a subsequent part, Application Integration infers the response payload type as JSON. Similarly, if the response Content-Type header has the term text in the first part and the term xml in a subsequent part, Application Integration infers the payload type as XML.
Some services request an MD5 signature. You can generate an MD5 signature in the HTTP Headers section of service connector actions.
To generate an MD5 signature, perform the following steps:
•Enter a name for the HTTP header. For example, enter Signature.
•Go to source > Expression Editor.
•Under type, select XQuery.
•Under Insert Field, select PAYLOAD_DIGEST_MD5.
When you test or run the service connector, the used variable contains an MD5 checksum for the generated request payload.
Content Type and Character Sets
You can determine the charset used for a request payload as noted here:
•Specify a charset value in the Content-Type header. In this case, the header determines the charset of the request payload. In this case, the charset is based on the value specified in the header unless the request format is an attachment type, in which case each part of a multipart/form-data request will be treated separately. If you set the Content-Type and want the service connector to append the default charset automatically, add a semi-colon after the specified Content-Type, as shown here:
Content-Type=application/json;
•Do not specify a charset value in the Content-Type header so this value can be set automatically based on the request format. To ensure that the content can be decoded correctly, the service connector appends the default charset (UTF-8) to the Content-Type. For example, the value might be set as follows:
Content-Type=application/json;charset=UTF-8
Expression Editor for Service Connector Properties
To define the binding parameters, you can use the Expression Editor accessible for the URL, Other Parameters, and HTTP Headers fields.
To open the Expression Editor, click f(x) next to the field you want to edit. When it opens, the Expression Editor gives you access to a list of available functions and the fields defined for the service connector, as shown in this image:
Based on the type selected for the expression, the Expression Editor applies syntax validation. In this case, the post_url field is validated as an XQuery variable.
Use the Output tab to define how the service connector must parse data returned from a service and place it in variables. Typically, a service returns data in the XML format. If the service returns data in the JSON format, the service connector converts it to the XML format. You can map the XML to output fields in two ways:
1Directly map the data to a property based on XML tag names or JSON properties.
2Use Expression to extract elements.
Note: Informatica recommends parsing the XML response by using XML parsing tools such as JDOM and Woodstox, and then extracting values rather than performing a plain string search to match namespaces and tags. If you match plain strings, you might encounter an error because the namespace prefixes are not constant.
The following image shows the Output tab:
For each output data item, specify:
•Name: The name of a variable into which a returned value is placed. The name must start with a letter or number, and can contain only alphanumeric characters, spaces, and underscores (_). This is a required field.
•Type: The data type of the value being written to the variable. If the type is Object List or Reference, Process Designer displays a list of Process Objects so you can choose one of the objects defined within the Process Objects tab.
You can also set a list of simple type such as text, integer, number, check box, date, date time, or time for an output field. To set the type as a list of simple type, select the Text, Integer, Number, Checkbox, Date, Date Time, or Time type as required, and then select the This is a list check box.
•Description: Text describing the variable
•Get From: Select one of the following options:
- Property: To enter a named value (which is the name used within the XML returned by the service) to be placed within the variable. Do not set the Property option to Reference because the Property option can retrieve only a single property in the XML response.
Note: You must select Property only for unique fields. If you have duplicate fields, select Expression and specify an XQuery expression. For more information, see Rules and guidelines for using list of simple types.
- Expression: To write an expression to parse the XML returned by the service. In the above image, we use the $RESTResponse output field to return one value for the AllModelsCount variable. The expression used for the CarMakesList returns a list. Click f(x) to open the Expression Editor where you can type the expression.
- HTTP Response Status Code: To check the HTTP response status code.
- HTTP Response Header: To enter the part of the response header to assign to the field. See the details below.
- Entire Response: To assign the complete contents of the response payload to the field.
- Simplified XML: To rearrange data so it can be used by process objects. For more information, see Simplified XML.
- Entire Response As Attachment: To handle the entire response as an attachment.
Note: The Entire Response As Attachment option preserves backward compatibility. If you had created a service connector with a single attachment earlier, it will continue to work as is, and no manual changes are needed. However, Informatica recommends that you redesign your service connector to handle multipart responses as multiple attachments so that you do not have to manually split attachments. You can also use the processing logic for attachments within the service connector itself instead of doing it within a process. Therefore, you can use a service connector within multiple processes without having to design the processing logic in multiple processes. You can also use the functions available to work with output attachments.
- Attachments: To work with multiple attachments and pass the entire list of attachments to the selected variable except the part used as the payload.
After you enter a value in the output field, you must click anywhere outside the row to save the value.
Rules and guidelines for using list of simple types
Consider the following rules and guidelines when you use a list of simple types in a service connector:
•You must use the Property option for an output field only if the payload response contains unique fields. If you have duplicate fields or a field with a list of simple type, there might be instances of one or more values with the same field name in the XML document. In that case, you must select Expression and use XQuery to get the correct field.
For example, assume that you select the Property option for the payload response as shown in the following sample:
When you use a field with a simple type and set the output as ID. Application Integration identifies an instance of the ID and returns a single output value such as the ID with the value as 4. However, if you use a field with a list of simple type, Application Integration finds the output instance. Then, Application Integration returns all the instances from the same level within the element. In this example, if the ID with value 1 in user 1 is identified, Application Integration also returns the IDs 2 and 3 within user 1.
To avoid this issue, when you have duplicate fields such as ID and you want to use the second ID from user 2, use XQuery to return the correct field as shown in the following sample:
.//user2/ID[2]/text()
Consider the following scenarios to use the sequence of values for the list of simple type variables:
If you have text output variables that contain a list of strings, to build a comma-separated string, use XQuery as shown in the following sample:
{string-join($TextsOut , ",")}
If you have a list of date-time values, and you want to access the second value from a list of dates, use XQuery as shown in the following sample:
{$DateTimesOut[2]}
If you want to iterate all the integers from the list of integer values, use XQuery as shown in the following sample:
{for $j in $Integers return $j}
•When you generate a JSON payload with an input field that contains a list of simple types, the output is in the form of a JSON array. When you parse the JSON response, the fields are also converted into a list of simple types.
For example, the generated JSON payload appears as shown in the following sample:
{ "userNames": ["Bob","John","Valery"] }
When you generate an XML payload, the request appears as shown in the following sample:
Much of the complexity in standard XML, with a mixture of namespace, attributes, siblings, and children, is not needed within Process Designer in order to present data to people designing processes. While you sometimes need to use the XQuery option for Get From, this is not necessary for many applications.
Simplified XML rearranges data within XML so that it can be used by process objects. This rearrangement treats attributes as children, removes namespaces, makes siblings with the same name consecutive, and places text into CDATA sections.
If you select Simplified XML for the Get From option, Process Designer displays a text field. If you do not enter anything in the field, Process Designer processes all of the received XML. If you enter the name of an element, Process Designer begins simplifying at this element, only processing this element and elements nested within it.
If you type a period ("."), this is treated as an empty field. (This is the default.)
Checking for HTTP Errors
When you send a request to a server and it cannot complete the request, it returns an error status code. There are two ways in which a service connector can handle HTTP errors (4xx and 5xx status code in the HTTP response).
1For each Action defined on the Actions tab, you can select Fail on HTTP error, as shown in the illustration below. By default, this option is enabled. If the HTTP request returns an HTTP error, the service connector fails.
2Specify how to handle the HTTP errors for each Action on the Output tab. To implement this option, disable Fail on HTTP error.
Fail on HTTP Error
If you enable Fail on HTTP error and an HTTP error is returned:
•A process faults and you can view the process details in the Application Integration Console.
•A process displays a dialog to the end user with message text showing the HTTP error received.
•The service connector throws faults in the same format a process throws faults:
HTTP error codes follow the format HTTP_NNN, for example, HTTP_404. The reason string contains the HTTP status message.
Note: Any internal or system errors return SERVICE_CONNECTOR_ERROR and one of the following reason strings:
•CATALOG_ERROR
•OTHER_PARAMETERS_ERROR
•AUTHENTICATION_ERROR
•CUSTOM_HEADERS_ERROR
•BINDING_URL_ERROR
•ALTER_REQUEST_AUTHENTICATION_ERROR
•PROCESS_RESPONSE_AUTHENTICATION_ERROR
•OUTPUT_PARAMETERS_ERROR
If you disable Fail on HTTP Error and an HTTP error is returned:
•A process does not fault and the service connector passes the 4xx or 5xx status codes to the process so that you can handle the error in the process.
•A or process faults and displays a failure message.
If the target service uses error codes that users might encounter as a matter of course, enable this option to provide process users with meaningful information.
The following image shows the Fail on HTTP error option enabled:
Handle HTTP Errors
To handle HTTP errors for a process, first be sure that you have disabled Fail on HTTP error.
You then need to check the HTTP response status code within the process.
To do this, define an "HTTP Response Status Code" as a variable in the Output tab. You can also specify a variable using $ResponseStatusCode in Expression fields (see the available functions below). In this way, you can pass the status code as part of the service connector's output and handle the response in the process.
These variables, like all variables you create in the Output tab, display when you click Test.
If you check Fail on HTTP error and an HTTP error status code is returned, the output contains a message.
HTTP Response Header Information Using Expression
You can use one of the following to get details from the response headers:
Returns a Boolean value that indicates if a header parameter exists within the response.
fn:getResponseHeaderNames( $ResponseHeaders );
Returns a list that contains the names of all the parameters within a response header.
Creating Service Connector Process Objects
On the Process Objects tab, you can define one or more process objects for a service connector to group data and create a structured object. When defined in the service connector, the process objects are available to processes that use the service connector. If, for example, a service returns demographic information such as name, address, and phone number, you might create a single Demographic process object that contains this information.
You can associate each process object with one or more of the data elements returned by the service using the Actions/Output tab.
To create service connector process objects:
1Create or open an existing service connector.
2Click the Process Objects tab.
3Click the + sign to add a new process object or select an existing process object from the list. Each process object appears as a line item on the tab.
4On the Properties tab, specify the following details for each process object:
- Name. Enter a process object name that identifies the process object. This name appears in the lists where the process object is available for selection. The name must start with a letter, and can contain only alphanumeric characters, underscores (_), and hyphens (-). This is a required field.
- Description. Enter an optional description.
5On the Fields tab, specify the following details for each process object:
- Name. Enter a name for each field in the process object.
- Type. Select the data type of the value being written to the variable using one of the built-in data types. If you select the Reference or Object List type, you can select a process object.
You can also set a list of simple type such as check box, date, date time, integer, number, text, or time for a process object field.
To set the type as a list of simple type, select the Checkbox, Date, Date Time, Integer, Number, Text, or Time type as required, and then select the This is a list check box. For more information about using a list of simple type, see Creating a field with a list of simple type.
- Optionally, expand the row after you select a data type such as text, date, date time, time, number, or integer. You can enter the following values for each of the data types:
▪ character length and text format for the text data type
▪ date range for the date data type
▪ date time range for the date time data type
▪ time range for the time data type
▪ minimum and maximum values for the number data type
▪ minimum and maximum values for the integer data type
- Required. Select this check box to set the field as a required field.
A required field must be included in the request payload. It can contain a value, be empty, or be null.
- Nullable. Clear this check box if the field must not accept null values. By default, the Nullable check box is selected.
When you use the service connector editor, click Test to send a request to the service and display the response data on the Test tab:
•Generate Process Objects: Click to see the process objects that you have defined for the service connector.
•Result: Displays the status of the test.
•HTTP Status: Displays the HTTP status code.
•URL: Displays the URL where test data was sent. Any query parameters are added to the URL shown here.
•Output and Value: Shows the data returned from the service that is assigned to the variables defined on the Output tab. If you are using XSLT, it is used to extract the data from the payload.
•Response Payload: Shows the payload sent to Process Designer from the service (not the full response sent by the service).
•REST Request: Shows the data sent to the service from Process Designer.
•REST Response: Shows all of the data sent back to the Process Designer from the service (whereas the response payload is only a portion of the returned data).
Here, you can see the differences between the payload, request, and response data (for illustration purposes only; the actual test results display only request or response data):
If the response includes one or more attachments, you can also download the attachments. The following image shows a multipart response with options to download all the attachments:
Generate Process Objects
A process object is usually tied to a specific set of elements. You may sometimes have a large number of identical objects, each of which applies to one set of elements. For example, when you define the data being returned, you create a process object whose sole purpose is to define a subset of returned data. These objects are non-reusable and can only be used by a single process object field. The object names are also the name of a field.
You can also create objects that are reusable. For example, the refType element in NetSuite has two fields: a name and an internalID. Instead of creating many objects, each of which contains these two fields, you can create a single, reusable process object.
1Click Generate Process Objects to show the process objects that you have defined for the service connector.
2Select the process objects that you want to make reusable and then click Next.
Process Designer displays a list of generated process objects.
3Click Finish.
Service Connector Timings
You can see the HTTP Response Parsing time, the HTTP Execution Time, and the Redirection Count in the tab of a service connector.
You can see the following HTTP headers in the Rest Response section of the tab:
HTTP Response Parsing Time
The time that a service connector takes, in milliseconds, to parse a response from the URL you entered in the Binding tab. The HTTP Response Parsing time is usually zero for small requests. For large requests, especially with requests with attachments, the HTTP Response Parsing time increases.
See the HTTP header X-AE-HTTP-RESPONSE-PARSING-TIME-IN-MILLIS for the HTTP Response Parsing Time.
Redirection Count
The number of redirects, if any, made by the URL that you entered in the Binding tab.
For example, if a service request redirects to a service that in turn redirects to another service, the Redirection Count is two. If a service request goes through with no redirects, the Redirection Count is zero.
See the HTTP header X-AE-REDIRECTION-COUNT for the Redirection Count.
Note: If a GET HTTP request redirects to another GET HTTP request, the Redirection Count remains zero. This is a limitation.
HTTP Execution Time
The response time, in milliseconds, of the URL that you entered in the Binding tab. The HTTP Execution Time does not include the response parsing time, or the time taken to by the service connector to perform other tasks.
See the HTTP header X-AE-HTTP-EXECUTION-TIME-IN-MILLIS for the HTTP Execution Time.
The following image shows the X-AE-HTTP-RESPONSE-PARSING-TIME-IN-MILLIS, X-AE-REDIRECTION-COUNT, and X-AE-HTTP-EXECUTION-TIME-IN-MILLIS HTTP headers:
