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/
