It's all about the answers!

Ask a question

Using Item Connector Framework


Ankur Sharma (151194) | asked Oct 21 '08, 8:59 a.m.
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 Jazz to External repository (NOT from External repository to jazz), the synchronization process can be started either explicitly or after a fixed interval of time. Is there any other other way to invoke synchronization process e.g. on the basis of event etc. (as this can done while synchronizing from external repository to Jazz).

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



permanent link
megha mittal (15112615) | answered Oct 06 '09, 8:16 a.m.
Hi,
I am back with some queries on item connector.I am working on outgoing synchronization part of external repository connection.

Firstly, Is there any way i can display my connector failure messages in "synchronization status" page in the column "last synchronization attempt" ?
I generally find the page very helpful as it tell me about conflict and other messages , but can i customize the messages to tell more detail reason as to why the update or create action failed. I currently display them in logs.

Secondly , My external repository (CMVC) has some processes configured ,because of which defect state varies in CMVC.
Like if "verify subprocess" exist defect state will be open->working->verify-> closed
and if no "verify subprocess" state will be open->working-> closed Now in my sync rule my mapping is as follows
New= Open
In progress= working
resolve= verify

verify= closed

I dont want to chnage my sync rule with processes on CMVC side .So now if my CMVC defect doesnt have "verify subprocess" and user move defect from "In progress" to " resolve".CMVC will move defect from "working" to " close"

and synchronization status will show me conflict becuase "closed" state is not mapped to "resolve".

Is there any way to resolve the issue beside adding new mapping of "Resolve= closed "in sync rule.

However incoming synchronization when triggered with move RTC state to "verified" which can resolve conflict but till then WI status will be "conflict".

what is the right way to handle such situations.

permanent link
John Vasta (2.6k15) | answered Oct 06 '09, 10:45 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
The error messages from any exceptions thrown by a manager method are captured and included in the "last synchronization attempt" info, so you should just be able to throw exceptions with the messages you want to see.

I can't think of any way to handle your state mapping issue other than to write your own value transformer, which would somehow have to determine what kind of CMVC process is in use, and therefore decide whether "resolve" should map to "verify" or "closed.

Hi,
I am back with some queries on item connector.I am working on outgoing synchronization part of external repository connection.

Firstly, Is there any way i can display my connector failure messages in "synchronization status" page in the column "last synchronization attempt" ?
I generally find the page very helpful as it tell me about conflict and other messages , but can i customize the messages to tell more detail reason as to why the update or create action failed. I currently display them in logs.

Secondly , My external repository (CMVC) has some processes configured ,because of which defect state varies in CMVC.
Like if "verify subprocess" exist defect state will be open->working->verify-> closed
and if no "verify subprocess" state will be open->working-> closed Now in my sync rule my mapping is as follows
New= Open
In progress= working
resolve= verify

verify= closed

I dont want to chnage my sync rule with processes on CMVC side .So now if my CMVC defect doesnt have "verify subprocess" and user move defect from "In progress" to " resolve".CMVC will move defect from "working" to " close"

and synchronization status will show me conflict becuase "closed" state is not mapped to "resolve".

Is there any way to resolve the issue beside adding new mapping of "Resolve= closed "in sync rule.

However incoming synchronization when triggered with move RTC state to "verified" which can resolve conflict but till then WI status will be "conflict".

what is the right way to handle such situations.

permanent link
megha mittal (15112615) | answered Nov 19 '09, 7:07 a.m.
Hi John,
I am back with some more queries.As per item connector framework on jazz,net , we have created a seperate java application for incoming(CMVC-RTC) with calls the following method
interopmanager.synchronizeIncomingAndWait()
for all its updates from CMVC.And a server plugin for outgoing(RTC->CMVC).
As per our current design both these applications dont interact directly with each other and have different polling time.
The missing part here is that we dont have any common point of interaction for both incoming and outgoing, so we dont have any means to know that the CMVC update, incoming connector recieves is from RTC or CMVC .So currently we pick last update from CMVC and compare the state with that of RTC and do the needfull.
Now the problem we are facing is that when RTC is sending some sequence of updates to CMVC , and in between the incoming wakes up and poll CMVC and start synchronizing the updates from CMVC to RTC. ( RTC has not completed its updates yet).This causes some unexpected errors and situations.
Is there any other way to make incoming and outgoing work in synchronized way i.e outgoing can notify incoming when done with its updates.

permanent link
John Vasta (2.6k15) | answered Nov 19 '09, 10:07 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
The short answer is, no, I don't think there is any way to coordinate the incoming and outgoing synchronization processes, since as you say, they are being driven by two different applications.

I'm wondering why you're calling the synchronizeIncomingAndWait method. Normally, external connector clients wouldn't do that; it's not mentioned in the connector development wiki page. Synchronization is automatically triggered whenever an ExternalState item is saved, so calling a "synchronize" method would trigger an additional synchronization operation on the last-synced-in ExternalState item. The synchronize methods exist in the API mainly for the Synchronization Status GUI, to implement the "retry" operations.

