I think projects that you want to update share the project folder that you want to use for record copy folder, this approach works for multiple.

Surendettement

Jilliane

We have added a fix to the upcoming Sixth Edition to track the primary project folder from a template.  This will allow relative paths to be correctly specified off the primary folder.

I have seen this happen on the following sub-folders during project creation (referenced by their tag names in Newforma):

<newforma folder>
<project email folder>
<file transfer incoming folder>
<file transfer outgoing folder>
<record copy folder>

Thanks, Matt, that’s definitely good to know.  I’ve actually moved those 5 folders into our SQL table, along with the primary project folder in fact, so that we (hopefully) don’t get bit by this.  The SQL workaround seems to function quite nicely for the creation of these folders.

We have indeed created a custom field in Deltek to hold the primary folder path and this field defines the “primary project folder” object that is handed to the Newforma project creation process.  So, it IS unique for each project.

OK, that definitely jives with what I was guessing based on your SQL queries.  Seems like a decent solution if your projects can end up in any number of locations on various servers, in fact.

We have defined a work procedure that explains what needs to happen in Deltek to have a project get linked to and created in Newforma.  This includes having the Deltek users enter in the full path for the primary project folder.  This is very roughly implemented right now, as there is no error checking done on the Deltek side and it is very easy to mess up the path that is entered in such a way that the project will not create in Newforma.

What we have for this path entry in Deltek works for now, but here are some things I would like to work on for future development.  Maybe you’ll find them useful too.

1. Include a workflow in Deltek that automates creation of the necessary project folder(s) on our file servers based on a fixed set of criteria.  This would be separate from the Newforma project creation.  I know some Deltek users are already doing this with stored procedures on the Deltek SQL server.
2. Leverage the folder creation in item 1 to eliminate the need to manually enter the primary folder path in Deltek.
3. The combined items 1 and 2 will provide some sanity checking to make sure valid and unique folders are created for each project.

Your step 1 is defnitely an interesting one that I hadn’t considered.  We currently file all of our project data in one main location, so unique names are essential for us as well.  The idea of automated primary project folder creation from Deltek is therefore an interesting one.

At the moment (still in the testing phase), I’ve got NF making not only the above folders but also the primary project folder.  I simply declare the path as a string literal in the SELECT statement and append some additional bits (project number, name, etc.) so that we’ll get a little bit of consistency and (hopefully) uniqueness.

We also don’t have any data validation on project numbering/naming in Deltek, but only a small group of individuals preform that task right now, which helps.  I’ve done the same appending trick for the other folders you mention above, which means I do have more than one point of potential maintenance should any part of the primary path change...however, those points are all in one place (literally next to each other in the template).  There are always trade-offs, it seems.  :o) We’ll see how happy I am with this solution as I get the Deltek workflow going, etc.

Thanks once again for sharing your work, it’s a big help!
--Erik

For anyone, in terms of where/how the problem manifests, is it necessary to apply the workaround Matt and Mark explain here to all project subfolders, or just to the primary project folder plus the 4 key subfolders that Newforma uses (email, transfers in and out, and record copies)?

I have seen this happen on the following sub-folders during project creation (referenced by their tag names in Newforma):

Finally, a couple for Matt, based on your SQL query, it looks like you created a custom field in Deltek to hold your primary folder path.  Is that path actually the primary project folder for the given project (and therefore unique for each project), or is it the parent folder would hold the unique project folders?

We have indeed created a custom field in Deltek to hold the primary folder path and this field defines the “primary project folder” object that is handed to the Newforma project creation process.  So, it IS unique for each project.

I’m curious as to how your process works on the Deltek side, I guess.  Are Deltek users responsible for typing in the full path to the primary project folder at project setup time?

We have defined a work procedure that explains what needs to happen in Deltek to have a project get linked to and created in Newforma.  This includes having the Deltek users enter in the full path for the primary project folder.  This is very roughly implemented right now, as there is no error checking done on the Deltek side and it is very easy to mess up the path that is entered in such a way that the project will not create in Newforma.

What we have for this path entry in Deltek works for now, but here are some things I would like to work on for future development.  Maybe you’ll find them useful too.

1. Include a workflow in Deltek that automates creation of the necessary project folder(s) on our file servers based on a fixed set of criteria.  This would be separate from the Newforma project creation.  I know some Deltek users are already doing this with stored procedures on the Deltek SQL server.
2. Leverage the folder creation in item 1 to eliminate the need to manually enter the primary folder path in Deltek.
3. The combined items 1 and 2 will provide some sanity checking to make sure valid and unique folders are created for each project.

Hello all,

As I’ve just started down the path to Deltek Projects -> Newforma integration, I found this thread to be very relevant and interesting.  Thanks to Matt and Mark for sharing their explanations and the workaround.  In pondering this solution, I have a few questions about the specifics.

For Newforma HQ, is there yet a timeline for a fix to the pathing issues in n4.exe and the Apply Project Settings functionality for 5ed?  I ask because to me this still smells a bit like a bug, even with the very helpful SQL workaround available.  So, I’m curious where it is on the development radar.

