Welcome Guest! Log in


This article describes the principal changes of HTTP REST Component.

If you need further information, please consult the full changelog.

Component download section can be found at this page.

Note:

Stambia DI is a flexible and agile solution. It can be quickly adapted to your needs.

If you have any question, any feature request or any issue, do not hesitate to contact us.

 

Component.HttpRest.2.3.0

XML wizard to reverse xml data

A new option to launch Xml schema wizard has been added on HTTP REST Metadata xml content node.

This option is available by right clicking on XML content node, in request body or in Responses:

http xml

Asking this option opens the xml wizard and allows to perform the reverse as we can do in the XML Metadata.

xml wizard

 

Component.HttpRest.2.2.0

 

Mapping whole response into one target field

A new extra field is available when using HTTP REST Metadata, under a response node, to be able to retrieve the whole content at once, instead of granular data.

This extra field is named "rawContent" and it can be used as source to retrieve all the response data at once.

You can add it dynamically in Mapping through extra fields as below:

rawcontent field

For instance, when mapping the rawContent node of the response to the target it retrieves all the content at once in the target field.

  

rawcontent

The previous mapping retrieves the whole response which is, in this case, JSON data like following which is loaded inside the target field:

{
    "response": {
        "data": {
            "customer": {
                "cus_id": "0",
                "tit_code": "M",
                "cus_first_name": "John",
                "cus_last_name": "Doe",
                "cus_company": "acme"
            }
        }
    }
}

Have a look at this article for further information about this feature.

 

Handling transparent stage in Integration RDBMS to HTTP rest

Transparent stage allows to define a staging area on a datastore, when the source does not support transformations.

Integration Rdbms to HTTP template has been updated to support using a transparent stage.

 transparent stage rdbms http

Complete changelog

The complete changelog with the list of improvements and fixed issues can be found at the following location.

 

Component.HttpRest.2.1.1

Minor improvements and fixed issues

This version also contains some other minor improvements and fixed issues, which can be found in the complete changelog.

 

Component.HttpRest.2.1.0

Proxy Metadata

Http REST metadata supports Proxy authentication.

This security information is set in a new dedicated metadata called "Proxy Security" in which you can set the information from the Proxy.

Then, in your HTTP REST metadata, you will need to define the security node to use for authentication.

This allows the various security information to be centralized into a single dedicated metadata.

Metadata looks like this:

proxy01

Currently, you can reference it only on HTTP Metadata. We are working on this topic. Soon you can reference it on other metadata.

 

Support Proxy Metadata

HTTP Rest Component now supports Proxy Security.

You must first define the proxy information in a dedicated Metadata. (Refer to this article for more information)

Then you reference it on the HTTP Metadata :

HTTP Proxy01 

NTLM Authentication

HTTP REST Metadata has been updated to support NTLM security.

http ntlm security

NTLM security is defined on a new HTTP security node:

NLTM node

Asking to create a new NTLM security node allows to define the Name, UserName, Password and Domain.

NTLM

Using substitution variables syntax inside the Reverse URL

HTTP REST wizard has been updated to support substitution variable syntax inside the http rest wizard on the Reverse URL such as %{env:variable_name}%

variable substitution file

 

HTTP REST Wizard - security Definition

When security metadata and proxy metadata are defined then the security and the proxy will be successively proposed in "HTTP Security" and in "HTTP Proxy" of the Security Definition wizard:

HTTP Secur

 

Support of EMF Compare

Several improvements have been made to support EMF Compare.

 

Minor improvements and fixed issues

This version also contains some other minor improvements and fixed issues, which can be found in the complete changelog.

 

Complete changelog

The complete changelog with the list of improvements and fixed issues can be found at the following location. 

 

Component.HttpRest.2.0.4

Templates Improvements

Write XML Key Values on INTEGRATION Rdbms to HTTP Template

Addition of the "Write XML Key Values" parameter on the INTEGRATION RDBMS to HTTP Template. If true, mapped XML element nodes that are used as a key will be written to the request even if they don't have a datatype.

  • when true and no datatype is set on the key node, the value is written.
  • when true and a datatype is set on the key node, the value is written.
  • when false and no datatype is set on the key node, the value is discarded.
  • when false and a datatype is set on the key node, the value is written.

 

KeyValue01

 

Example with the written value:

KeyValue02

 

Important note:

Setting this to false will prevent runtime from sending requests when only key nodes are mapped.

(for example if only the root element of the http datastore is mapped).

 

Nil Behaviour on INTEGRATION RDBMS to HTTP Template

Addition of the "Nil Behaviour" parameter on the INTEGRATION RDBMS to HTTP Template. This parameter defines what to do when a null value is loaded into a target xml element or JSON value.

The possible values are:

  • ForceToTrue: The element is created with the xsi:nil="true" attribute.
  • ForceToFalse: The element or JSON value is not created.
  • TrueIfNotDefined: When the 'isNullable' property is not defined in Metadata, the element is created with the xsi:nil="true" attribute.
  • FalseIfNotDefined: When the 'isNullable' property is not defined in Metadata, the element is not created.

 

Nill01

 Example with the attribut: 
Nill02

 

Note: 

All options are supported for XML elements only.

The property "nillable" does not currently exist on Json Values.

 

Certificates and hostname verifications

New attributes allowing to indicate that if certificates and hostname verifications should be performed. These attributes are available in HTTP REST and also in HTTP security OAuth2 Metadata.

On the HTTP REST Metadata, the parameter allows to define if the verification should be performed, for the certificates verifications of the operation itself