Also, both incoming and outgoing synchronization operations are queued for a particular item. In other words, they run serially, not in parallel. So if outgoing synchronization is occurring for some work item, and incoming data is received for that item, it is added to a queue of pending synchronization operations for that item, rather than immediately executed. So I'm not sure whether the fact that the incoming and outgoing synchronization processes are uncoordinated is really the source of any problems you're seeing. It might be better to see exactly what the problems are.

Hi John,
I am back with some more queries.As per item connector framework on jazz,net , we have created a seperate java application for incoming(CMVC-RTC) with calls the following method
interopmanager.synchronizeIncomingAndWait()
for all its updates from CMVC.And a server plugin for outgoing(RTC->CMVC).
As per our current design both these applications dont interact directly with each other and have different polling time.
The missing part here is that we dont have any common point of interaction for both incoming and outgoing, so we dont have any means to know that the CMVC update, incoming connector recieves is from RTC or CMVC .So currently we pick last update from CMVC and compare the state with that of RTC and do the needfull.
Now the problem we are facing is that when RTC is sending some sequence of updates to CMVC , and in between the incoming wakes up and poll CMVC and start synchronizing the updates from CMVC to RTC. ( RTC has not completed its updates yet).This causes some unexpected errors and situations.
Is there any other way to make incoming and outgoing work in synchronized way i.e outgoing can notify incoming when done with its updates.

permanent link
megha mittal (15112615) | answered Nov 20 '09, 7:01 a.m.
Yes i guess there is some design issue which is creating these type of problems for us.
Why external client used 'synchronizeIncomingAndWait' even i am not sure because the person did the coding for external client has left organization.
From your reply what i got to know that for incoming (CMVC->RTC) client should do the following:
1) Poll external repository(CMVC) after every specific period of time .
2) Do 'interopManager.saveExternalState()'
and this is add the updates from CMVC in a queue and both incoming and outgoing will execute this queue serially.
Correct me if i have missed something in above steps.

So if this is the way incoming client should work , my concern is that 'saveExternalState()' operation should be done only for updates from CMVC? What about the updates that are done from RTC and CMVC polling mechanishm has picked them up because of lack of incoming supression code?


Thanks in advance for your most needed and valuable support.

permanent link
John Vasta (2.6k15) | answered Nov 23 '09, 8:54 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
So if this is the way incoming client should work , my concern is that 'saveExternalState()' operation should be done only for updates from CMVC? What about the updates that are done from RTC and CMVC polling mechanishm has picked them up because of lack of incoming supression code?


In general, you shouldn't need to suppress incoming synchronization for updates that were caused by outgoing synchronization. In fact, if it is possible that the act of applying the outgoing changes will cause additional changes, then you would want those changes sent back in to RTC anyway. For example, in ClearQuest, hooks can fire whenever a record is modified, and those hooks can make further changes to the record. Theoretically, if nothing like that happens, so that the external record is in an equivalent state to the work item, then syncing the external state back in to RTC should be a no-op.

There is one caveat, however. If it is possible for the external system to sync in changes out of order, then newer states could be overwritten by older states. This is discussed in the wiki page at

https://jazz.net/wiki/bin/view/Main/ItemConnectorCreation#Guarding_against_data_overwrites

For example, ClearQuest records each have a version number that gets incremented on every commit. The CQ Connector includes that version number in the incoming data, and whenever it is about to send in some changes, it checks that the version number for the new changes is greater than the version number of the most recent state that has been synced in. If not, it doesn't send in the changes.

permanent link
megha mittal (15112615) | answered Nov 24 '09, 2:53 a.m.
Yes in our case the act of applying any RTC update in CMVC ,cause some additional changes in CMVC item .For example when we modify "Abstract" in RTC CMVC 'summary' filed is modified and it also add a remark to that item telling about the old summary and new summary.
But in our current code we get those changes back in RTC through the 'returnedState' parameter of "updateState()" , i passed on the new state of CMVC item(With all the attributes) in "returnedState" parameter after my update was successfull and the changes are reflected to me in the RTC gui.
So in this case item connector client was not even called and CMVC item's new state is reflected back in RTC.

Now in continuation with above example ,in the absence of incoming supression ,incoming connector client will poll CMVC for updates (it will find modified 'summary' and 'remark')and will save them to external state. What will happen to these updates now?

Is this the situation when version number concept will be used to prevent these changes to be processed again?

Also about the caveat , its not problem in our case since item connetcor client will pick updates from CMVC in order only, as it queries CMVC server directlty for updates after end of polling interval.

Thanks a lot in advance for your support.

