It's all about the answers!

Ask a question

connector problem


sam detweiler (12.5k6189201) | asked Oct 10 '10, 9:34 a.m.
Thanks to the workshop document, I have a working system with my connector running.

I am now encountering problems that I don't know how to resolve.

1. I set the user in the workitem to be remotely synched, with a separate sync rule.. that does in fact drive my connector, ya!..
but.. once 'successful', the user is added to the Jazz user DB and my connector is never called again.. or at least I haven't found the condition to do it..

anyhow, I don't really have a problem with that. but.. I need to retest my connector now that I have remote connection working and the user is now added to the DB with no way to remove them

advice please..

altho people DO leave the company, and their ID should be removed (not just archived)..

2. I have a workitem that I forced into synchronized state,
(from the unsynchronized status list, open item, and redo the outgoing/incoming synch)
and now the web UI causes the jazz server to crash..
how can I clean this up?

Sam

13 answers



permanent link
sam detweiler (12.5k6189201) | answered Oct 11 '10, 12:36 p.m.
also a few more questions..

1. when updateState is called, WHAT is changing?

the prior, new and returned states are interesting but
and the list of properties

all seem to indicate EVERY/ANYTHING might have changed and I HAVE to figure it out..

I added comments to the workitem thru the web ui, forced a sync thru the sync rule, and got calls at updatestate() as expected..
but I get called 5 times for this same workitem.. I did say 'all workitems related to this connector'..

but I can't tell any difference on the 5 calls.

also, is there a way to get the workitem number that was just created, and I am processing at the updatestate() call?
I wanted to sync the workitem number back to the ticket system for tracking.. same problem with the workitem inside RTC.. I can't tell from looking at it what the source problem item is.. altho it is connected, there is no easy way for humans to talk about this on the phone, or to build reports that show the linkages.

I am also still in need of info on the attachment input format.
I want to use URL links all the time, no actual file movement
as many are huge (gigabytes) and don't need to be copied or replicated.

and then on the comments/attachment process..

I want to push JUST the new comment/attachment to the work item. but I am unsure what happens if I do a workitem update with the only property of comment, and only one present.. vs all that were there prior..

I downloaded the cq connector and the source is so convoluted I am having a hard time following what is going on.

Sam

permanent link
sam detweiler (12.5k6189201) | answered Oct 28 '10, 2:21 p.m.
still need help

permanent link
sam detweiler (12.5k6189201) | answered Nov 16 '10, 9:51 p.m.
I've answered almost all my questions here

users are added, never deleted.
when updateState() is called, all properties are provided. it is up to the implementation to decide what and how to distinguish the changes.

comments follow the CW connector format
user==username_string!FIELD!text==note text data!NOTE_ENTRY!

repeat with them all concatentated together. there is no date info provided or accepted.

attachment format is similar..

still working on solutions for comments and attachments according to our business processes.

Sam

permanent link
sam detweiler (12.5k6189201) | answered Feb 13 '11, 9:46 a.m.
actually, after all this time, I have to report I was wrong..

when updateState() is called, there are 4 important parameters

Map newState
Map lastState
Map returnedState
List propertyNames

I've just found a longstanding issue with my code..

newState is NOT a state...!!. it is a set of CHANGED properties, and ONLY the changes.

propertyNames contains the list of ALL the properties for this item (depends on what this manager is processing for), and only applies to the lastState map.

So, the mechanism is

create a new state in returnedState, that combines lastState
and the changed properties.

I do this by

1. copying the lastState map properties to returnedState map
oh if java had good assignment operator support
2. process the properties in newState, and apply them to returnedState map.

I think the abstract class definition for the parameters to updateState() should be changed to reflect the facts..

newState -> changedProperties
propertyNames -> propertyNamesAll

sam

permanent link
John Vasta (2.6k15) | answered Feb 15 '11, 10:29 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
The documentation for the external manager interface is in the Java specification of the interface, which is com.ibm.team.interop.service.IInteropExternalManager (which extends com.ibm.team.interop.service.IInteropRepositoryManager, and therefore which is also part of the specified interface.) For example, this is the documentation for the updateState method:


