Using Item Connector Framework
Hi
We are using Item connector framework for making connector for our defect tracking system. I have a few queries regarding Item connector framework.(https://jazz.net/wiki/bin/view/Main/ItemConnectorCreation) The following are the queires: 1. In Item connector client, there are two implementation choices : as a 'plain java application' or as an 'eclipse plug-in'. Which of these two implementations we should follow? Any idea how is it done in CQ connector ? Note that as per jazz tutorial it is recommended that we should go for 'java application' implementation. 2. While synchronizing from 3. We are not able to find javadoc/code for 'Jazz Plain Java Client libraries'. It would be helpful if we can have some link for it. Regards Ankur Sharma |
47 answers
|
Our external system does use LDAP and jazz will also use LDAP. Also in our case, users will use Jazz in almost all the cases rather than external system once connector is deployed, so all the external users need login access to jazz server.
So If I understand well, all the users will be created manually in Jazz first, give them proper permissions, add them to required team areas. Now user synchronization will create proxies regarding these already exiting users in jazz and subsequently will synchronize any changes in user information. But In case if there is some user which is not found in jazz server but was there in external system, the user synchronization will not be able to create the new user data in jazz. Also in case of "external modifier", item connector can override earlier configured permissions to that user role and extra required permissions will be granted to that role. I want your comments on my understanding. Anything extra which we can take advantage of the fact that both jazz and external system uses same LDAP ? -Ankur |
That's not quite right; the new user data will be created in Jazz, but it won't be created in your LDAP registry, so that user will not be able to login to Jazz.
No, not at all; the connector never changes anything having to do with roles or permissions. An "external modifier" property means that the property value identifies a Jazz user, and the connector should execute incoming synchronization under the identity of that user, rather than the identity that the external connector client logs in as. Essentially, it impersonates that user so that the same user that modified an external object is recorded as the user that modified the Jazz object, and that user's role is used to determine whether the Jazz object can be modified (according to your process permissions scheme).
I can't think of anything extra. |
|
Hi John,
As in case of Defect work items, we can find in 'external connection' synchronization status link, which can be opened and verified that a defect is linked to some external defect and what synchronization status it has. But I couldn't find anything similar for 'User'. Basically how can I verify that any particular user is linked to some external user or not ? -Ankur |
|
There is no direct way to see the connection between items other than work items, and external objects. You can indirectly see the connection between a Jazz Contributor item and an external object by opening the synchronization status for a work item that references the Contributor item in some property that is being synchronized (e.g. "Created By" or "Owned By"), and see that there is a corresponding external value for that property.
Feel free to submit an enhancement request, if you'd like. Hi John, |
|
Hi John,
I am facing a strange exception while testing my code on our remote server. Everything worked fine on local server but on remote server its giving me this exception Jazz Team Repository Exception: 'Synchronize with External Objects' failed. Permission denied. Though I have given all the required permission to the user who is running sync process. Also I am not using 'modifiedBy' parameter. So is this some 'weird' error due to connector framework or I am somewhere wrong ? Can somehow user mapping lead to this kind of exception because previously I haven't face such problem on other remote servers. Infact I am able to successfully run the incoming sync for 'user' workitem with same set of permission, user, projectArea, this exception is coming for only 'defect' workitem. -Ankur |
|
Hi John
I did some more homework on this problem and I found that this issue is 'Server' specific, because same code is running fine with another remote server. But still if you can give some hint why the problem is on this particular server, that would be helpful. -Ankur |
|
Well, this is pretty much what it says - the user identity that is trying to initiate incoming synchronization does not have the permission to do so, in the project area containing the synchronization rules. That user must be a member of the project area, assigned a process role that has been granted the needed permissions in the Team Configuration area of the project area configuration.
Hi John |
|
No the actual problem is something different. As I told earlier, I have given all the required permissions to the sync process user. Actually the problem occurs whenever we deploy the external repository manager on the server. Somehow there is a mismatch between external repository manager plugin versions and server version, which in turn is causing these license issues.
-Ankur |
|
Hi John
While synchronizing users, some of the users are not getting synchronization status OK but instead they are getting synchronization status 'Uninitialized'. What does this status means and how I can make it OK status ? -Ankur |
|
The Uninitialized status means that a proxy was created in Jazz for an external object, but no data for it has been synchronized. If your client created the proxy objects, you'll have to investigate why it didn't synchronize in any data. If you open the synchronization status, are there any error messages?
Hi John |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.