MSP XML Interface - Limit on number of Assignments?

[Legacy User]

Comparing Legacy version to XML version of MSP Interface.

 

• Projects which produce XML files under 2MB load fine into MSP whether using Legacy or XML version
• Where XML file is greater than 2MB, Legacy version will load into MSP fine, but XML version stalls - must use Task Manager to kill after weighting 10 or minutes.
• Took a project which produced 21MB XML file
  • Loaded using Legacy version in about 2 minutes (also loads in CA PPM Gantt and OWB just fine)
  • Using XML version, stalled
  • Edited XML file, removing all but one assignment
    • Yes, this was a drastic cut, but was looking to see if number of assignments was the problem or something else in the file; was not looking for the exact number or range at which number of assignments becomes problematic
    • File imported into MSP instantly
• Using MSP2010 on machine with 8GB memory

 

Has anyone had same experience?  Have you moved to newer versions of MSP and has experience gotten better or stayed the same?  Found any setting changes in MSP that resolve this?  (I've read through configuration docs, checked settings.)

 

I'm attempting to get MSP2016 installed and will report my findings.  But if someone already knows that large numbers of assignments will kill even the latest version of the XML interface in MSP2016, would like to avoid spending time on a known issue.

 

Thanks.

[Kristin Schroer]

Hi Dale,

 

There's no official limitation on assignments that I am aware of, and the size of your xml appears to be one that should typically save back from my experience. While the xml (new driver) is generally faster then the legacy, there are a couple of known issues that can cause the issue you are seeing:

 

1. Check to see if you have any Microsoft Project updates installed. If you have any updates unsupported with the version of the MSP Interface you have installed, it's recommended to uninstall them, as I've seen at least one cause this type of issue.

 

2. If that doesn't help there was also a Microsoft Project performance issue that caused slowness for some projects that was resolved in a Microsoft Project Update. This Microsoft Project update is supported starting in the MSP 14.4 New Driver. See list of supported updates here that include this fix: https://www.ca.com/us/services-support/ca-support/ca-support-online/knowledge-base-articles.tec1830355.html 

 

Thanks,

Kristin

[Legacy User]

Hi Kristin,

 

Wondering if there is anything new on this.  We went back to legacy driver, but with Windows10, MSP2016 (Version 1708 Build 8431.2250) and 15.2 all coming together here, now, have started to try the XML version - and our problem is back on some projects.

 

Appears to be quitting during the load of calendars, resources.  Windows process monitor shows MSP goes to idle - no activity.  I quit the process, which left the XML file on my machine.  I then opened it manually from within MSP.  Saw calendars and a partially loaded list of resources.  Other projects, some with bigger XML files, load fine.

 

Co-worker opened my problem project from CA PPM using legacy version, on their own machine, no problem.

 

Could there be something in a resource/calendar name or id that causing this to grind to a halt?  Willing to have someone look at the file.

[Kristin Schroer]

Hi Dale,

 

There's been a few recent fixes around MSP projects not opening in 15.3 and 15.4. 

 

1. Do any of the projects have baselines? If yes, if you create a new baseline in PPM, does that allow the project to open? If yes, then this points to the following defect: MSP New Driver: Project hangs when opening at "wri - CA Knowledge

2. Another reason I've seen projects hang on opening in the new driver is if there are any enterprise fields associated with the project: MSP New Driver: Projects do not open if there are - CA Knowledge 

3. Here's one other one, but this one usually generates an error when the project is attempted to be opened: In the MSP New Driver, Incorrect Rate Dates Preven - CA Knowledge 

 

So far, I don't believe I'm aware of anything in a resource / calendar name or ID that has caused issues, but it's possible. If the above doesn't help, support can look at the XML to see if there is anything else going on. 

 

Regards,
Kristin

[Legacy User]

Hi Kristin,

 

No baseline - so #1 is out.  And, we've never used MSP Enterprise, nor has this project ever been exported to MSP before - expect #2 is out.

 

I'm not getting the 'SchedLink MFC Application has stopped working' error, but I do see "The last time you opened 'PRJ00088.xml', it caused a serious error. Do you still want to open it? " message.

 

Also, the XML file contains dates in 2079, even availability dates of 2149.  May we live that long!

 

• <Rate>
  <RatesFrom>1900-01-01T00:00:00</RatesFrom>
  <RatesTo>2079-06-03T00:00:00</RatesTo>

 

• <AvailabilityPeriods>
  <AvailabilityPeriod>
  <AvailableFrom>1984-01-01T00:00:00</AvailableFrom>
  <AvailableTo>2149-12-31T23:59:00</AvailableTo>

 

Is this sufficient evidence for your #3? 

 

If yes, will try the workarounds suggested in the associated link.

 

One question regarding:  "These errors occurs when another resource/role has been staffed on the project Team after the Rate Matrix Extraction job has already run and there are already records in the nbi_proj_res_rates_and_costs for other resources/roles on that project.

 

• The RME job is regularly scheduled
• We staff projects, and then later, new staff or replacement staff are added
• This is a naturally occurring thing, it's reality
• So, won't this issue continue to present itself each time I add/replace a resource/role to a previously staffed project?

[Legacy User]

Ah, I see permanent fix is in patch 5.  So, problem may recur if patch 5 is not installed.

[Kristin Schroer]

That's correct. Though based on that excerpt of the XML, your rates are okay, at least for that resource. The issue happens if the dates are out of order (example, rates starting from 1984, and going out to 1900 is a problem, since 1900 is in the past. The Rates To should be after 1984. Example of a problem rate below:

 

    <RatesFrom>1984-01-01T00:00:00</RatesFrom>

     <RatesTo>1900-01-01T00:00:00</RatesTo>

[Legacy User]

I have found 4 resources in the XML file with following XML tag:

 

      <Resource hidden="true">

 

When I remove these from the XML file (their calendar/resource/assignment data), the file loads perfectly and quickly.

 

None of the other resources have this 'hidden' tag.  The 4 resources were all added to the project recently (May 2018); project was created in 2016.

 

Is this more proof for root cause #3?  Or signs of something else?

[Kristin Schroer]

That part with the resource hidden is interesting, great find! I don't believe I've seen that in a project XML before. I tested and I don't see "Resource Hidden" in my XML here. Some questions:

 

1) Were these resources added through PPM or MSP? 

 

