Hi Francesco,
Thank you for the responses. I will try the curl way for the task list and
execute, but can you also let me know about this problem:
"We accidentally mapped a single internal attribute, "dutyOrg" to 2 different
external attributes, "co" and "dutyOrg" on a target LDAP. However, when we ran
the pull task followed by the push task, only the "co" attribute in the target
LDAP instance was changed. In other words, the mapping from the one internal
attribute to two different external attributes didn't appear to work. For us,
if this is the case, this would be a MAJOR problem, as in the current product
we use, we have many attribute flows where a single attribute is pushed to
multiple attributes in the target LDAPs."
Can we map an internal attribute to multiple external attributes (on the PUSH)?
Or can we only map the internal=>external attributes 1 to 1?
Also, is there any other way to find the task UUID, other than the way I have
been finding them, by using the task --list command and searching for the task
key in the output?
Thanks,Jim
On Thursday, November 21, 2019, 7:37:47 AM UTC, Francesco Chicchiriccò
<[email protected]> wrote:
Hi,
as a general concept, please consider that because of
https://issues.apache.org/jira/browse/SYNCOPE-1413
the Syncope CLI code was removed from master branch: this means that Syncope
2.1.X is the last series providing such a component.
I have just created
https://issues.apache.org/jira/browse/SYNCOPE-1514
to review the Reference Guide accordingly.
About your specific items, please see in-line below. Regards.
On 20/11/19 23:12, [email protected] wrote:
Hi,
We have been testing Syncope CLI and especially the tasks execute and list
command, and we have encountered a few problems:
- When we tried running "./syncopeadm.sh --list PULL" or "./syncopeadm.sh
--list PULL", it listed the runs, but the output was old, dated Nov. 6 and Nov.
7 (today is Nov. 20). In other words, the output from the "–list PULL" and
"–list PUSH" commands seems to be stuck and not recording current statuses, I
think.
I guess that by "date" you are referring to last executions.
Unfortunately, the CLI command returns the task list ordered by creation, with
no paging support.
As an alternative to CLI, you can empower the popular curl program; for
example, if you want to get the list of pull tasks ordered by their most recent
last executions:
curl -X GET -u admin:password -H "Accept:
application/json""http://host:port/syncope/rest/tasks/PULL?page=1&size=25&orderby=start%20DESC&details=true";
assuming that:
* Core is reachable at http://host:port/syncope/
* you are using basic authentication with admin user (and you haven't changed
the default password, which is definitely a bad practice)
- The CLI tasks commands use a task "key" to identify each task. The task
"key" is a long hex-like string, and is probably not memorizable. Also, so
far, the only way that I have been able to find the task "key" for a given task
is to review the output from the --list PULL" or "–list PUSH" commands, which
may also be problematic. Is it possible to use the task names instead of the
task "key" when running commands?
The key values for tasks - as for many other entities including Users - are not
"hex-like" but UUID version 4 - see
https://en.wikipedia.org/wiki/Universally_unique_identifier#Version_4_(random)
for an introduction.
I confirm there is no other value than key that can be used to run tasks; for
example:
curl -X POST -u admin:password -H "Accept:
application/json""http://host:port/syncope/rest/tasks/418a70e8-6c38-4f06-a3c9-ecec2787b069/execute";
will trigger execution of task with key 418a70e8-6c38-4f06-a3c9-ecec2787b069.
Slightly different area:
- We accidentally mapped a single internal attribute, "dutyOrg" to 2
different external attributes, "co" and "dutyOrg" on a target LDAP. However,
when we ran the pull task followed by the push task, only the "co" attribute in
the target LDAP instance was changed. In other words, the mapping from the one
internal attribute to two different external attributes didn't appear to work.
For us, if this is the case, this would be a MAJOR problem, as in the current
product we use, we have many attribute flows where a single attribute is pushed
to multiple attributes in the target LDAPs.
Please advise if there are any ways to workaround the above problems?
Thanks, Jim
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/
