You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@syncope.apache.org by Edward Siewick <es...@digipro.com> on 2013/03/03 20:15:40 UTC
Derived attributes -- global & automatic application?
Hi.
With v1.0.5 is there a way to automatically apply "Derived attributes"
to all users? Globally and permanently?
With "Attributes" the values get populated in the Users List. Refreshing
the values seems to require deleting each user, setting the "Reset
Token" for the resource to true, then running the synchronization for
the resource. The default behavior is backward from what I was
expecting, but I can at least do these steps, get the fields populated.
With "Derived attributes," however, I've only managed to get these
populated by walking through the Edit/Derived attributes screen for
every user, add each Derived attribute. I'm thinking there's got to be
a way to pin these to some global, automatic behavior.
The use case I'm playing with has two resources with dissimilar schema:
1. MySQL with an OrangeHRM database, and;
2. openLDAP with inetOrgPerson & posixAccount.
I'm just trying to set the MySQL resource as authoritative for certain
attributes, have these mapped to appropriate inetOrgPerson attributes,
and propagate to the openLDAP directory. When an authoritative bit of
data changes in MySQL, it should be able to translate through without
intervention.
Edward Siewick
Re: Derived attributes -- global & automatic application?
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 07/03/2013 01:41, Edward Siewick wrote:
> [...]
>
> Sorry. I'm still banging my head on the wall over this DbTable
> synchronization configuration. I've picked through the wiki and the
> listserv discussions, worked through Francesco's post carefully.
> There's probably something I'm just not understanding.
>
> Anyway, the "Dry Run" seems OK:
>
> [...]
>
> However, actually executing the MySQL synchronization yields
> [updated/failures]: 0/6, so it's still tripping over something. Just
> guessing at the meaning of that "trying to sync its status anyway",
> I'm thinking it either can't set the ChangeLogColumn field, or it
> can't set some status variable in the schema.
>
> There's also one:
>
> Caused by: org.activiti.engine.ActivitiException:
> No outgoing sequence flow of the exclusive gateway 'activeGw' could be
> selected for continuing the process.
>
> What's this mean? It's trying to tell me something's awry in my
> mapping? If it means the openLDAP connector, that's in the user
> template / resource / "Selected" bucket for the DbTables resource.
Take a look at [1]: in the default workflow definition [2] - I guess you
haven't change this yet - not every state transition is allowed.
>
> The core.log for the run is:
>
> 16:36:43.521 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob
> - Execute synchronization with token null
>
> 16:36:43.541 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob
> - Process 'CREATE_OR_UPDATE' for '8'
> 16:36:43.544 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob
> - About to update [166]
> 16:36:43.545 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob
> - About to update user 166
> 16:36:44.699 ERROR org.apache.syncope.core.scheduling.AbstractTaskJob
> - Update of user 166 failed, trying to sync its status anyway (if
> configured)
> java.lang.NullPointerException: null
Take a look at the message "Execute synchronization with token null":
this suggests that the DBTable connector is sending null values as tokens.
The rest of this stacktrace might be very interesting (about the NPE).
> ...
> [...]
>
> The one improvement I have with the "user template" is that I can
> delete a user and have all the "derived" fields auto-populate. This
> also had the side effect of causing the results to shift slightly. I
> deleted one Username from Syncope, re-synched. Since then, I now have:
>
> Sync result: Users [created/failures]: 0/1 [updated/failures]: 0/5
> [deleted/ failures]: 0/0
> vice
> Sync result: Users [created/failures]: 0/0 [updated/failures]: 0/6
> [deleted/ failures]: 0/0
>
>
> However, afterward, neither "Attributes" nor "Derived attributes"
> refresh with a re-sync even for the one that was synch'd to Syncope
> new and clean.
>
> I did try experimenting with different MySQL data types for the
> ChangeLogColumn. For MySQL only the TIMESTAMP data type is available
> as an internal increment-on-update feature, frankly. I did try a
> trigger for incrementing an integer. It made the OrangeHRM webapp
> really unhappy.
>
> For sanity-checking, here's what the ChangeLogColumn was set to use.
>
> mysql> use orangehrm;
> mysql> ALTER TABLE `hs_hr_employee` ADD `ts_changelog` TIMESTAMP ON
> UPDATE CURRENT_TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ;
>
> # set emp_work_telephone for the first user, and MySQL sets the
> ts_changelog:
>
> mysql> select emp_number , employee_id , emp_lastname , emp_firstname
> , emp_work_telephone , emp_work_email, ts_changelog from hs_hr_employee;
> +------------+-------------+--------------+---------------+--------------------+----------------------------+---------------------+
> | emp_number | employee_id | emp_lastname | emp_firstname |
> emp_work_telephone | emp_work_email | ts_changelog |
> +------------+-------------+--------------+---------------+--------------------+----------------------------+---------------------+
> | 8 | 0008 | Doe | Jane |
> 800-555-1212 | jane.doe@digipro.com | 2013-03-06 14:24:33 |
> | 9 | 0009 | Doe | John |
> | john.doe@digipro.com | 0000-00-00 00:00:00 |
> | 11 | 0011 | Pare | Karen |
> | karen.pare@digipro.com | 0000-00-00 00:00:00 |
> | 12 | 0012 | Robbins | Baskin
> | | baskin.robbins@digipro.com | 0000-00-00 00:00:00 |
> | 13 | 0013 | Dempsey | Jack |
> | jack.dempsey@digipro.com | 0000-00-00 00:00:00 |
> | 14 | 0014 | Hill | Jill |
> | jill.b.hill@example.com | 0000-00-00 00:00:00 |
> +------------+-------------+--------------+---------------+--------------------+----------------------------+---------------------+
>
> Set the rest of the emp_work_telephone via the OrangeHRM interface.
> ts_changelog picks these up:
>
> mysql> select emp_number , employee_id , emp_lastname , emp_firstname
> , emp_work_telephone , emp_work_email, ts_changelog from hs_hr_employee;
> +------------+-------------+--------------+---------------+--------------------+----------------------------+---------------------+
> | emp_number | employee_id | emp_lastname | emp_firstname |
> emp_work_telephone | emp_work_email | ts_changelog |
> +------------+-------------+--------------+---------------+--------------------+----------------------------+---------------------+
> | 8 | 0008 | Doe | Jane |
> 800-555-1212 | jane.doe@digipro.com | 2013-03-06 14:24:33 |
> | 9 | 0009 | Doe | John |
> 123-456-7890 | john.doe@digipro.com | 2013-03-06 15:54:27 |
> | 11 | 0011 | Pare | Karen |
> 789-654-3423 | karen.pare@digipro.com | 2013-03-06 15:56:19 |
> | 12 | 0012 | Robbins | Baskin |
> 676-878-9898 | baskin.robbins@digipro.com | 2013-03-06 15:56:50 |
> | 13 | 0013 | Dempsey | Jack |
> 444-666-7777 | jack.dempsey@digipro.com | 2013-03-06 15:54:56 |
> | 14 | 0014 | Hill | Jill |
> 546-864-5656 | jill.b.hill@example.com | 2013-03-06 15:55:51 |
> +------------+-------------+--------------+---------------+--------------------+----------------------------+---------------------+
>
> However, these doesn't seem to have an effect on the results of the
> DbTable / MySQL synchronization task. Whatever my error here, the
> ChangeLogColumn stuff isn't part of it. (Leaving the parameter out of
> the connector altogether gives the same log result.)
I think you'd better start this Syncope exploration from scratch and go
on step-by-step:
1. clean up your Syncope persistence storage (PostgreSQL?) and restart
Syncope
2. define a DbTable Connector for your MySQL database, flag all capabilities
3. create a Resource, associate it with the Connector (2), define a
reasonable mapping for the columns in the MySQL table (*not* including
the ts_changelog column)
4. define a Synchronization Task for the Resource created at (3) and
flag everything (including "Full reconciliation") in its Profile tab
5. execute once the Synchronization Task from (4), check that all users
from the MySQL table were created in Syncope
6. change some value (for example 'emp_lastname') in the MySQL table,
re-execute the Synchronization Task from (4) and check that the
matching Syncope users were updated accordingly
If (5) and (6) are fine now you can go on with the following:
7. change the Connector (2) by configuring the ChangeLog column (even
though I haven't never had to deal with it directly, I guess that the
'ts_changelog' defined above with the increment-on-update MySQL feature
is just fine)
8. Unflag "Full reconciliation" from the Synchronization Task (4)
9. remove all users from Syncope via the admin console
At this point try again to execute (5) and (6): these should work in the
same way as before.
Once all this is working, you can start thinking about propagating these
data to another external resource (OpenLDAP in your case).
> My Apologies about the long post.
You're welcome.
Regards.
[1]
https://cwiki.apache.org/confluence/display/SYNCOPE/FAQ#FAQ-Igettheerror%22WorkflowException%3A...Nooutgoingsequenceflow...%22whenupdatinganuser
[2] https://cwiki.apache.org/confluence/display/SYNCOPE/Default+Workflow
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: Derived attributes -- global & automatic application?
Posted by Edward Siewick <es...@digipro.com>.
On 03/04/2013 04:57 AM, Francesco Chicchiriccò wrote:
> On 03/03/2013 20:15, Edward Siewick wrote:
>> Hi.
>>
>> With v1.0.5 is there a way to automatically apply "Derived
>> attributes" to all users? Globally and permanently?
>>
>> With "Attributes" the values get populated in the Users List.
>> Refreshing the values seems to require deleting each user, setting
>> the "Reset Token" for the resource to true, then running the
>> synchronization for the resource. The default behavior is backward
>> from what I was expecting, but I can at least do these steps, get the
>> fields populated.
>>
>> With "Derived attributes," however, I've only managed to get these
>> populated by walking through the Edit/Derived attributes screen for
>> every user, add each Derived attribute. I'm thinking there's got to
>> be a way to pin these to some global, automatic behavior.
>>
>> The use case I'm playing with has two resources with dissimilar schema:
>> 1. MySQL with an OrangeHRM database, and;
>> 2. openLDAP with inetOrgPerson & posixAccount.
>>
>> I'm just trying to set the MySQL resource as authoritative for
>> certain attributes, have these mapped to appropriate inetOrgPerson
>> attributes, and propagate to the openLDAP directory. When an
>> authoritative bit of data changes in MySQL, it should be able to
>> translate through without intervention.
>
> Hi Edward,
> let me try to rephrase your requirements in Syncope terms (feel free
> to correct, of course):
>
> You have
> 1. a "MySQL" resource, with DbTable connector
> 2. an "OpenLDAP" resource, with LDAP connector
>
> You need to (periodically) synchronize users from (1) and to propagate
> them to (2); for this reason you have also defined:
> 3. a synchronization task for the MySQL resource, possibly with some
> scheduling
>
> Now you need that users synchronized from MySQL are automatically
> assigned some derived attributes and the OpenLDAP resource.
> The way to accomplish this in Syncope is to define a "user template"
> [1], for the task from the (3) above. For your needs, you just need to
> add the derived attributes and the OpenLDAP resource to the user template.
>
> You can take a look at how the user action flow generally works in
> Syncope [2].
>
> As a side note, you don't generally need to remove users to get their
> attributes updated upon synchronization: make sure
> a. to have the "Update matched identities" flagged for (3)
> b. that mapping defined for (1) is working for matching existing
> users during synchronization - empower the "dry run" feature [3] for
> this and examine the output of the related execution to check if users
> are matched
>
> Finally, please be aware that configuring the DbTable connector (used
> for (1)) for actual synchronization requires to specify the
> changeLogColumn [4]. I'd rather suggest to start without this column
> and to flag "Full reconciliation" for (3), at least for the moment.
>
> HTH
> Regards.
>
> [1]
> https://cwiki.apache.org/confluence/display/SYNCOPE/Tasks#Tasks-SpecifyUserTemplate
> [2] https://cwiki.apache.org/confluence/display/SYNCOPE/User+action+flows
> [3] https://cwiki.apache.org/confluence/display/SYNCOPE/Tasks#Tasks-DryRun
> [4] https://connid.atlassian.net/wiki/display/BASE/Database+Table
> --
> Francesco Chicchiriccò
>
> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> http://people.apache.org/~ilgrosso/
Sorry. I'm still banging my head on the wall over this DbTable
synchronization configuration. I've picked through the wiki and the
listserv discussions, worked through Francesco's post carefully. There's
probably something I'm just not understanding.
Anyway, the "Dry Run" seems OK:
16:34:52.098 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
Execute synchronization with token null
16:34:52.572 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
Process 'CREATE_OR_UPDATE' for '8'
16:34:52.616 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
About to update [166]
16:34:52.616 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
About to update user 166
16:34:53.055 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
User 166 successfully updated
16:34:53.056 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
Process 'CREATE_OR_UPDATE' for '9'
16:34:53.088 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
About to update [151]
16:34:53.088 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
About to update user 151
16:34:53.586 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
User 151 successfully updated
16:34:53.587 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
Process 'CREATE_OR_UPDATE' for '11'
16:34:53.619 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
About to update [168]
16:34:53.620 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
About to update user 168
16:34:53.957 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
User 168 successfully updated
16:34:53.957 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
Process 'CREATE_OR_UPDATE' for '12'
16:34:53.990 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
About to update [153]
16:34:53.990 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
About to update user 153
16:34:54.320 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
User 153 successfully updated
16:34:54.320 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
Process 'CREATE_OR_UPDATE' for '13'
16:34:54.353 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
About to update [154]
16:34:54.353 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
About to update user 154
16:34:54.673 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
User 154 successfully updated
16:34:54.674 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
Process 'CREATE_OR_UPDATE' for '14'
16:34:54.706 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
About to update [169]
16:34:54.707 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
About to update user 169
16:34:55.125 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
User 169 successfully updated
16:34:55.127 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
Sync result: ==>Dry run only, no modifications were made<==
Users [created/failures]: 0/0 [updated/failures]: 6/0 [deleted/
failures]: 0/0
Created:
Updated:
UPDATE SUCCESS (id/ name): 166/ null
UPDATE SUCCESS (id/ name): 151/ null
UPDATE SUCCESS (id/ name): 168/ null
UPDATE SUCCESS (id/ name): 153/ null
UPDATE SUCCESS (id/ name): 154/ null
UPDATE SUCCESS (id/ name): 169/ null
Deleted:
###
However, actually executing the MySQL synchronization yields
[updated/failures]: 0/6, so it's still tripping over something. Just
guessing at the meaning of that "trying to sync its status anyway", I'm
thinking it either can't set the ChangeLogColumn field, or it can't set
some status variable in the schema.
There's also one:
Caused by: org.activiti.engine.ActivitiException:
No outgoing sequence flow of the exclusive gateway 'activeGw' could be
selected for continuing the process.
What's this mean? It's trying to tell me something's awry in my mapping?
If it means the openLDAP connector, that's in the user template /
resource / "Selected" bucket for the DbTables resource.
The core.log for the run is:
16:36:43.521 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
Execute synchronization with token null
16:36:43.541 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
Process 'CREATE_OR_UPDATE' for '8'
16:36:43.544 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
About to update [166]
16:36:43.545 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
About to update user 166
16:36:44.699 ERROR org.apache.syncope.core.scheduling.AbstractTaskJob -
Update of user 166 failed, trying to sync its status anyway (if configured)
java.lang.NullPointerException: null
...
16:36:45.182 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
User 166 successfully updated
16:36:45.183 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
Process 'CREATE_OR_UPDATE' for '9'
16:36:45.185 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
About to update [151]
16:36:45.185 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
About to update user 151
16:36:45.851 ERROR org.apache.syncope.core.scheduling.AbstractTaskJob -
Update of user 151 failed, trying to sync its status anyway (if configured)
java.lang.NullPointerException: null
...
16:36:46.181 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
User 151 successfully updated
16:36:46.181 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
Process 'CREATE_OR_UPDATE' for '11'
16:36:46.183 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
About to update [168]
16:36:46.183 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
About to update user 168
16:36:46.577 ERROR org.apache.syncope.core.scheduling.AbstractTaskJob -
Update of user 168 failed, trying to sync its status anyway (if configured)
java.lang.NullPointerException: null
...
16:36:46.763 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
User 168 successfully updated
16:36:46.764 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
Process 'CREATE_OR_UPDATE' for '12'
16:36:46.766 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
About to update [153]
16:36:46.766 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
About to update user 153
16:36:47.177 ERROR org.apache.syncope.core.scheduling.AbstractTaskJob -
Update of user 153 failed, trying to sync its status anyway (if configured)
java.lang.NullPointerException: null
...
16:36:47.379 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
User 153 successfully updated
16:36:47.379 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
Process 'CREATE_OR_UPDATE' for '13'
16:36:47.381 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
About to update [154]
16:36:47.381 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
About to update user 154
16:36:47.862 ERROR org.apache.syncope.core.scheduling.AbstractTaskJob -
Update of user 154 failed, trying to sync its status anyway (if configured)
java.lang.NullPointerException: null
...
16:36:47.962 ERROR org.apache.syncope.core.scheduling.AbstractTaskJob -
Could not update user 13
org.apache.syncope.core.workflow.WorkflowException:
org.activiti.engine.ActivitiException: No outgoing sequence flow of the
exclusive gateway 'activeGw' could be selecte
d for continuing the process
...
Caused by: org.activiti.engine.ActivitiException:
*No outgoing sequence flow of the exclusive gateway 'activeGw' could be
selected for continuing the process*
...
16:36:47.963 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
User 154 successfully updated
...
16:36:47.963 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
Process 'CREATE_OR_UPDATE' for '14'
16:36:47.965 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
About to update [169]
16:36:47.966 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
About to update user 169
16:36:48.355 ERROR org.apache.syncope.core.scheduling.AbstractTaskJob -
Update of user 169 failed, trying to sync its status anyway (if configured)
java.lang.NullPointerException: null
...
16:36:48.536 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
User 169 successfully updated
16:36:48.538 DEBUG org.apache.syncope.core.scheduling.AbstractTaskJob -
Sync result: Users [created/failures]: 0/0 [updated/failures]: 0/6
[deleted/ failures]: 0/0
Failed to update: UPDATE FAILURE (id/ name): 166/ null with message:
Update failed, trying to sync status anyway (if configured)
null
UPDATE FAILURE (id/ name): 151/ null with message: Update failed, trying
to sync status anyway (if configured)
null
UPDATE FAILURE (id/ name): 168/ null with message: Update failed, trying
to sync status anyway (if configured)
null
UPDATE FAILURE (id/ name): 153/ null with message: Update failed, trying
to sync status anyway (if configured)
null
UPDATE FAILURE (id/ name): 154/ null with message:
org.activiti.engine.ActivitiException:
No outgoing sequence flow of the exclusive gateway 'activeGw' could be
selected for continuing the process
UPDATE FAILURE (id/ name): 169/ null with message: Update failed, trying
to sync status anyway (if configured)
null
Created:
Updated:
Deleted:
###
The one improvement I have with the "user template" is that I can delete
a user and have all the "derived" fields auto-populate. This also had
the side effect of causing the results to shift slightly. I deleted one
Username from Syncope, re-synched. Since then, I now have:
Sync result: Users [created/failures]: 0/1 [updated/failures]: 0/5
[deleted/ failures]: 0/0
vice
Sync result: Users [created/failures]: 0/0 [updated/failures]: 0/6
[deleted/ failures]: 0/0
However, afterward, neither "Attributes" nor "Derived attributes"
refresh with a re-sync even for the one that was synch'd to Syncope new
and clean.
I did try experimenting with different MySQL data types for the
ChangeLogColumn. For MySQL only the TIMESTAMP data type is available as
an internal increment-on-update feature, frankly. I did try a trigger
for incrementing an integer. It made the OrangeHRM webapp really unhappy.
For sanity-checking, here's what the ChangeLogColumn was set to use.
mysql> use orangehrm;
mysql> ALTER TABLE `hs_hr_employee` ADD `ts_changelog` TIMESTAMP ON
UPDATE CURRENT_TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ;
# set emp_work_telephone for the first user, and MySQL sets the
ts_changelog:
mysql> select emp_number , employee_id , emp_lastname , emp_firstname ,
emp_work_telephone , emp_work_email, ts_changelog from hs_hr_employee;
+------------+-------------+--------------+---------------+--------------------+----------------------------+---------------------+
| emp_number | employee_id | emp_lastname | emp_firstname |
emp_work_telephone | emp_work_email | ts_changelog |
+------------+-------------+--------------+---------------+--------------------+----------------------------+---------------------+
| 8 | 0008 | Doe | Jane |
800-555-1212 | jane.doe@digipro.com | 2013-03-06 14:24:33 |
| 9 | 0009 | Doe | John | |
john.doe@digipro.com | 0000-00-00 00:00:00 |
| 11 | 0011 | Pare | Karen | |
karen.pare@digipro.com | 0000-00-00 00:00:00 |
| 12 | 0012 | Robbins | Baskin |
| baskin.robbins@digipro.com | 0000-00-00 00:00:00 |
| 13 | 0013 | Dempsey | Jack | |
jack.dempsey@digipro.com | 0000-00-00 00:00:00 |
| 14 | 0014 | Hill | Jill | |
jill.b.hill@example.com | 0000-00-00 00:00:00 |
+------------+-------------+--------------+---------------+--------------------+----------------------------+---------------------+
Set the rest of the emp_work_telephone via the OrangeHRM interface.
ts_changelog picks these up:
mysql> select emp_number , employee_id , emp_lastname , emp_firstname ,
emp_work_telephone , emp_work_email, ts_changelog from hs_hr_employee;
+------------+-------------+--------------+---------------+--------------------+----------------------------+---------------------+
| emp_number | employee_id | emp_lastname | emp_firstname |
emp_work_telephone | emp_work_email | ts_changelog |
+------------+-------------+--------------+---------------+--------------------+----------------------------+---------------------+
| 8 | 0008 | Doe | Jane |
800-555-1212 | jane.doe@digipro.com | 2013-03-06 14:24:33 |
| 9 | 0009 | Doe | John |
123-456-7890 | john.doe@digipro.com | 2013-03-06 15:54:27 |
| 11 | 0011 | Pare | Karen |
789-654-3423 | karen.pare@digipro.com | 2013-03-06 15:56:19 |
| 12 | 0012 | Robbins | Baskin |
676-878-9898 | baskin.robbins@digipro.com | 2013-03-06 15:56:50 |
| 13 | 0013 | Dempsey | Jack |
444-666-7777 | jack.dempsey@digipro.com | 2013-03-06 15:54:56 |
| 14 | 0014 | Hill | Jill |
546-864-5656 | jill.b.hill@example.com | 2013-03-06 15:55:51 |
+------------+-------------+--------------+---------------+--------------------+----------------------------+---------------------+
However, these doesn't seem to have an effect on the results of the
DbTable / MySQL synchronization task. Whatever my error here, the
ChangeLogColumn stuff isn't part of it. (Leaving the parameter out of
the connector altogether gives the same log result.)
My Apologies about the long post.
Edward
Re: Derived attributes -- global & automatic application?
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 03/03/2013 20:15, Edward Siewick wrote:
> Hi.
>
> With v1.0.5 is there a way to automatically apply "Derived attributes"
> to all users? Globally and permanently?
>
> With "Attributes" the values get populated in the Users List.
> Refreshing the values seems to require deleting each user, setting the
> "Reset Token" for the resource to true, then running the
> synchronization for the resource. The default behavior is backward
> from what I was expecting, but I can at least do these steps, get the
> fields populated.
>
> With "Derived attributes," however, I've only managed to get these
> populated by walking through the Edit/Derived attributes screen for
> every user, add each Derived attribute. I'm thinking there's got to
> be a way to pin these to some global, automatic behavior.
>
> The use case I'm playing with has two resources with dissimilar schema:
> 1. MySQL with an OrangeHRM database, and;
> 2. openLDAP with inetOrgPerson & posixAccount.
>
> I'm just trying to set the MySQL resource as authoritative for certain
> attributes, have these mapped to appropriate inetOrgPerson attributes,
> and propagate to the openLDAP directory. When an authoritative bit of
> data changes in MySQL, it should be able to translate through without
> intervention.
Hi Edward,
let me try to rephrase your requirements in Syncope terms (feel free to
correct, of course):
You have
1. a "MySQL" resource, with DbTable connector
2. an "OpenLDAP" resource, with LDAP connector
You need to (periodically) synchronize users from (1) and to propagate
them to (2); for this reason you have also defined:
3. a synchronization task for the MySQL resource, possibly with some
scheduling
Now you need that users synchronized from MySQL are automatically
assigned some derived attributes and the OpenLDAP resource.
The way to accomplish this in Syncope is to define a "user template"
[1], for the task from the (3) above. For your needs, you just need to
add the derived attributes and the OpenLDAP resource to the user template.
You can take a look at how the user action flow generally works in
Syncope [2].
As a side note, you don't generally need to remove users to get their
attributes updated upon synchronization: make sure
a. to have the "Update matched identities" flagged for (3)
b. that mapping defined for (1) is working for matching existing
users during synchronization - empower the "dry run" feature [3] for
this and examine the output of the related execution to check if users
are matched
Finally, please be aware that configuring the DbTable connector (used
for (1)) for actual synchronization requires to specify the
changeLogColumn [4]. I'd rather suggest to start without this column and
to flag "Full reconciliation" for (3), at least for the moment.
HTH
Regards.
[1]
https://cwiki.apache.org/confluence/display/SYNCOPE/Tasks#Tasks-SpecifyUserTemplate
[2] https://cwiki.apache.org/confluence/display/SYNCOPE/User+action+flows
[3] https://cwiki.apache.org/confluence/display/SYNCOPE/Tasks#Tasks-DryRun
[4] https://connid.atlassian.net/wiki/display/BASE/Database+Table
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/