Working with Multiple Framework Developers

[Opher]

Hello - I'm stumped over how to get multiple developers working in FM.Ã,  Perhaps someone out there has already worked this out, or maybe we can compare experiences and find a working solution.

Here's the scenario:Ã,  We have a large data warehouse, which will inherit dozens of new tables over the next 10 months as new in-house development rolls online.Ã,  Having one FM Project that contains the whole environment will create too large a bottle-neck:Ã,  We have IQDs to build, reporting requirements to meet, etc.

What I would like to do is have a project which contains the physical layer and first-generation business view of each table (with names made user-friendly, default formats, default prompting, etc defined) and then have multiple developers "pull" from this project whatever tables are needed for what they are working on.Ã,  So the Product table would be defined once in the "master project" with nice field names, dimensionality, descriptions, etc.Ã,  Then as each developer requires the Product table, they pull it from the 'master project'.

Here's where the problem(s) start(s):Ã,  If you use a SEGMENT to create the Product Table the segment becomes a whole new Project.Ã,  Too much overhead, and the next problem occurs as well.Ã,  This next problem is that when you LINK (you can link a Segment or any Container) any edits made are bi-directional:Ã,  If you change the source it is pushed to the 'link' - which is what I want...but if you change the LINK it is driven back down to the source!Ã,  This means that if seven links to Product exist, if someone makes a change in one of those child Projects all of them will be affected.

Not only that, but have you taken a look at the metadata/properties of a link in FM?Ã,  You can't...there is a chain link icon on the object, but the properties shows nothing.Ã,  It is buried deep in the XML and is coded so you cannot just read it out of the file.Ã,  It is obvious that FM knows what is linked to what, but there are no reports of this and no way to do any impact analysis.

The next hurdle in multiple developer environments would be to have a naming convention.Ã,  Does anyone have a starting point for one?Ã,  It will need to address some of the base weaknesses of the FM -> Package -> ReportNet design.Ã,  For example, if you have a Package in Cognos Connection, how do you determine which Project it was published from?Ã,  What is to prevent someone working in SALES.CPF to publish a package called REGIONAL SALES which writes over a package by the same name which came from the MARKETING.CPF FM project?Ã,  Same thing applies to externalized queries as IQD files - they are tagged not by the Project/Package they are assocated with, but with the Namespace the queries are located within.Ã,  There is no way to trace back to the appropriate Project/Package combination without opening FM and doing a lot of legwork.

So, there's a starting point - a need and description of the problem.Ã,  I have tested Segments and found them totally not usable because of the overhead of an entire new project.Ã,  Links work, but are bi-directional and cannot be audited.Ã,  So, what have you done, or suggest.

Thanks for your input!
Opher

[cognosfreelancer]

Hi Opher

Great post!.

To your first prolem, I would recommend a source code control mechanism such as Rational Clear Case (with which I am familiar).

It lets you create an integration view and stream which would contain the master project.

Individual developers can then create a development stream off the integration stream. So if you have 7 developers for e.g. you could have 7 development streams.

Developers would open the FM against using a view to the development stream.

They can pick up the latest updates from the master project by syncing with the integration view. They can 'deliver' their completed work to the integration stream.

The clear case admin or an appropriate person could then include the deliverable into the integration stream so all developers can now access the updates.

Please note that Framework Manager does not include built in support for Rational, so you will have to take the extra step of manually adding FM project to the Clear Case project as a one time activity.

You raise a very valid point in your second question.

I can think of no better way than instituting a naming convention to prevent such problems.

NKT

[cognosfreelancer]

does it make sense.

can you respond.

[Opher]

Sorry about the slow response - too many balls in the air.

Yes, your suggestion makes sense.Ã,  I'll take a look at Clear Case.Ã,  Are you adding the actual model.xml file for it to manage, or will it take the whole project?

As for naming conventions, we've decided amoung the group that one is required.Ã,  We're batting around a few ideas.Ã,  As we test them, we find that CRN is not consistent.Ã,  For example, a query in a package has metadata tagged as "[package].[namespace].[query].[column]" but a query externalized as an IQD is given the name "[namespace].[query]" and no reference to the package it came from is in the name.Ã,  Of course, the FM project name is lost entirely, which is what started us on the path toward a naming convention.

Are you using a naming convention?Ã,  Care to share any experiences you have with one?

Thanks,
Opher

[johnsoncognos]

As far as I know the only 2 supported mechanisms for repository control are Visual SourceSafe (VSS) or Concurrent Versions System (CVS).

I advise mose of my customers to try creating a master project and import have multiple developers import from it.  This is not the greatest way but if you do not have the above mechanisms it's the simplest way.