Connector vs Existing Office Project integration

Jun 26, 2007 at 1:18 PM
Dear Lenny,

I want to start another discussion about some missmatches I feel between new Connector and existing file integration.

Using Connector I definetely win with the following aspects:
- better integration and architecture
- direct link between TFS and PS projects

On the other hand the project file integration allows me:
- using fields mapping
- making more than 1 MS project plans for a TFS project

I am interesting if anybody faced the sames issue or have ever tried to combine this to approaches. In other words, how can I use new architecture (that I really like :) ) with all nice things.
::Mike
Coordinator
Jun 26, 2007 at 3:30 PM
These are the kinds of discussions I love :-)

Mike, the new connector uses field mappings as well. In fact, I dare so (although I am obviously biased) that the fieldmapping is a bit more extensible. The fieldmappings are maintained within the web.config file for the Connector Web Service. So, basic fieldmappings map a field in a TFS WorkItem to am assignment field within Project Server. OOB there is also a PSFieldMapping that you can use. This allows you to set a different PS entity than Assignment -- really Task and AssignmentCustomFields to be specific. Thus, you can add and map additional custom fields in your work item types and PS assignments than what you get out of the box. And since the FieldMappings are just provider based, you should be able to create your own and use those too. I don't; however, expect many folks to extend the connector in this way.

I do, however, expect that folks will extend the Connector by adding custom FieldMappingRules. As data moves back and forth between the two disparate systems, it usually needs to be modified in some way. For example, resource information is not stored the same way. The units of work are not stored the same way. This data needs to be modified as it is passed back and forth between the two systems. The Connector allows for pluggable providers to be 'snapped in' to the configuration that allows a company to create their own FieldMappingRules. Out of the box, you'll see rules to lookup and modify resource information, validate date fields, apply math formulas (e.g., for changing unit of work), and create 'lookup tables'. However, without modifying any of the code within the connector, you can create your own FieldMappingRules and plug those in as well. This is where I suspect most of the customization will be done as each customer may have different needs as data is passed back and forth. I'll be blogging much more about this in the next few weeks.

To your last point re: having an MS Project map to more than TFS Project, the only way to do that with the Connector now is to create your own PS2007 Provider. Yes, even the way that the Connector interacts with PS2007 is provider based, so theoretically, you should be able to create your own provider by deriving from the PS2007Provider and implementing your own logic. But that, of course, would not be trivial at all. Furthermore, there are a few others that are asking for a features similar to this (e.g., remove 1:1 need b/w PS server and TSF server) so it may be something that is considered for future releases.

HTH. Looking forward to your further discussion on this.

Lenny
Jun 27, 2007 at 11:32 AM
Edited Jun 27, 2007 at 12:57 PM
Lenny,

Thank you for the detailed response. The field mapping posibility is really great. Also, maping rules is something I lack at the moment. The only problem is that I did not find much documentation about these features. Where can I find anything about using them?

I also found another issue I'd like to disscus there . It is about a scenario of reassigning work Item in TFS which makes no changes in Project. I see the problem with it and think that it was done on purpose, but if you have any additional information on it as well as other synchronization scenarios behavior and limitation it would be great to see them.

As for existing architacture, I have a question about the 1:1 link between assignment and work item. Let's imagine task "Create architecture" and 3-5 guys assigned to it. In that case in TFS we will have the 3-5 different tasks with different history and the same name. May you evaluate the possibility of making the 1:many relationship (actually, I am sure you did it, I just don't know it) between task in TFS and assighment in PS. This may also may also help with described scenario (each time I reassign the task - new assignment in PS is created if the user was not assighed before, of course).

::Mike
Coordinator
Jun 27, 2007 at 12:03 PM
I know documentation is very sparse right now. I am working on documenting the features and ability to extend the Connector over the next few weeks. Right now, I am resolving a few bugs which have surfaced.

Speaking of which, one of the ones that I am resolving right now involves reassigning work in TFS to a new member of the team or even a member of the team that currently has no assignments. I expect to have this resolved shortly. Is that the issue you are seeing?

Thanks,
Lenny
Jun 27, 2007 at 12:59 PM
Edited Jun 27, 2007 at 1:11 PM
Lenny,

After additional estimation I have updated my previous post (at almost the same time you have made yours:)). Have a look at my additions if they can make any difference.

::Mike
Coordinator
Jun 27, 2007 at 1:31 PM
Mike,

Many people use the term task and assignment to mean the same thing in PS. However, they are not. A task has many assignments -- each assignment is associated with a specific resource. In the scenario you provided above there will actually be an assignment for every workitem in TFS. The reason for this is exactly for the scenario to which you are alluding --- assignments are the most granular level to which can be assigned within PS; workitems are the most granular level to which work is assigned within TFS. That is why the mappings are between assignments (not tasks!) and workitems.

Does this help?

Lenny
Jun 27, 2007 at 2:39 PM
Lenny,

This help in terms that you have the same feeling as I :) (actually vice versa, of course).
My collegues get the same conclusion. And architecture is really clever. Yes I argee, even more, the good PM in most cases should have 1 task assighment per person and your tool made some limitation to base this approach.

The most problem we have with a bug or task life cycle scenario. So if I receive the bug, fix it - it renurns to activator. Later in PS it will result in another task/bug or just nothing which is not really efficient. Have you evaluate this workflow, which is more or less standard for many process templates (CMMI, Agile)

