Default HTTP Transmitter

Introduction

The SC::JSON – Default HTTP Transmitter (also called “Dynamic HTTP transmitter”) allows you to send data to any endpoint. You can create the whole structure of the request dynamically. This transmitter is part of the Dynamic:JSON-Connector.
There is a similar transmitter in the Generic:JSON-Connector, but this article is for the Dynamic:JSON-Connector

For sending requests, you can use GET, POST, PUT, PATCH and DELETE.
It’s also possible to set custom headers for your requests. 

Version 1.21. and higher:
You can access Endpoints using OAuth-Authentication. This is explained in this article down below.
It is also possible to handle the response for each endpoint dynamically, you can find the documentation here:
https://sawsconnector.saws.de/knowledge-base/response-handler-field-plugin/ 

Configuration

The transmitter has multiple input fields which will be explained in detail down below.
The first step is selecting the “SC::JSON – Default HTTP transmitter” in the Step “Target System/Format” in a “Dynamic:JSON“-Station.

 

 

Configuration / Field	Explanation
Name	Custom name for the transmitter If multiple transmitters are stored / configured in one station, you can later select the transmitter in the job settings by this name
Timeout in seconds	HTTP Timeout in seconds
URL to the API interface of the application	The Base URL to the API where the requests should get sent to. Note that the final endpoint will be defined in the field “Endpoint table”.
Instead of direct authentication on the target system, load a token via this URL	If you want to use OAuth-Authentication insert the URL here. OAuth will only work if this field is not empty. You can also use a different URL than for the requests. How to use this field will be explained in detail later in this article
Username	The username for requests
Password	The password for requests
Additional headers	You add headers to your request. These headers can have different scopes to e.g. be only used for login, but not for data requests. A detailed explanation can be found later in this article
Endpoint table	Configuration of different endpoints where the requests as GET, PUT, POST, PATCH and DELETE can be sent to A detailed explanation can be found later in this article
Validation behavior	Selecting a JSON Validation from a JSON schema

 

OAuth Authentication

Instead of a basic authentication with username and password, the transmitter can request an access token which then will be used fo the other endpoints as authentication method.
There are two different ways how the token is requested:

Method	Condition	Explanation
POST	Token URL, Username and Password are configured	If the required fields are filled a POST request to the token url will be executed with the following body: {   “client_id”: “administration”,   “grant_type”: “password”,   “scopes”: “write”,   “username”: “your_username”,   “password”: “your_password” }
GET	Only token URL configured, username and password empty	If only the token url is filled a GET request will be executed. For authentication you need to create your own header with scope “Login”. You can also use placeholders in the headers to e.g. access passwords.

 

Additional Headers

Additional headers can be configured for the data only, for the login only or for both requests.
You can use placeholders in the headers which allows you to use passwords in the custom header (placeholder: {password:YOUR_PASSWORD_ID_HERE})

 

Endpoint table

In the endpoint table you can configure different enpoints that are used in the export. The endpoints are appended to the API-URL. For each row of the configuration you have the option to select the HTTP-Method. When exporting the data, each row sends its linked nodemap. To connect the nodemap to the endpoint the “JSON Separator” must match on nodemap and endpoint table.
It is also possible to send e.g. products successively by using placeholders to separate values.

 

Linking to the nodemaps, example for product update from endpoint table:

 

Response Handling

If you want to handle each response, you can use the “Response Handler”-Format Plugin. You can find a detailed documentation for this plugin down below

Response Handler Field Plugin

Was this article helpful?

0 0

How can we improve this article?

Please submit the reason for your vote so that we can improve the article.

Name

Email

Submit