2) Do you happen to have a Skype integration or any other type of addin associated with Microsoft Project?  I did some searching and saw that with Skype, there is this Resource Presence option that can be associated, and that's the one thing I'm wondering if it could be causing something to display in the XML if for some reason the XML recognizes that as hidden if the resource presence is not visible. Here's a link to what you'd see if you are using the Skype integration: Turn online status off in Project Professional 2016 - Project  

Thanks,

Kristin

[Legacy User]

Well, I'm glad I found something new!

 

• Resources were added via CA PPM
• Yes, we have Skype
• I disabled this option per the link provided - still, the project import from XML stalled at same point

 

As a next test, I want to try deleting one hidden resource at a time - maybe 'hidden' isn't the key problem, but something else within one of the hidden resources.

 

In the meantime, would there be any benefit to sending our XML file to you?

 

Dale

[Kristin Schroer]

Thanks for trying disabling that option. Yes, that would be great, if you send the XML to me, I can take a look in more detail.

[Legacy User]

After further testing and finding issue on additional projects, was able to identify instances of reversed dates in XML file, as described in the link provided above.  After removing these from the XML file, the files loaded instantly.

 

Replicated issue in our TRN system and found same issue in our Sandbox(SB) system, where recent copy of PRD data was installed.

 

Our IT team put 15.2/patch 7 (latest available) into our SB system - problem resolved.  Installation to TRN scheduled for noon, today.  Hopefully, patch can be installed in PRD system over the weekend. 

 

Thanks, Kristin!

[Legacy User]

Hi Kristin,

 

15.2\Patch 7 installation completed on our training (TRN) system - no luck.  Problem remains where one gets "From 1984 To 1900" in XML file after adding resource to Team\Staff page.  Sandbox (SB) system continues to operate fine with the same patch.

 

Why the two systems are behaving differently, we do not know, yet.  Of course, team is not encouraged to push for installation in production (PRD).  

 

Ideas on what to check?  Expect something failed to install correctly from patch into our TRN system.

 

Dale

[Legacy User]

Resolved - work on DEV and TRN with plan to install patch 7 into PRD next week.

 

Issue was that the patch apparently modifies files in the MSP Interface - so even if one has recently installed the interface, patch 7 makes that recent install obsolete.  "15.2 XML version" isn't the latest - "15.2 XML version downloaded after patch 7 install" is the latest.

 

 

Working with Stephen and Maria (Plano, TX office) we did a complete uninstall of the MSP Interface, then reinstalled, making sure the software download was done from an app server that had the patch 7 install completed.  We also did some investigation into why the previous version of the interface worked on our DEV system after patch 7 was installed - why did it work there, an not in TRN?  Issue may have been related to differences in content of NBI_PROJ_RES_RATES_AND_COSTS table between the two systems.

 

All works, now, as expected.