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ò <ilgro...@apache.org> 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, oh...@yahoo.com 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/