Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Follow the steps below to learn how to authenticate Astera’s Server APIs.
Right-click on the server name in Server Explorer > Server Connections > DEFAULT > HTTPS://(ServerName):9260.
A wizard will appear with the Centerprise Server API Path. Click on the copy icon located at the bottom-left of the wizard to copy it.
A message will appear to confirm that the text has been copied successfully. Click OK.
Click the Import API option in the API Browser and paste the Astera Server API path in the URL box. Then click OK.
Note: Check the “Ignore certificate errors over HTTP/SSL” option to avoid any certification barriers.
A wizard will appear, notifying you about the created shared action file. Click Yes to set it up.
You can also click on the .sact file in Project Explorer to configure the authentication settings.
The API Browser will be populated with Astera’s Server APIs, which you can use in your dataflow.
Right-click on the Centerprise_Server object and select Properties.
This will open the API Connection screen. Select the Security Type as Bearer Token, as Astera Server APIs use Bearer Token authentication.
Provide the User Name, Password, and Token URL for Bearer Token. Then click Request Token to generate a token, and click OK. Press Ctrl+S to save changes in the shared action file.
Note: You will have to regenerate the token if the validity period has expired.
Now, drag-and-drop the /api/ServerInfo from the API Browser to make a GET request.
Right-click on the object’s header and select Preview Output.
This is how your output would look like:
This concludes working with Astera’s Server API.
Square API is an HTTP-based API that follows REST standards. It allows you to manage the resources of your Square account by making requests to URLs representing those resources. You can configure Square API for use in Astera by providing its swagger definition using the Import API option in the API Browser.
After you have created the application in Square, go to Manage Properties.
Now go to OAuth properties in Production tab. Here, you have to provide the Redirect URL for the authorization callback.
Note: Save Applicant ID and secret to use it later for Astera authentication.
Reference Link: https://developer.squareup.com/docs/oauth-api/overview
Now create an integration project in Astera. Also, import the following swagger definition in the API Browser:
Base Url: https://raw.githubusercontent.com/square/connect-api-specification/master/api.json
Go to the Square’s shared action file’s (.sact) properties to authenticate it in Astera.
You can authorize Square API by using Security Type OAuth 2 or Bearer Token. In this example, we will be authorizing using OAuth 2.
Set its Security Type as ‘OAuth 2’ and Grant Type as ‘Authentication Code’. Provide the application ID and secret that you saved in step 2.
Click on Request Token to get the access token to Square API.
Auth Url: https://connect//squareup.com/oauth2/authorize
Access Token Url: https://connect.squareup.com/oauth2/token
Additional Info: You can modify your authorization by mentioning the names of only those permissions that you want to access from your Square account in Astera. In case you want to access all of them, leave the settings at default.
Once you get the access token, save the Shared Action file and you are ready to use Square API in Astera.
This concludes authenticating the Square API in Astera.
The ActiveCampaign API is structured around REST, HTTP, and JSON. You can make requests by using URL endpoints particular to a specific resource. The resources in ActiveCampaign are represented in JSON following a conventional schema. In Astera, you can configure an ActiveCampaign API using the Import API option present in the REST API Browser.
ActiveCampaign does not provide an Open API definition so we will add a request manually by using a Custom API in Astera.
To authorize an ActiveCampaign API in Astera, follow these steps:
Create an integration project in Astera.
Create a Custom API and provide Base Url.
Reference link for Base Url: https://developers.activecampaign.com/reference#url
Now, you need to authenticate the ActiveCampaign APIs to use them in your dataflow. Without authentication, you will get an error. To authenticate an API, go to the Project Explorer and double-click on the API’s .sact file under the Shared Connection node.
The ActiveCampaign .sact file will open in the designer. Now, right-click the shared action file’s header and select Properties.
ActiveCampaign uses an API Key as Security Type. Specify your Key and Value.
Key: API-Token
Value: {Token}
Click OK, and save the shared action file (.sact).
Add methods in REST API Browser panel which you want to use in Astera by adding requests, and you are ready to use the ActiveCampaign API in Astera.
This concludes authorizing the ActiveCampaign API.
The Avaza API follows REST protocol with ‘OAuth2’ authentication. It allows you to access contacts, projects, tasks, invoices and taxes. In Astera, you can configure an Avaza API through a swagger definition using the Import API option in API Browser.
Let’s go over how we can authenticate an Avaza API in Astera.
Create an integration project by going to Project > New > Integration Project.
To import Avaza API in your Astera client, click on the following icon.
An Import API window will open. Here you will need to select your relevant import source. In this case, we will import using the Json/Yml Url source.
Base URL: https://api.avaza.com/swagger/docs/v1
You will see that all the APIs present on Avaza’s URL have been populated in the API Browser.
Now, you need to authenticate the Avaza APIs to be able to use them in your dataflow. Without authentication, you will get an error. To authenticate an API, go to the Project Explorer and double click on the API’s .sact file under the Shared Connection node.
The Avaza .sact file will open on the designer. Now, right-click the shared action file’s header and select Properties.
This will open the API Connection window where you can configure settings to authenticate Avaza API.
Avaza uses ‘OAuth 2’ authentication. In the ‘OAuth 2’ Security Type, select one from the following Grant Type options:
Authorization Code
Implicit
In this case, we will be using the ‘Authorization Code’.
Note: Login to your Avaza account and go to Settings > Developer Apps > Add OAuth App to generate the ClientID and Client Secret.
Auth Url: https://any.avaza.com/oauth2/authorize
Access Token Url: https://any.avaza.com/oauth2/token
Now, click Request token to generate an access token and refresh token for Avaza.
Note: As you click on Request Token, Avaza’s authorization app will open where you will be required to provide your credentials to be able to generate access token and refresh token to access Avaza.
After authentication, save the shared action file, and you are ready to use Avaza APIs in Astera.
This concludes authenticating the Avaza APIs in Astera.
Facebook uses HTTP-based APIs that can be utilized to extract or load data, to and from Facebook. You can configure Facebook APIs for use in Astera using the ‘Custom API’ source in the REST API Browser (Beta).
To authorize a Facebook API in Astera, follow the steps below.
Go to this Url: https://developers.facebook.com/ and log in.
Note: If you have not created an account yet, you need to create one first after signing in.
Enter your Facebook account credentials to log in.
Go to My Apps > Create App to create an application.
Provide the Display Name for your application, and click Create App ID.
Once your application is created, it will show under the My Apps tab.
Click Centerprise to open the dashboard.
Reference Url: https://developers.facebook.com/apps/217423066002800/dashboard/
Click on Settings > Basic to get the relevant credentials.
Reference Url: https://developers.facebook.com/apps/217423066002800/settings/basic/
Here you can see the App ID and App Secret. Save this information to use later for authentication.
To use Bearer Token authentication, go to Tools > Graph API Explorer.
Reference Url: https://developers.facebook.com/tools/explorer/
Click Generate Access Token and copy the token.
To access and try out different APIs, go to Tools > Graph API Explorer.
Reference Url: https://developers.facebook.com/tools/explorer/
Select anything from the drop-down list.
Click Submit, to see the results.
Import the API in Astera using the Import API option in the REST API Browser (Beta). Select API Import Source as Custom API by providing Name and Base Url.
Base Url: https://graph.facebook.com/
Now, you need to authenticate the Facebook APIs to use them in your dataflow. Without authentication, you will get an error. To authenticate an API, go to the Project Explorer panel and double click on the API’s .sact file under the Shared Connection node.
Facebook’s .sact file will open on the designer. Now, right-click on the shared action file’s header and select Properties. This will open the REST API Connection window, where you can configure the settings to authenticate Facebook’s API.
Facebook uses ‘OAuth 2’ authentication with Grant Type, ‘Authorization Code’.
Auth Url: https://www.facebook.com/dialog/oauth
Access Token Url: https://graph.facebook.com/oauth/access_token
Provide ClientID and Client Secret that you had saved earlier, then click on Request token to generate the access token for Facebook.
Note: As you click on Request Token, Facebook’s login window will open where you will have to provide your credentials to generate the access token to access Facebook API.
Save the shared action file after authentication and you are ready to use Facebook APIs in Astera.
This concludes authenticating the Facebook APIs in Astera.
This article is intended to provide a brief user guide to Astera users on how they can use Astera Server APIs to perform some commonly used actions without using the Astera Client.
The document covers the following operations:
Configure Astera Server properties
Configure Astera Server license
Deploy user projects on Astera Server
Schedule/execute the jobs
For the use cases below, Astera Integration Server is installed on a Virtual Machine and no Astera Client is going to be used to perform operations. However, some images of the Astera Client have been used for description purposes. We will use the Postman client as a third-party tool to send API requests to the Astera Server to perform several tasks.
‘POST /api/account/login’
This API returns the bearer token that can be used to make calls to the Astera Server. It also returns some more information about the user.
In this section, we are going to use the API ‘POST /api/Server/Config’ to change Server Profile of the Astera Server.
Here, we can see that a Server Profile named DEFAULT has been selected in our Server Properties.
To change this profile shown in the image above, we must provide the JSON body containing information related to the Repository Database with the name of the desired Server Profile in the POST request.
Note: Server Profile 2 was created in advance to be used in this request.
Once we have provided the relevant information, we can send the request.
We can see that a 200 OK success response is received in the image above.
We can verify using the Astera Client that we have successfully configured our server with the desired profile ServerProfile2.
Note: To see how the JSON request body is structured or what fields are required for a successful POST request, send a request to the GET /api/Server/Config API. This API will return the configured server’s properties in the response.
In this section, we are using the POST /api/License/Key API that allows the user to change the server license. We will also use the POST /api/License/Activate API to activate the license.
Go to Server > Configure > Enter License Key. Here, we can see a user ‘Nisha’ of the organization ‘G’ is registered with an active license.
To change the license key and register the user, we must provide the User, Organization, and License Key in the JSON request body. Refer to image below.
Note: The license key was taken in advance for this demo.
Once we have provided the relevant information, we can send the request.
In response, we can see that a 200 OK success status is received indicating that the license key has been changed.
Now, go to Server > Configure > Enter License Key, and notice the license properties. We can see a user Nisha of the organization Astera with a different/new license key has been registered.
3.3.3. Activate license API Example (/api/License/Activate)
However, the license is not activated yet. To activate the license, we can simply send a request to the /api/License/Activate endpoint. After sending the request, we can see that a 200 OK response is received.
Note: To receive a 200 OK response, we must send an empty text in the body otherwise the request will result in an error. Also, this API only activates the license online.
Go to Server > Configure > Enter License Key again. Here, we can see the status of the license is activated now.
No parameters required, send an empty body here.
Configuration of cluster settings is important before proceeding with the project deployment.
To successfully deploy an archive file (User project .car file) using the APIs, a user must perform the following prerequisites:
Upload the archive file (User project .car file) to the deployment directory.
Upload the config file to the deployment directory. (optional)
There are two methods to do this, let's see each in action.
a. Example of using ‘POST /api/UploadFile’
The user can upload the config and .car files to the deployment directory using APIs. There is a possibility that a user might delete or move the config or .car file from their local machine. To avoid any issues, it is recommended to first upload these files to the deployment directory.
To upload the file, use the ‘POST /api/UploadFile’ API. In this API, we must provide two query parameters:
FileTypes: Extension of the target file e.g., cfg for the config file, car for Archive files.
TargetFileName: Here, we define the target file’s name e.g., Testing.
Next, we need to configure Request Body for this API. For the request body, select the form-data content type, select the Key type as File and provide the desired archive file (.car file) in the Value. Click Send.
Note: The archive project file (.car file) was created in advance for this demo.
Here, we can see that a 200 OK response, with a file path of the deployment directory’s archive file, has been received. Please copy down this path on your notepad as we need to use this path while creating the deployment.
Similarly, we can upload the config file to the deployment directory using this api/UploadFile endpoint.
Parameter description of /api/UploadFile
b. Using the ‘POST api/UploadCarFile’
An archive file (.car file) can also be uploaded to the deployment directory via another API i.e., ‘POST api/UploadCarFile’.
In this API, we do not need to specify the query parameters. Simply select the archive file (.car file) in the body and click Send. Here, we receive the archive file path in the response.
The uploaded files can also be seen in the deployment directory.
Parameter description of api/UploadCarFile
3.5.2. Creating the Project Deployment
3.5.2.1. Using POST /api/Deployment example
Now, let’s proceed to the deployment creation. To create a deployment, we must use the ‘POST /api/Deployment’ API.
In this API’s Request’s Body, we must provide info such as:
Relevant archive (.car) and config (optional) file paths (both local and deployment directory file paths)
The deployment’s name, its ID, and its activation state, etc.
After defining the body, we can click Send.
Here, we can see a 200 OK response has been received indicating that a deployment has been created.
Open the client and go to Server > Deployment Settings > Deployment. In the deployment window, we can see the archive file has successfully been deployed.
Please note the following:
To create a new deployment, we must provide the field “Id” as 0. We should also provide a unique deployment “Name” i.e., not the same name as an already existing deployment. Otherwise, the request will result in a 400 Bad Request error.
If we provide a non-zero “Id” field e.g., Id = 7, the server will consider this request as an update request, and if a deployment with ID 7 already exists on the server it will be modified/updated.
3.5.2.2. Parameter description of /api/Deployment
3.5.3. Post Deployment Modification
The ‘POST /api/Deployment’ API can also be used to modify an existing deployment. In this API’s Request Body, details of an existing deployment are required.
In this scenario, we want to update the name of the above-created DeploymentTesting. However, we do not have its details available.
So, to gather the details, we firstly use the ‘GET api/Deployments’ API to fetch the info of the existing deployment. Then, we copy the deployment Id, UpdateDtTm, and CreatedDtTm fields from the response.
Note: This GET API returns information for all the deployments on the server. Since we desired to modify only one deployment DeploymentTesting, we copied these highlighted fields only.
Now, in the POST Request’s Body, let’s change the deployment Name to DeploymentTesting_Modified and replace the values of Id, UpdateDtTm, and CreatedDtTm fields with the values copied from the GET response.
Let’s send the request.
A 200 OK response is received. Now, go to Server > Deployment Settings > Deployment, in the deployment window, we can see the modified deployment name.
Note: Each time we update an existing deployment the UpdateDtTm field is modified as well. Therefore, we always must send a GET api/Deployments request first to fetch the details of the deployment and then use the received details as the body for the POST request to successfully modify the deployment. Using an invalid (past time) UpdateDtTm value will give a 400 Bad Request error.
Let’s proceed to learn how we can schedule jobs on the server using APIs.
In this section, we are scheduling the previously created deployment using the ‘POST api/Schedule’ API.
This API’s Request Body requires the schedule configuration information, i.e., Schedule Name, Schedule Type, Frequency, Activate State, Server Info, etc.
Let’s create the schedule called Schedule_Testing, which runs daily, with schedule type deployment, an active state as True, etc.
Sending the request shows a 200 OK status response.
If we go to Server > Job Schedules, in the scheduler window, we can see a schedule called Schedule_Testing with the following properties: Schedule Job Id is 4, with Schedule Type as Deployment, running at Frequency daily has been created.
Note: Like the deployment POST API, this POST api/Schedule endpoint can also be used for modification of existing schedules.
Each time we update an existing schedule the UpdateDtTm field is modified as well. Therefore, we always have to send a GET api/Schedules or a GET /api/Schedule/:scheduleId request first to fetch the details and then use the received details as the body for the POST request to successfully modify a schedule.
Note: Using an invalid (past time) UpdateDtTm value will give a 400 Bad Request error.
Note: Client Secret, Access Token and API Key are to be generated by the user, and will be unique for every application. The values specified below are just for example.
Authentication Type: API Key
Import API: https://raw.githubusercontent.com/adafruit/io-api/gh-pages/v2.json
Authentication: API-KEY
Key: X-AIO-Key
Value: aio_UTqF73klycqdLWpbp0wLl7RHKV25
UserName: [Enter you user name]
FeedKey: [Enter your feed key]
Adafruit Login Page: https://accounts.adafruit.com/users/sign_in
Email: [Enter your login email]
Password: [Enter your password]
Authentication Type: OAuth 2, Authorization Code
Import API: https://api.avaza.com/swagger/docs/v1
Authentication: oauth2 (Access token will be valid for 1 day)
Token URL: https://any.avaza.com/oauth2/token
Auth URL: https://any.avaza.com/oauth2/authorize
ClientId: [Enter client ID]
Client Secret: c1d4b723790f0e24d0b2df68ebde613e9533
Avaza Login Page: https://any.avaza.com/account/login
Email: [Enter your email]
Password: [Enter your password]
Authentication Type: Bearer Token
Base URL: https://api.box.com/2.0
Authentication: Bearer Token (Access token will be valid for 1 hr)
Token: 1IVYyDgfDPyWpoXe9c4RMOt7tmtiB75q
Steps to generate access token:
Page: https://app.box.com/developers/console/app/984015/configuration
Email: [Enter your login email]
Password: [Enter password]
Click Generate Developer Token to generate access token
API Reference: https://developer.box.com/en/reference
Authentication Type: OAuth 2, Authorization Code
Base URL: https://graph.facebook.com/
Auth URL: https://www.facebook.com/dialog/oauth
Access Token URL: https://graph.facebook.com/oauth/access_token
Client ID: 217423066002
Client Secret: d7d8969c6ea31bf117f04768b63bb
Credentials to use when using ‘Request Token’
Email address: [Enter your email]
Password: [Enter your password]
Authentication Type: Bearer Token
Base URL: https://www.googleapis.com/drive/v3
Authentication: Bearer Token (Token will be valid for an hour)
Token: ya29.Il_AB6CICAcAQD6lKoQCW3K2DO_enBd3be5G2Vvd0hZ3Q8US4eHL-PEOS1qRD7zzSEN3t_qb_eNqWzZS3zsXP_FcAHA9TSoy-tDpsWv0RnWRledPhZqRt79f9X
API Reference: https://developers.google.com/drive/api/v3/reference
Steps to generate access token:
Go to https://developers.google.com/oauthplayground/
Select the APIs you want to authorize and click Authorize APIs.
On the next screen, provide your credentials.
Email: [Enter your login email]
Password: [Enter your password]
Now click Exchange authorization code for tokens to generate access token.
Authentication Type: API Key
Import API: https://api.doc.nextauth.com/api/swagger.json
Authentication: API-KEY
KEY: [Enter API Key]
VALUE: J5znqilK_qUt65iQyy9W2Q
Help link: https://api.doc.nextauth.com/
Authentication Type: API Key
API key to be passed as a query parameter
JSON File: http://www.omdbapi.com/swagger.json
Steps to generate API Key:
Open
Select Account Type, ‘FREE.’
Enter your email address.
Enter your first name and last name.
Describe in a few words your purpose of using this service.
Click Submit.
You will get the API Key in your email with a link to activate it. Click on this link and the key will be activated.
Authentication Type: Bearer Token
Import API: https://raw.githubusercontent.com/square/connect-api-specification/master/api.json
Authentication: Bearer Token
Token: EAAAEPXVtza2Utrx-GJ90Az4sCQ_NLbLYOKANVFmJiPGJ1Z6B-eJgZ-2V1
Use this API to import: https://raw.githubusercontent.com/
Note: This looks like an issue with Square Connect’s documentation because the ‘Import API’ option does not work.
Authentication Type: Basic Authentication
Username: [Enter username or login email]
Password: [Enter password]
The QuickBooks API is a RESTful API which allows you to read or write data to and from QuickBooks. It uses ‘OAuth 2’ authentication type. You can configure a QuickBooks API in Astera by using the Import API option present in the API Browser.
QuickBooks does not provide Open API definition, so we will add the request manually by using a Custom API in Astera.
We only need to follow steps from Development > Create and Configure an App from the following link:
Authentication steps: https://developer.intuit.com/app/developer/qbo/docs/build-your-first-app
Where the Redirect Url used in step 7 in the above link for Astera would be:
Redirect Url for Astera Server: http://{Server_Name}:8050/)
Note: Save ClientID and secret to use it afterwards in Astera Data Stack authentication.
Create an integration project in Astera.
Create a Custom API and provide a Name and Base Url.
Base Url (Sandbox): https://sandbox-quickbooks.api.intuit.com
Base Url (Production): URL:https://quickbooks.api.intuit.com
Now, you need to authenticate QuickBooks APIs to be able to use them in your dataflow. Without authentication, you will get an error. To authenticate an API, go to the Project Explorer and double click on the API’s .sact file under the Shared Connection node.
The QuickBooks .sact file will open in the designer. Now, right click on the Shared Action file’s header and select Properties.
QuickBooks uses ‘OAuth 2’ Security Type with Grant Type, ‘Authentication Code’.
Auth Url: https://appcenter.intuit.com/connect/oauth2
Token Url: https://oauth.platform.intuit.com/oauth2/v1/tokens/bearer
ClientID: {ClientID}
Client Secret: {Client_Secret}
Scope: {Scope}
State: {State}
Additional Info - You can modify the authorization by mentioning the names of only those permissions that you want to access from QuickBooks in Astera.
Note: While working with QuickBooks APIs, it is necessary to specify Scope and State to generate the access token.
Click OK, and save the Shared Action file (.sact).
Add methods in the REST API Browser which you want to access in Astera by adding requests and you are ready to use QuickBooks APIs in Astera.
This concludes authorizing the QuickBooks API.
Astera’s Server APIs use Bearer Token authentication.
Login
Method: POST
Endpoint: https://{servername}:{portno}/api/account/login
In this case: https://LOCALHOST:9261/api/account/login
Resource: /api/account/login
Request Body
Note: The format of our request body is JSON type.
Status
Method: GET
Endpoint: https://LOCALHOST:9261/api/Job/{jobID}/Status
Resource: /api/Job/{jobID}/Status
Required Parameter
Description: This method fetches the status of a job for the given job ID. A few of the response statuses are given below:
Unknown
Invalid
NotStarted
Queued
Initializing
Running
Completed
The Astera Data Stack provides you with the flexibility to execute your jobs through a third-party tool, without using the Astera client. Let’s learn how to achieve this in the article below.
In this use case, we have our Astera client on a local machine and a server installed on a virtual machine. Instead of using the Astera client, we will use Postman as a third-party tool to send REST requests to the server in order to execute the job.
The workflow document in Astera consists of a Variables object, a FileTransferTask object and a RunDataflow object.
We will pass the name of the file that we want to download and process to the FileTransferTask from the Variables object. The Variables object takes an input from the REST call sent through Postman, and passes it to FTP to download the file with that name. We then pass the file path of the downloaded file to the RunDataflow object.
In the following section, we will cover a step-by-step overview of how you can achieve this.
We will make the first API call for logging into the Astera server to generate an access token. Provide the following credentials in the request body and click on Send.
User: admin
Password: Admin123
RememberMe: 1
The Astera server will provide you with an access token in response.
In the second step, we will send the path of the file that we want to download from FTP, in the form of a string, to the Variables object.
In the parameters:
ActionName: Variables
Name of the object present inside the workflow to which the name of the file will be passed
Parameters: sourceFilePath
The value of the input variable field inside the workflow
Value: [file path of the file that you want to download]
The value of the input variable field inside the workflow
As soon as you send this API request, Astera will provide you with a jobID that you can use to get the job status.
In the third step, we will make a GET call to fetch the job’s status by providing the job ID.
This is what Astera’s response would look like.
This concludes accessing Astera’s server APIs through a third-party tool.
AWS Signature authentication is the process of verifying the authenticity of requests made to Amazon Web Services (AWS) using the AWS Signature method.
This authentication process involves calculating a digital signature for each request using the requester’s access key and secret access key, along with details about the request being made. AWS verifies the signature against the user’s access credentials and grants access to the requested resources if the signature is valid.
The AWS Signature authentication method ensures that requests are securely transmitted and that only authorized users can access AWS resources.
Astera lets the user configure an API Connection with AWS Signature as an authentication type.
Drag-and-drop an API Connection object from the Toolbox onto a Dataflow.
Right-Click on the object and select Properties from the context menu.
This will open a new window:
Base URL: Here, you can specify the base URL of the API which will prepend as a common path to all API endpoints sharing this connection. A Base URL usually consists of the scheme hostname and port of the API web address.
Timeout (msec): Specify the duration, in milliseconds, to wait for the API server to respond before giving a timeout error.
Include Client SSL Certificate: Selecting this option is going to include any Client SSL certificate that is needed for authentication.
Enable Authentication Logs: Selecting this checkbox will allow the client to generate authentication logs when the API connection has been configured.
Define the Base URL and select AWS Signature from the security type.
Selecting it will make the following options available.
Access Key: The unique access key provided to the AWS user for authentication.
Secret Key: The corresponding unique key provided to the AWS user for authentication
AWS Region: The region from where the API connection is being made, set by the admin.
Service Name: The name of the AWS service being used in the API Connection.
Note: While the Access Key and Secret Key are unique to each user, the AWS Region and Service Name are common among a group of users.
5. Once the fields have been filled, click OK and the API Connection will be configured.
This API Connection can then be used in an API Client object to make API Calls to the resource.
Drag-and-drop an API Client object and configure it with the API Connection.
Preview the output of the API Client object.
As you can see, the response has returned a ‘200 OK’ status.
This concludes the configuration and testing of the AWS Signature Authentication in Astera.
A sample server config JSON body is provided for reference.
The JSON payload sample for the cluster configuration is attached .
A sample deployment JSON body is attached for reference.
A sample JSON is attached for reference.
A postman collection containing all the server APIs discussed in this article is attached .
Fields
Field Location
Data Type
Description
JSON Format
User
Body
String
Username of the Astera user account.
{ "user": "admin", "password": "Admin123", "rememberMe": true }
Password
Body
String
Password of the Astera user account.
RememberMe
Body
Boolean
Binary value. Pass “1” for yes and “0” for no.
Parameter
Parameter Location
Data Type
Description
JobID
URI
Integer
Job ID of the flow that has already been executed in Astera.
https://localhost:9261/api/account/login
|
Description
|
{
|
"User":"admin",
|
Username of the user trying to login (default is "admin")
|
"Password":"Admin123",
|
Password of the user trying to login (default is "Admin123")
|
"RememberMe":1
|
This parameter takes 1 or 0, indicating True or False.
|
}
|
{
|
"configParameters": {
|
This section is recommended to leave defaulted.
|
"instrumentationOn": false,
|
Instrumentation slows down a server's processing capacity, but adds more logging for visibility. Only set to "true" when you want to debug an issue with the server or job running on that server.
|
"purgeChunkSize": 10000,
|
This is the number of records the server will try to delete at once when purging old job and event history from the cluster database.
|
"purgeCommandTimeoutSeconds": 600,
|
This is how long the server should wait for the SQL command to complete before giving up on a purge operation.
|
"purgeWindowStartHour": 0,
|
This is the beginning of the 24-hour window in which the server can attempt to purge old job and event history from the cluster database.
|
"purgeWindowEndHour": 24
|
The is the end of the 24-hour window in which the server can attempt to purge old job and event history from the cluster database.
|
},
|
"serverDbInfo": {
|
"port": 1433,
|
SQL Server database port on which instance is running on
|
"protocol": "http",
|
Protocol for connecting
|
"serviceName": "RepositoryDWB",
|
Name of the database
|
"authenticationType": "SqlServerAuth",
|
Type of authentication, SQL Server Authentication or Windows logon
|
"connectionTimeOut": 15,
|
Timeout when trying to connect to the instance
|
"commandTimeOut": 90,
|
Timeout when executing a command on the SQL server instance
|
"dataProvider": "SqlServer",
|
Database provider name. Either SqlServer or PostgreSQL
|
"server": "localhost",
|
Database instance host server
|
"database": "RepositoryDWB",
|
Name of the database
|
"isRepository": true,
|
This option is used to tell the server that this connection is pointing to an Astera repository. Always set this to true.
|
"schema": "",
|
Schema of the database, by default it’s 'dbo'
|
"user": "sa",
|
Username for logging in to the SQL Server
|
"password": "Astera123"
|
Password for logging in to the SQL Server
|
},
|
"port": 9261,
|
The port where Astera Integration Server is running on. By default its 9261, unless specified during installation
|
"serverProfile": "DEFAULT",
|
Astera Integration Server profile configuration. User can create different profiles for different servers, in this profile the user can set the max job count and other administrative properties.
|
}
|
|
|
Description
|
{
|
"LicenseKeyRegistrationModel":
|
{
|
"user":"TEST",
|
Username you want to register the product with.
|
"organization":"TEST",
|
Organization name you want to register the product with.
|
"key":"TEST"
|
License Key provided by Astera Software.
|
}
|
}
|
{
|
"id": 1,
|
This is the identifier for the settings object in the repository database. Should always be 1.
|
"name": "DEFAULT",
|
This is the name we want to give to our cluster (Server group), by default its set to 'Default'
|
"sendErrorInfoToAstera": true,
|
Allow sending anonymous usage and error data to Astera.
|
"purgeJobInfoAfter": 7,
|
The number of days before a job info will be purged (removed from the repository database). It will no longer be available in the Job Monitor after it is purged.
|
"purgeEventInfoAfter": 7,
|
The number of days before a Server event info will be purged (removed from the repository database). It will no longer be available in the Server Monitor after it is purged.
|
"stagingDirectory": {
|
Setting Staging directory in this section
|
"path": "C:\\Staging"
|
The staging directory path, this is where Astera Integration Server keeps files which are related to a deployment.
|
},
|
"deploymentDirectory": {
|
Setting deployment directory in this section
|
"path": "C:\\Deployment"
|
The deployment directory path, this is where Astera Integration Server keeps a local copy of deployment archive files(.car) and its configuration files (.cfg)
|
},
|
"pauseAllServers": false,
|
This parameter takes in a Boolean value to set the feature for pausing Astera Integration Servers on or off
|
"pauseServersFrom": null,
|
Start time when servers pause. Depends on if pauseAllServers is true.
|
"pauseServersTo": null,
|
End time when servers pause. Depends on if pauseAllServers is true.
|
"clientAndServersShareTheSameFileSystem": false
|
False if the client and the server do not share the same file system. This applies to any scenario when the client and server do not exist on the same machine or network.
|
}
|
Query Parameters | Description |
|
|
FileTypes: Cfg | The extension of the file e.g., Car or Cfg. There are two files related to the Deployment, one is .car file, another is .cfg file. .car files are archive files which have the snapshot of the project when it was generated, and .cfg files are configuration files, it contains the values for the parameters which were used in the project. |
TargetFileName: Testing | The name with which the uploaded files will be saved |
|
|
Request Body (content-type form-data) | Description |
|
|
ArchiveFile | In this parameter, attach the archive or configuration file you wish to upload to the deployment directory. |
Request Body (content-type form-data) | Description |
|
|
Archive | In this parameter, attach the archive or configuration file you wish to upload to the deployment directory. |
Description |
{ |
"userArchiveFilePath": "C:\\Project_ArchiveFile.car", | This is the path that was the source .car file used for deployment. It is not used anywhere at runtime. |
"clusterArchiveFilePath": "C:\\Testing.Car", | Archive file's (.car file's) deployment directory path, i.e, the path to the archive file that is uploaded in the deployment directory. |
"userConfigFilePath": "", | This is the path that was the source .cfg file used for deployment. It is not used anywhere at runtime. |
"clusterConfigFilePath": "", | Config file's (.cfg file's) deployment directory path, i.e, the path to the configuration file that was uploaded in the deployment directory. The config file is optional. |
"encryptFiles": true, | Turn it to true or false to set the encryption of the configuration (.cfg) file on or off. |
"comment": "Modifying by reducing the body", | User comment (i.e., description) attached to a deployment. |
"id": 0, | Deployment ID of the deployment in case of modification. Use zero for new deployments. |
"name": "DeploymentTesting" | Name of the Deployment, this should be a unique name. |
} |
{
|
"archiveStartItem": "C:\\DataflowSample.Df",
|
Initial artifact to run from the deployment. Omit if not using an archive.
|
"schedule": {
|
"dailyScheduleBase": {
|
"startTime": "2022-09-06T04:53:46.2573662-07:00",
|
Date and time when this scheduled job should first start. Since this is a daily schedule, this job will repeat everyday on the same time given here.
|
"typeName": "Astera.Core.DailyScheduleEveryDay"
|
Type of the schedule. i.e, daily, weekly, etc.
|
},
|
"typeName": "Astera.Core.DailySchedule"
|
Type of the schedule. i.e, daily, weekly, etc.
|
},
|
"traceLevel": "Job",
|
Set this parameter to 'Job' if you want to track it in job monitor, otherwise this job's progress will not be tracked.
|
"skipIfRunning": false,
|
Set this to true if you want to skip if the same schedule's last run is already queued or running.
|
"isActive": true,
|
Activates/deactivates the schedule.
|
"jobOptions": {
|
"usePushdownOptimization": false,
|
Set this to true if you want to run scheduled job in 'Pushdown mode'.
|
},
|
"filePathResolved": {
|
This section sets the file path of the archive or flow file.
|
"path": "C:\\SampleConfigFile\\test.car"
|
Path to the .car, .df or .wf file depending on 'isFile' parameter.
|
},
|
"deploymentId": 1,
|
Deployment ID in case using an archive deployment, i.e, 'isFile' is set to 'false'. This can be found under Server->Deployment.
|
"isFile": false,
|
Set this to True if pointing to a dataflow or workflow file directly, otherwise if using deployment set this to false.
|
"name": "test"
|
Name of the scheduled job.
|
}
|
NTLM (NT LAN Manager) authentication is a Microsoft proprietary authentication protocol used to authenticate users in a Windows-based network.
It provides secure authentication by using a challenge-response mechanism, where the server sends a challenge to the client, and the client sends a response that is encrypted using a hash of the user’s password.
NTLM authentication is used in various Microsoft products, including Windows, Internet Explorer, and Microsoft Office.
Astera also offers the ability to use NTLM authentication when establishing an API connection.
To start, drag-and-drop the API Connection object from the Toolbox onto a Dataflow.
Right-click on the object and select Properties from the context menu.
This will open a new window,
Base URL: Here, you can specify the base URL of the API which will prepend as a common path to all API endpoints sharing this connection. A Base URL usually consists of the scheme hostname and port of the API web address.
Timeout (msec): Specify the duration, in milliseconds, to wait for the API server to respond before giving a timeout error.
Include Client SSL Certificate: Selecting this option is going to include any Client SSL certificate that is needed for authentication.
Enable Authentication Logs: Selecting this checkbox will allow the client to generate authentication logs when the API connection has been configured.
Fill in the Base URL and open the Security Type drop-down menu,
For our use case, we have deployed an API on IIS Manager on another machine, and we will send a request to access that API.
Select NTLM as the authentication type.
This will give us the following options,
Username: This field will input the same username that is used to login to Windows.
Password: The password associated with Windows login credentials.
Note: NTLM authentication establishes API connections using a challenge-response mechanism. When sending an API request, Astera sends a hashed version of the user’s credentials (username and password) to the server, which sends back a random challenge. Astera then mixes this challenge with the user’s password and sends back a hashed value for verification. Access is granted if the validation is successful.
Click OK and the API Connection object will be configured with NTLM Authentication.
This API Connection can then be used in API Client objects to make API calls to the server and receive appropriate responses in return.
Drag-and-drop an API Client object onto the dataflow and select the shared connection that was defined.
Note: The Resource will be ‘/’ since our entire address has been defined in the Base URL.
Click OK and preview the output of the API Client object.
As we can see in our data preview window, the request has been sent successfully and the response has returned as ‘200 OK’.
This concludes working with and configuring the NTLM Authentication in Astera.