For anyone, in terms of where/how the problem manifests, is it necessary to apply the workaround Matt and Mark explain here to all project subfolders, or just to the primary project folder plus the 4 key subfolders that Newforma uses (email, transfers in and out, and record copies)?  I ask because we’re planning to have Newforma create a collection of subfolders for each project, so it’s a different proposition for me to move all of that into the SQL table vs. moving only 4-6 items in there.

Finally, a couple for Matt, based on your SQL query, it looks like you created a custom field in Deltek to hold your primary folder path.  Is that path actually the primary project folder for the given project (and therefore unique for each project), or is it the parent folder would hold the unique project folders?  I’m curious as to how your process works on the Deltek side, I guess.  Are Deltek users responsible for typing in the full path to the primary project folder at project setup time?

Thanks very much,
--Erik

An excellent idea, and it seems to work a treat - full path info is now available in the sql table portion of the template.  Thank you!

For anyone interested in the SQL code we’re using to accomplish this, see below.  Comments and suggestions welcome.

For some Deltek integrations in the past where a customer has specified multiple project folders and spread the Newforma project folders around these locations, we have needed to explicitly specify those paths in SQL as well.  For instance, the <record copy folder> property could be calculated as an absolute path using a SQL statement.  This path might be based off the primary project folder with the additional folder structure concatenated on the end.  This technique can be used for all project properties allowing them to be generated by SQL code within the <sql table> if the flexibility is needed.

In particular, we need those folders to be set in the template in order to create a new project in Project Center from within Deltek Vision.  During project updates triggered from our Vision system, these folders are not used.  But, in order to actually create a new project in Project Center from Vision, I need to specify these folders (using full path names).

During manual project creations based on our master project template, this is easy.  I have to manually fill out the primary project path in the template spreadsheet and can therefor just reference that path as the base for the other paths that need to be entered.

However, the templates that are associated with the Deltek Vision system all use the embedded <sql table> syntax to perform lookups from the Vision database, including a lookup of the primary project path.  Since the primary project path is now a lookup that’s interpreted at runtime by Project Center, I don’t have the actual value of the lookup available in the spreadsheet itself to create absolute folder paths.

Does that make sense?  Is there a better way to accomplish this?

Thanks,
Matt

Hi Matt,

I’d like to understand what you were trying to achieve when you discovered this issue. Were you doing any folder rename or move, or were you trying to change the project folders? Since those folder parameters are mainly used to specify where emails, transfers, and project record copies reside, I am curious to know what operations you were trying to do…

Thanks in advance,
Fanny

Just ran across another application where this bug is an issue.  For a “standard” template, it is relatively easy to always use a full path for the affected settings mentioned.  However, when updating info via a template that has embedded SQL tables in it, I cannot easily reproduce the full working paths for the settings folders.

Can you confirm an approximate timeframe for when this issue will be corrected?

Thanks,
Matt

Upgrade does not require users to hand n4 a template to work with. The default values are used for newly added fields in upgraded project, such as the record copy folder. In the case you mentioned, it seems like there is bug since it is not deterministic as far as the code runs to pick the primary project folder.

Alternatively you can use ‘Apply Settings’ task on the admin page in NPC for projects that you need to update the project record copy folder, by using absolute path in the template file. It is sufficient to only specify that field in one template, if that’s the only parameter you’d like to update. If all the projects that you want to update share the project folder that you want to use for record copy folder, this approach works for multiple projects. (This task is enabled when you multi-select projects in the project list.)

Hope this helps…

There is one other instance that I am aware of where this may be an issue as well, as it hit me during our upgrade from v4 to v5.

Version 5 added a new Newforma path for “Record Copies” that was not present in the v4 project settings.  When I ran n4 to upgrade the projects, some of them defaulted this previously undefined record copies path to using the primary folder as the base path; others grabbed one of the secondary folders and used that as the base path.

I can’t remember offhand if that upgrade process required me to hand n4 a template to work with - does it require a template as part of the upgrade process?  If it does, this can likely be worked around by working an absolute path into the template.  If it does not use a template for the upgrade, is there another way to force it to default the new setting to use the primary folder as the base path?

I am able to reproduce the exact same behavior - n4 and apply project settings in the admin page both share the same defect.  As you stated, the work-around would be to always use absolute paths for these folders in your templates.

There appears to be a bug in how the n4.exe tool creates file path information when updating/creating a project and reading relative path info stored in a project template.

Reproducible: Not reliably

Description of Issue: When using n4 to update projects in the system, it appears to not consistently parse any relative paths that exist in the Excel project template file being used.  This becomes a problem when secondary project folders exist along with the primary project folder, as n4 will randomly pick any of the primary or secondary folders to prepend to the relative path to get the desired absolute path.

For example, our standard setup includes the path “Newforma\NewformaEmail” for the project email folder property in the template, with the intention that this “Newforma\NewformaEmail” folder will always be created and reside as a subfolder within the primary project folder path.  However, n4 seems to randomly use one of the paths listed under the secondary project folders table list on some occasions, with no readily discernible pattern.  Almost all of our projects use at least two paths (one primary and at least one secondary), so this is a big problem for us as the relative paths are being randomly changed by n4.

Impact: Relative paths are not consistently parsed by n4 from the Excel project template file.

Workaround: Don’t use relative paths in the Excel project template file.

Desired Behavior: The n4 tool should always default to using the primary project folder as the base path to prepend to any relative paths that are in the Excel project template.