On HTTP REST Metadata, the parameter allows to define if the verification should be performed on the exchange performed to get OAuth2 token.

Default values of these parameters are "true" and when setting it to false the certificates and hostname verifications should not performed

 httprest hostname certificate verif

Complete changelog

The complete changelog with the list of improvements and fixed issues can be found on the full changelog.

 

 

 

Component.HttpRest.2.0.3

Support Multipart Request contents

HTTP REST Component now supports sending multi-part contents as input request.

You can define Multipart request in your Metadata through the new dedicated nodes.

Then, you can use them in Mapping as usual.

 

Definition in Metadata:

 

multipart metadata

 

Usage in Mapping:

 

multipart mapping 01

 

If you want to send multiple times the same part in a request, you can simply use the "part" node as repetition key.

A part will be created for each value of the repetition key.

 

multipart mapping 02 iteration

 

You can customize the Part Name and also the Part Filename dynamically through extra fields In Mapping

 

multipart mapping 03 part extra nodes

 

Response Cookies

HTTP REST Component now allows to design in Metadata the response cookies you want to retrieve.

A new cookie node can be created, with dedicated attributes allowing to identify the cookie to retrieve, such as the cookie name and a regexp.

This node can be created in responses, under the headers node.

 

Example:

http response cookies

 

Connection and Read Timeouts

Prerequisites:
  • Stambia DI Runtime S20.3.0 or higher

 

This new version allows to define Connection and Read Timeouts at different levels.

You can define them globally on the HTTP REST Metadata, or for each operation, and override them also in Mapping through new parameters on Templates.

This offers agility to define timeouts accordingly to your requirements.

 

Definition in Metadata

In Metadata, you will find those new attributes under the "Advanced" tab.

The timeouts can be specified globally on the root node, applying to all the operations defined in the Metadata:

 

http01

 

They can also be specified directly on an operation node, if you want to define different timeouts on the various operations.

Note that it overrides the default timeouts defined on the root node, if any.

 

http02

 

 

Definition in Template

You can also define the timeouts directly in Mapping, through the corresponding two Template parameters.

Timeouts defined in Templates take precedence over the timeouts defined in Metadata.

If no timeout is defined on the Template, it will use the value from Metadata.

 

Example:

HTTP03

 

 

OAuth2 improvements

New parameter to specify how credentiels are sent

 

Some OAuth2 authentication servers require that the credentials are sent alongside the token generation.

When this is the case, those credentials were legacily sent as parameters by Stambia

However, some servers require those credentials to be sent differently.

 

A new attribute named "Send Client Credentials" has therefore been added in Metadata to define how client id and client secret should be sent, with the support of a new mode to send them in Basic Auth header.

This attribute is available for the following "Flow Type", which may require it depending on the OAuth2 server implementation:

  • Resources Owner Password Credentials Grant
  • Client Credentials Grant

 

This new attribute proposes the list of the following values:

  • Send Client Id as parameter
  • Send Client Id and Client Secret as parameters
  • Send Client Id and Client Secret as Basic Auth header

 

Refer to the documentation of the attribute for further information about each value.

 

The attribute in OAuth2 Metadata node:

 

oauth2 clientcredentials metadata

 

The new attribute has also been added in the OAuth2 wizard:

 

oauth2 clientcredentials wizard

 

Backward compatibility

Legacy "Send Client Id" and "Send Client Secret" have been moved to a deprecated tab:

 

oauth2 clientcredentials legacy deprecated

 

When working with a Metadata using the legacy attributes, the default value for "Send Client Credentials" attribute is automatically adapted with the according value.

The following behavior applies:

Legacy attributes values
Default value generated for Send Client Credentials

Send Client Id = true and

Send Client Secret = true

Send Client Id and Client Secret as parameters

Send Client Id = true and

Send Client Secret = false

Send Client Id as parameter

Send Client Id = false

Send Client Secret = false

Empty

 

Minor improvements and fixed issues

This version also contains some other minor improvements and fixed issues, which can be found in the complete changelog.

 

Complete changelog

The complete changelog with the list of improvements and fixed issues can be found at the following location.

 

Component.HttpRest.2.0.2

Previous version was including too much dependencies libraries, which was leading to having a larger archive file for the HTTP REST Component and plugin contained inside.

This has been fixed, the HTTP REST Component size is now back to normal.

Note that except the larger file size, this had no other consequences.

 

Component.HttpRest.2.0.1

Prerequisites:
  • Stambia DI Designer S20.2.0 or higher

 

New wizard to define security

A new wizard has been added in HTTP REST Metadata to define the security node to be used.

When creating a new HTTP REST Metadata, a wizard will now open to guide the user to choose the security node to be used if any, and then to continue to the reverse step.

Note that the security page allows to choose an existing security node from all the HTTP Security Metadata of the workspace, which must therefore already exist.

 

New wizard to reverse an Open API 3 definition

The HTTP REST Metadata now also supports reversing an Open API 3 definition.

The wizard which opens at Metadata creation, and which can be reopened from the context menu on the root node, allows to reverse an Open API3 definition from an HTTP URL or from a local file.

After having defined the url, the wizard will reverse the definition and allows to choose the nodes to save.

 

Launching the HTTP REST API wizard

start wizard

 

Defining the Open API 3 definition through an HTTP URL or local file (after the security step)

define url

 

Finally, choosing the nodes to reverse

selective reverse

 

You have no rights to post comments

Articles

Suggest a new Article!