/**
* Update the state of an external object in its repository. If the update
* succeeds, return the saved state. If it fails because the external
* object was independently modified, then return the current state of the
* object.
* <p>
* Only modified properties are included in the <code>newState</code>
* map. Since repositories may alter the values of properties when they are
* saved, the actual, post-save values of the properties should be returned
* in the <code>returnedState</code> map. The Interop service will then
* schedule incoming synchronization with that state. All properties that
* have changed as a result of the save should be returned.
* <p>
* It's possible that the properties in <code>newState</code> are based on
* an older copy of the external properties than what actually exists in the
* repository (known as a "stale data" condition). In that case, if the
* repository can detect such a situation and prevent the overwrite, this
* method should return false. It is the external repository's responsibility
* to send in the latest state at some point. Until then, the sync status
* of the proxy will be PENDING.
* <p>
* If the object cannot be updated for some reason other than "stale data",
* then this method should throw some kind of runtime exception. Any message
* text in the exception will be stored in the proxy.
*
* @since 0.6
*
* @param typeName
* the type name of the external object, if specified by the
* synchronization rule being used, or <code>null</code> if no type
* name specified. (The type name may be inferable, or there may be
* only one type supported by a manager, so this argument is optional.)
* @param uri
* the URI of the external object
* @param newState
* the properties to modify for the object
* @param lastState
* the most recently received state for the external object, if any,
* or <code>null</code> if there isn't any
* @param returnedState
* the current state of the object, either after it has been saved,
* or if the save failed because the object was independently
* modified
* @param propertyNames
* the names of properties that should be returned in the returnedState
* argument
* @param externalConnection
* the external connection being used by the synchronization rule,
* if any; provided for contacting the external repository or for
* obtaining any properties of the connection specific to this manager;
* may be <code>null</code>
* @param processArea
* any process area associated either with the connected Jazz item,
* if known, or the synchronization rule being used.
* Provided for the external manager to use as an indication of the
* "source" of an item, in case it supports multiple Jazz connections
* to a single external object and needs to distinguish them somehow.
* @return
* <code>true</code> if the external object was successfully updated;
* <code>false</code> if the update failed due to a "stale data"
* condition
* @throws RuntimeException for an error other than "stale data"
*/


actually, after all this time, I have to report I was wrong..

when updateState() is called, there are 4 important parameters

Map newState
Map lastState
Map returnedState
List propertyNames

I've just found a longstanding issue with my code..

newState is NOT a state...!!. it is a set of CHANGED properties, and ONLY the changes.

propertyNames contains the list of ALL the properties for this item (depends on what this manager is processing for), and only applies to the lastState map.

So, the mechanism is

create a new state in returnedState, that combines lastState
and the changed properties.

I do this by

1. copying the lastState map properties to returnedState map
oh if java had good assignment operator support
2. process the properties in newState, and apply them to returnedState map.

I think the abstract class definition for the parameters to updateState() should be changed to reflect the facts..

newState -> changedProperties
propertyNames -> propertyNamesAll

sam

permanent link
sam detweiler (12.5k6189201) | answered Feb 16 '11, 10:06 a.m.
The documentation for the external manager interface is in the Java specification of the interface, which is com.ibm.team.interop.service.IInteropExternalManager (which extends com.ibm.team.interop.service.IInteropRepositoryManager, and therefore which is also part of the specified interface.) For example, this is the documentation for the updateState method:




nice. where do you find that? I have never seen that anywhere
not in the source of the base class, I don't see a doc folder...

I would have saved a ton of time if that was somewhere easily findable..

Sam

permanent link
sam detweiler (12.5k6189201) | answered Feb 16 '11, 10:16 a.m.
thinking thru the recovery design..

followon question.

if for some reason I cannot connect or complete the syncronization with my repository, and return false from the updateState() method.. will this be retried at a later time?

or will changes be accumulated, and subsequent updateState() calls made to push the changes..

I 'think' I am seeing the latter..
unless 'Synchronize all item states' is enabled in the synch rule

thanks

Sam

permanent link
John Vasta (2.6k15) | answered Feb 17 '11, 9:24 a.m.
FORUM MODERATOR / JAZZ DEVELOPER

nice. where do you find that? I have never seen that anywhere
not in the source of the base class, I don't see a doc folder...


All of the interface files are in the RTC source package. Since you have to implement those interfaces, I highly recommend reading their documentation. The wiki page https://jazz.net/wiki/bin/view/Main/ItemConnectorDevelopmentSetup describes how to set up your development environment to have the source available in your IDE.


if for some reason I cannot connect or complete the syncronization with my repository, and return false from the updateState() method.. will this be retried at a later time?


There is no automatic retry; if the connected Jazz item (e.g. work item) is modified later, then outgoing sync will be triggered again. If the sync rule has 'Synchronize all item states' checked, then the updateState method will be called for each state of the Jazz item created since the last state that was successfully synced out. If not checked, then updateState will be called once, with the supplied properties being the delta between the current state and the last-synced-out state.

permanent link
sam detweiler (12.5k6189201) | answered Feb 17 '11, 9:39 a.m.
>There is no automatic retry; if the connected Jazz item (e.g. work item) is modified later, then outgoing sync will be triggered again

yeh.. thats the problem I am looking at..

the RTC user made a change, the outgoing synch failed due to server unavailbility, and altho the synctime is set to 60 seconds, this update will not be resent..

the reason for the update was to ask the owner on the remote side to do some work (contact the customer for some data, that could take days) but the message never arrived.. (all of you that can't hear me please raise your hand!)..

one would think that the workitem synch status is still outgoing pending, and this would then retry at the next sync interval. (with either accumulated properties or indicidual state
changes)

the question is, is there another exit from update state,
true, false, or throw error)

Sam

permanent link
sam detweiler (12.5k6189201) | answered Feb 17 '11, 10:05 a.m.
and as for setup.. I have all the V3 sdk source, but for the life of me I cannot find the abstract class my repository manager is derived from.. none of the folder/file names line up.

sam

http://i427.photobucket.com/albums/pp351/sdetweil/rtcsource.jpg

Your answer


Register or to post your answer.