TODO, What is the audience of this document?
TODO, speak about synchronization direction options and consequences.
TODO, speak about synchronization options available for each element.
This section show typical synchronization environment treated by Mizura.
To simplify, a LEFT_TO_RIGHT synchronization operation is used, where left elements are Enterprise Architect usecases and right elements are Jira issues.
The elements involved in this example are showed below:
Left element (EA usecases) |
Last update |
Right element (JIRA issues) |
Last update |
|---|---|---|---|
usecase UC001 |
2010.02.01 10:00:00 |
issue MZ-1 |
2010.02.01 09:00:00 |
usecase UC002 |
2010.02.01 12:00:00 |
issue MZ-2 |
2010.02.01 11:00:00 |
usecase UC003 |
2010.02.01 14:00:00 |
issue MZ-3 |
2010.02.01 15:00:00 |
usecase UC004 |
2010.02.01 16:00:00 |
||
issue MZ-5 |
2010.02.01 17:00:00 |
Since many synchronization options (SyncOption) can be used, each configuration is covered below:
Using ADD configuration option in the right side (Jira issue), after the synchronization, the system hold these values:
Left element (EA usecases) |
Last update |
Right element (JIRA issues) |
Last update |
Comment |
|---|---|---|---|---|
usecase UC001 |
2010.02.01 10:00:00 |
issue MZ-1 |
2010.02.01 09:00:00 |
Jira issue untouched |
usecase UC002 |
2010.02.01 12:00:00 |
issue MZ-2 |
2010.02.01 11:00:00 |
Jira issue untouched |
usecase UC003 |
2010.02.01 14:00:00 |
issue MZ-3 |
2010.02.01 15:00:00 |
Jira issue untouched |
usecase UC004 |
2010.02.01 16:00:00 |
issue MZ-n |
current_time |
Jira issue created |
issue MZ-5 |
2010.02.01 17:00:00 |
Jira issue untouched |
Note 1: Since other issues may have been created in the interval, the term "n", in MZ-n refer a new sequence number in Jira repository. Dont worry about it, since Mizura uses a internal identifier (TODO, link to it) to synchronize elements.
Note 2: The signal "+" in timestamp column denotes that a right timestamp is, at least, greather than the left element timestamp, since synchronization always occurs over preexisting elements.
Using ADD_UPDATE configuration option in the right side (Jira issue), after the synchronization, the system hold these values:
Left element (EA usecases) |
Last update |
Right element (JIRA issues) |
Last update |
Comment |
|---|---|---|---|---|
usecase UC001 |
2010.02.01 10:00:00 |
issue MZ-1 |
current_time |
Jira issue fields updated |
usecase UC002 |
2010.02.01 12:00:00 |
issue MZ-2 |
current_time |
Jira issue fields updated |
usecase UC003 |
2010.02.01 14:00:00 |
issue MZ-3 |
current_time |
Jira issue fields updated |
usecase UC004 |
2010.02.01 16:00:00 |
issue MZ-n |
current_time |
Jira issue created |
issue MZ-5 |
2010.02.01 17:00:00 |
Jira issue untouched |
Using ADD_UPDATE_DELETE configuration option in the right side (Jira issue), after the synchronization, the system hold these values:
Left element (EA usecases) |
Last update |
Right element (JIRA issues) |
Last update |
Comment |
|---|---|---|---|---|
usecase UC001 |
2010.02.01 10:00:00 |
issue MZ-1 |
current_time |
Jira issue fields updated |
usecase UC002 |
2010.02.01 12:00:00 |
issue MZ-2 |
current_time |
Jira issue fields updated |
usecase UC003 |
2010.02.01 14:00:00 |
issue MZ-3 |
current_time |
Jira issue fields updated |
usecase UC004 |
2010.02.01 16:00:00 |
issue MZ-n |
current_time |
Jira issue created |
issue MZ-5 |
2010.02.01 17:00:00 |
Jira issue untouched |
Left element (EA usecases) |
Right element (JIRA issues) |
ADD |
ADD_UPDATE |
ADD_UPDATE_DELETE |
ADD_UPDATE_DELETEWITHPURGE |
|---|---|---|---|---|---|
usecase UC001 |
issue MZ-1 |
issue updated |
issue updated |
issue updated |
|
usecase UC002 |
issue MZ-2 |
issue updated |
issued updated |
issue updated |
|
usecase UC003 |
issue MZ-3 |
issue updated |
issued updated |
issue updated |
|
usecase UC004 |
issue MZ-n created |
issue MZ-n created |
issue MZ-n created |
issue MZ-n created |
|
issue MZ-5 |
None |
None |
None |
issue MZ-5 deleted |
|
x |
issue MZ-5 |
None |
None |
issue MZ-5 deleted |
issue MZ-5 deleted |