Skip to main content
Announcements
July 15, NEW Customer Portal: Initial launch will improve how you submit Support Cases. IMPORTANT DETAILS
cancel
Showing results for 
Search instead for 
Did you mean: 
rx178
Partner - Contributor II
Partner - Contributor II

Do you plan to release an API for Creating TASKs and Endpoints in the future?

Hi Team,

I am working on a program that will operate on the following Qlik Replicate
using the API provided by Qlik Enterprise Manager.

Qlik Enterprise Manager API guide ‒ Qlik Enterprise Manager

There are APIs for retrieving TASK and ENDPOINT information,
But There is no API to create TASKs or create Endpoints.

Do you plan to release an API for creating TASKs and Endpoints in the future?

Best regards,
Michihiro Maeda

Labels (2)
2 Solutions

Accepted Solutions
Heinvandenheuvel
Specialist III
Specialist III

[2024 UPDATE - The AEM API has grown. Please check the latest API manual. Notably check out the "patch_endpoint" API with 'op' request parameter "‘add’,’replace’,’remove’, or ’test’" and JSON 'value'.

It's there.

Just generate a JSON string to describe task(s) and/or endpoint(s) and use ImportTask or ImportAll.

For tasks ImportTask is the obvious choice with additional sanity check that the correct task name is used.

For endpoints you _can_ also use ImportTask and provide a task that can be freely replaced (dummy task?) with as many endpoints as you please.  But for endpoints I would use ImportAll and a JSON which looks like (whitespace optional)

 

 

{
	"name":	"just-some-name-for-your-source-control",
	"cmd.replication_definition":	{
		"databases":	[{
				"name":	"your-db-name",
				"role":	"SOURCE",
				"is_licensed":	true,
				"type_id":	"your-db-type",
				"db_settings":	{
					"$type":...}			
				}]
	},
	"_version":	{
		"version":	"6.3.0.328",
		"version_major":	6,
		"version_minor":	3,
		"version_revision":	328
	}
}

 

 

 

Note 1, you can also provide server settings like scheduling and global error handling with ImportAll.

Note 2, On the Replicate server, without the (rest)API, you can use REPCTL -d <datadirectory> importrepository json_file=xxx.json.  See Replicate User Guide.

Hein.

View solution in original post

Heinvandenheuvel
Specialist III
Specialist III

Yeah no... you don't want to use any of those 'put' endpoint/task services, only putserver.

For starters they are not exposed or documented.

Other then PUTserver, the put services would be relayed to the targeted Replicate server. You can get a sneak peek of how it works over there using REPCTL help option=1 .   this will list 'everything' whether it is useable or not. The PUT services are not useable (through REPCTL) as they need a structure as input. There is no way to provide that, and they would just be too complex.   see a otherwise useless example: "REPCTL putendpointresource ?"

Just use the JSON as your flexible structure. This is an infrequently used service where performance is surely of no concern.  You are not generating multiple tasks per second are you now?.

Indeed the passwords as exported hashed, but can by imported both clear-text and as hash (only to the server they came from).

Hein.

View solution in original post

3 Replies
Heinvandenheuvel
Specialist III
Specialist III

[2024 UPDATE - The AEM API has grown. Please check the latest API manual. Notably check out the "patch_endpoint" API with 'op' request parameter "‘add’,’replace’,’remove’, or ’test’" and JSON 'value'.

It's there.

Just generate a JSON string to describe task(s) and/or endpoint(s) and use ImportTask or ImportAll.

For tasks ImportTask is the obvious choice with additional sanity check that the correct task name is used.

For endpoints you _can_ also use ImportTask and provide a task that can be freely replaced (dummy task?) with as many endpoints as you please.  But for endpoints I would use ImportAll and a JSON which looks like (whitespace optional)

 

 

{
	"name":	"just-some-name-for-your-source-control",
	"cmd.replication_definition":	{
		"databases":	[{
				"name":	"your-db-name",
				"role":	"SOURCE",
				"is_licensed":	true,
				"type_id":	"your-db-type",
				"db_settings":	{
					"$type":...}			
				}]
	},
	"_version":	{
		"version":	"6.3.0.328",
		"version_major":	6,
		"version_minor":	3,
		"version_revision":	328
	}
}

 

 

 

Note 1, you can also provide server settings like scheduling and global error handling with ImportAll.

Note 2, On the Replicate server, without the (rest)API, you can use REPCTL -d <datadirectory> importrepository json_file=xxx.json.  See Replicate User Guide.

Hein.

rx178
Partner - Contributor II
Partner - Contributor II
Author

Hi Hein,  Thanks a lot !

I understand that ImportTask API can be used as an alternative to PutTask API and PutEndpoint API.

At first, I thought that the ImportTask API was not an alternative
because I understood that the password for the database connection defined
in the JSON file must be defined as an encrypted string.

However, it turns out that the password definition for the JSON file specified
by ImportTask API can be done with plain text strings (*).

* https://help.qlik.com/en-US/replicate/November2021/Content/Global_Common/Content/SharedEMReplicate/D...

Thank you !!

Heinvandenheuvel
Specialist III
Specialist III

Yeah no... you don't want to use any of those 'put' endpoint/task services, only putserver.

For starters they are not exposed or documented.

Other then PUTserver, the put services would be relayed to the targeted Replicate server. You can get a sneak peek of how it works over there using REPCTL help option=1 .   this will list 'everything' whether it is useable or not. The PUT services are not useable (through REPCTL) as they need a structure as input. There is no way to provide that, and they would just be too complex.   see a otherwise useless example: "REPCTL putendpointresource ?"

Just use the JSON as your flexible structure. This is an infrequently used service where performance is surely of no concern.  You are not generating multiple tasks per second are you now?.

Indeed the passwords as exported hashed, but can by imported both clear-text and as hash (only to the server they came from).

Hein.