::Mike
Coordinator
Jun 27, 2007 at 3:50 PM
Mike,

I am not really sure what you are asking here. The bug workitem type should function similarly to the task workitemtype -- the only difference are the fields that are mapped because some of the fields (like completed/remaining work) do not exist for the OOB bug workitemtype in TFS.

Can you elaborate more on the issue you are having?

Thanks,
Lenny
Jul 2, 2007 at 6:37 AM
Edited Jul 2, 2007 at 6:50 AM
Lenny,

Sorry for foggy description. I understood that the bug will behave similar to other work items. The question is how the system will/should react on the basis bag scenatio, like Bag is assigned to resource B by resource C, resource B reassign in to resource D, then D fixes the bag and it will be assigned back to B or C. How the Connected will treat this scenario? Can you suggest the most appropriate synchronization set up for the process with similar scenario.

You may find the same issue if you look at the Task work item. It has four states by default (Active, Closed, Proposed, Resolved). So I can see the same problem. Task is assigned to resource B by resource C, resource B reassign in to resource D, then D resolves the task and it will be assigned back to B or C for approval.

I still think you can evaluate 1:many relationship proposal (I have some internal vision if it can make you interested) for some or even all scenarios, otherwise just describe how can I work effeciently within the described scenarios.

Thank you in advance.

::Mike
Coordinator
Jul 2, 2007 at 12:58 PM
Thanks, Mike. That does clear things up a little.

The connector doesn't hook into any of the "workflow" events that might occur on either server. That is, it does not know that work has been reassigned, per se. It does know; however, that an assignment or work item has changed in some way and because the resource fields are part of the field mappings it evaluates the relevant fields for change. So, it will use whatever rules are configured in the mappings to determine what the changed valve should be in the other system. For example, for a task, the OOB mapping is to map State in TFS to Heath in PS while still mapping AssignedTo to RES_UID. But one field's valve, OOB, is not affectinganother. It wold be easy to create aField mapping Rule that does though and plug thisin instead. Does this make sense?

I know this may be a bit unclear right nows am currently witty documentation to try to make this clearer.

HTH,
Lenny
Jul 3, 2007 at 8:01 AM
Lenny,

Thank you for the detailed response. I really hope that an ad hoc documentation will solve most of the problems, especially description for the mapping rules usage.
At the same time, I still belive that you may consider the reassign scenario from TFS or see if you can contradict to my vision.

My ideal workflows will be as follows:
- when I create several assignments for a task on PS side it really should result in creating several tasks in TFS, as this mean parallel work (work)
- when I create a new assignment in PS it results in new work item in TFS, the same parallel work is implied (work)
- (most difficult) when I reassign task in PS I expect that my TFS workitem is also reassigned, irrespective of creating a new assignment in PS, as for me it is still same task just another resource will work on it (do not work)
- (most difficult) when I reassign work item in TFS I expect the standard reassign action for the same item in PS, no new WI are created (do not work)

Last two workflows will require some kind of 1:many relation, plus if WI is changed in TFS the system should take the Assigned To resource and update its assignments in PS. I can see the possible solution by using the AutoSync field. As you added this field to task and assignment, you may treat:
- PS task <> TFS WI as 1:many relation (new relation)
- PS assignment <> TFS WI as 1:1 (existing relation)

Also, quite often aften doing it the project was blocked (checked-out on the server be service account) with the status Blocked Due To A Failed Job. After that the project association is also blocked.

Look forward to hearing from you soon.

::Mike
Coordinator
Jul 3, 2007 at 12:31 PM
I'll answer one by one --
1) (most difficult) when I reassign task in PS I expect that my TFS workitem is also reassigned, irrespective of creating a new assignment in PS, as for me it is still same task just another resource will work on it
This should be working for you. However, you may need a hotfix that we are working with the Office team on. The Connector does its best to match up the assignment with the task and simply reassign the work -- it gets a bit more muddy though when there are several assignments for a task, because Project actually doesn't see a 'reassignment' the same way the TFS does -- it sees it as a completely new assignment and deletes the previous one. Having said that, we realized that this is not the way that people expect it to work so there is a bunch of logic that should help with with the reassignment. There are some bug fixes related to this that will be available this week, but like I said, if you are still having issues after that we may need to work with you more and have you try out the hotfix (that wont be available until later this year).
- when I reassign work item in TFS I expect the standard reassign action for the same item in PS, no new WI are created (do not work)
There was a bug here. It should be fixed in the release later this week.

No need for 1:n workflow fo rthese scenarios -- simply needed to do some more work around how resources are added and delegated within Project Server. It's not well documented and the wrong field was being populated in the DataSet that gets passed to the DelegateAssignments method.

Hope this helps.
Lenny
Jul 5, 2007 at 6:57 AM
Lenny,

Thank you for the information. Acoording to your response, I think I need to wait for the latest fixes and updated whitepapers. Do you have any dates when these things will be available?
Also, I have another question - while I am creating a new project in TFS I noticed 2 new templates, but they are not accessible. Can you clarify what for may I need them and should they be accessible?

::Mike
Coordinator
Jul 5, 2007 at 1:15 PM
Should be released next week at the latest. The documentation will probably be the end of the month.

They are supposed to be accessible to you. What problem are you having accessing them?

HTH,
Lenny