permanent link
John Vasta (2.6k15) | answered Nov 24 '09, 7:19 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
Now in continuation with above example ,in the absence of incoming supression ,incoming connector client will poll CMVC for updates (it will find modified 'summary' and 'remark')and will save them to external state. What will happen to these updates now?

Is this the situation when version number concept will be used to prevent these changes to be processed again?


The redundant incoming data should be a no-op; whenever a new state of an ExternalState item is created, it is compared with the previously-synchronized state, and if there are no differences, then no changes are applied to the connected Jazz item (e.g. work item). The CQ Connector doesn't suppress redundant updates, and that hasn't caused any problems.

Again, it would be easier to determine what's going on if you provide the details of any problems you're observing (error messages, debug traces, etc.) Feel free to email me that information directly.

permanent link
megha mittal (15112615) | answered May 31 '11, 8:15 a.m.
I have a query related to behavior of getState method of external repository manager .As per link
https://jazz.net/wiki/bin/view/Main/ItemConnectorCreation#Introduction
this method is optional and used if we want to avoid conflict.So we have done implementation of this method in our External repository manager.
But this method is creating problem for us in some cases.

Like we have done a transition(Say 1) in external repository and it is pushed in RTC(say 1)
Now 3 more transitions(say 2-> 3-> 4) are done in external repository and since our incoming client code is on periodic basis it polls external repository and process these updates one by one .Meanwhile getState is getting called and it tries to compares the final state of external repository (i.e 4) with RTC current state and tries to move the state in RTC. (from 1 ->4).This results in loss of history ( 2, 3) or at times extra state transition on RTC since incoming is still doing processing .(say 1->4-> 2-> 3->4).
how to stop this extra transition done by getState (1->4).


Thanks
Megha

Now in continuation with above example ,in the absence of incoming supression ,incoming connector client will poll CMVC for updates (it will find modified 'summary' and 'remark')and will save them to external state. What will happen to these updates now?

Is this the situation when version number concept will be used to prevent these changes to be processed again?


The redundant incoming data should be a no-op; whenever a new state of an ExternalState item is created, it is compared with the previously-synchronized state, and if there are no differences, then no changes are applied to the connected Jazz item (e.g. work item). The CQ Connector doesn't suppress redundant updates, and that hasn't caused any problems.

Again, it would be easier to determine what's going on if you provide the details of any problems you're observing (error messages, debug traces, etc.) Feel free to email me that information directly.

permanent link
John Vasta (2.6k15) | answered Jun 02 '11, 3:27 p.m.
FORUM MODERATOR / JAZZ DEVELOPER
I don't think there is a way to avoid this skipping of external states that can happen when the getState() method is implemented. I looked to see how the CQ synchronizer handles this. The same thing will happen; if a work item is in state 1 and a CQ record is in state 4, and outgoing sync is triggered on the work item, state 4 will be pulled in from CQ and applied to the work item. That may or may not succeed, depending on whether the 1 -> 4 transition is allowed in the work item workflow. Note that if it does succeed, because the CQ manager guards against data overwrites (according to https://jazz.net/wiki/bin/view/Main/ItemConnectorCreation#Incoming_data_overwrites), there won't be a problem when incoming sync runs, since it will be noticed that state 4 is already synced in, so it won't try to sync in states 2 and 3. Those states will be missing in the work item history, but both the CQ record and the work item will end up synchronized (in state 4).

I have a query related to behavior of getState method of external repository manager .As per link
https://jazz.net/wiki/bin/view/Main/ItemConnectorCreation#Introduction
this method is optional and used if we want to avoid conflict.So we have done implementation of this method in our External repository manager.
But this method is creating problem for us in some cases.

Like we have done a transition(Say 1) in external repository and it is pushed in RTC(say 1)
Now 3 more transitions(say 2-> 3-> 4) are done in external repository and since our incoming client code is on periodic basis it polls external repository and process these updates one by one .Meanwhile getState is getting called and it tries to compares the final state of external repository (i.e 4) with RTC current state and tries to move the state in RTC. (from 1 ->4).This results in loss of history ( 2, 3) or at times extra state transition on RTC since incoming is still doing processing .(say 1->4-> 2-> 3->4).
how to stop this extra transition done by getState (1->4).


Thanks
Megha

Now in continuation with above example ,in the absence of incoming supression ,incoming connector client will poll CMVC for updates (it will find modified 'summary' and 'remark')and will save them to external state. What will happen to these updates now?

Is this the situation when version number concept will be used to prevent these changes to be processed again?


The redundant incoming data should be a no-op; whenever a new state of an ExternalState item is created, it is compared with the previously-synchronized state, and if there are no differences, then no changes are applied to the connected Jazz item (e.g. work item). The CQ Connector doesn't suppress redundant updates, and that hasn't caused any problems.

Again, it would be easier to determine what's going on if you provide the details of any problems you're observing (error messages, debug traces, etc.) Feel free to email me that information directly.

Your answer


Register or to post 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.