≡ Menu

3 Lessons Learned while Upgrading Teamcenter to 8.3

Share the knowledge

About a month ago at work we went through the process of upgrading Teamcenter Engineering 2007 to Teamcenter 8.3 (AKA, Teamcenter Unified). Here are a couple of lessons learnt from mistakes we made:

  1. Account for workflows that were started, but not completed, before the upgrade.

    We had to make some changes to our workflows to accommodate some of the changes we made while upgrading Teamcenter. We tested the new workflow templates extensively, but we never tested what happened to the workflows that were started in Teamcenter Engineering but would be completed in Teamcenter 8.3. Either we should have tested that case, or we should have had a policy that all in-process workflows had to be completed or terminated before the upgrade.

  2. Test while logged in as a non-DBA user (not just while not logged into the dba group).

    We did lots of testing — but most of it was done by users who were members of the dba group, although they weren’t typically logged into it while they did the testing. Well, unfortunately, Teamcenter sometimes treats users a bit differently if they have dba membership even when they’re not currently logged into that group. When we went live we discovered that many of our regular users were having problems that we had never seen during testing. What we should have done in our test system was to log in as one of the “regular” users to do the testing.

  3. Roles are objects that can have object-ACLs.

    This isn’t a generally applicable lesson like the previous two, but it was enough of a surprise to me that I think I should mention it. Somehow a couple of our oldest roles, originaly created in iMan 7 or so, turned out to have had object ACLs attached to them somehow at some point. This caused some really bizarre and surprising problems when we went live. This was actually the main set of errors that we missed because we had been testing as users who who were members of the dba group.

Here’s hoping that these lessons may help you avoid some grief the next time you upgrade Teamcenter!

  • Jeremie FEBURIE

    Thanks a lot for your feedback
    First point is an important note that we should take care on future migrations
    Second point is not only relevant to migration but also for functionnal test also (always keep in mind that dba and infodba have special access rules on the top of the rule tree)

    Third point is a very strange situation inherited from your history …

    • http://plmdojo.com/ Scott Pigman

      our mistake was not realizing that some of those special behaviors apply even when you’re in a “regular” group. I think some of it goes beyond the Access Rule Tree and is hard-coded into the software.

  • Swaminathan Maa

    Valuable updates. Thanks.

    We faced similar problem after our every release that regular user faces strange problems rather testing team had never seen the clue of the issue during their testing phase.

    Is there any way to overcome this issue? Is Teamcenter built for this kind of behavior w.r.t Session login user, user has other roles and ACL?

    • http://plmdojo.com/ Scott Pigman

      As part of testing we had cloned our production database so it had our entire organization structure and all of our metadata. What we should have done was simply pick some user IDs, reset their passwords and logged into the test system as those users and done our testing under their IDs.

  • Teamcenter Heretic

    There are a few items to think about in this area…

    1) Some stuff gets cached, so simply logging out and in as another user is not really valid.
    Better to stop your TC client, clear the RAC cache and login as another user.

    2) Always have a “bozo user” that has no special privs and who does not use a privileged OS account. This will save you bundles of time debugging.

    3) Have a real test plan and execute it faithfully.
    One of the challenges with Teamcenter is that most testing becomes destructive and at some point your test DB is so trashed that you really cannot use it for anything significant.
    VMs can play a huge role in this but some of the biggest challenges are in the area of volume copy.

    4) Be very careful when you are creating data as infodba.
    It is imperative that you are able to do a full copy of infodba’s data for testing, and if you do things like create standard hardware as infodba then your volume becomes so large that you cannot easily copy it. The challenge then becomes one of sifting thru the “important” data and leaving the “useless” data off your Test system.

    5) Insist that real users test the system, but assume the reality that they tested nothing.

    6) Plan to get blamed.
    ‘Nuff said on that one 😉

    • Jeremie FEBURIE

      1) I agree with you
      2) I agree with you
      3) I agree with you, boring task but really needed : “build a test plan”
      4) I agree with you
      5) I agree with you, so true
      6) I agree with you

  • Santosh Aher

    Hi Scott, thanks for sharing your valuable experiance.
    To provide reliable and flexible solution for Teamcenter testing as a part of upgrade or fresh install or even patch update we have unique solution of testing in automated way.
    1. Where automated suite does testing using different data and different user ID combination.
    2. We have automated workflow creation process as well where script will go ahead and created workflow as per requirement with given data.
    3. The automation actually works on UI level so it does all what human does in Teamcenter, however has great execution speed and acuracy.
    Just an example – we have created 500 workflows in few hrs using UI based automation scripts, or we have capability to execute more than 1000 + tests a week through unattended 24 x 7 automation suite.
    I will be more than happy to share details if you need more information of how this will help you or different customers in upgrade testing.

    • https://twitter.com/Skinning_Door PS:

      hi santosh,
      thats a very important factor which often worries customer.
      i feel its important to moniter system performance with every upgrade to learn how it affects whole environment
      please share your thoughts?
      also explain how do you automate this testing process?


    • http://www.facebook.com/kaushik.kesani Kaushik Kesani

      Hi Santosh. Currently we are upgrading from TC7 to TC9. Can you please share the automation test scripts that you have created. It would be of huge help for us.

  • https://twitter.com/Skinning_Door PS:

    hi scott,
    thanks again for this informative article.
    with these contant upgrade n updates in teamcenter environment
    it is often observed that system performance always keeps on changing
    like normal business process of item creation, opening a cad assembly or executive a workflow process becomes slow at times..
    do you think its possible to track system performance changes after these upgrades thru some monitering mechanism?
    i guess siemens has never given any utilities or recommended any third party tool to integrate with teamcenter to achieve this..
    share your thoughts..


    • http://plmdojo.com/ Scott Pigman

      Talk to your Siemens Rep. Siemens has developed some standardized tests for evaluating performance. We recently had them come in to do a “health check” of our system. They compared our performance to the results from their lab and then gave us several recommendations for how to improve our performance results.

  • Teamcenter Heretic

    I’ve always used ITK nd the NxAPI to gather statistics.
    Really easy to write standard tests and log the results.
    Really convenient when tracking down not only global performance issues, but local ones as well.

    Don’t know how many bets I won that the ethernet card was not running at full speed on a single workstation just based upon simple file retrieval timings.

    Once you establish your baselines, it is a simple thing to run and compare after changes.
    and unlike the Siemens tests that compare apples to oranges, this is apples to apples 😉

  • Michael Russell

    I would assume that migration and upgrade have very similar issues. So I want to ask the community about Hardware upgrade. Moving from a M$ to a Linux based TeamCenter instance should be relatively uneventful. (given the import/export into PLMXML) Are there any pitfalls that I should be aware of? Will my BMIDE projects die a horrible death? I know to try to stay with the same database, so that should be of no issue. I’m asking conceptually for your best guess and ideas. But if you have done it before that is also worth knowing.

    • Jeremie FEBURIE

      At first, you have to identify the hardware that is supported for both source release and target release.
      This hardware will be used for the upgrade execution. It could be W$ or Linux, it doesn’t matter.
      On this hardware, you execute the upgrade from source release to target one, so your application is upgraded…
      At the end, and if upgrade wasn’t executed on target harware, you just have to install a new server with Teamcenter corporate server (FSC, PoolManager, WAS, Dispatcher and other modules)
      All new TC clients that you install will be directed to this new server …

      Bmide is not a problem because it is just a set of xml files.
      TC clients (RAC) are never upgraded, you just uninstall old release and install a new RAC of new release.

    • Teamcenter Heretic

      I’m assuming you are not meaning Lintel, but rather Linux…

      Remember the limitations if you are using Micro$oft stuff now…

      MSSql doesn’t run on Linux. So, if you are on MSSql now, the migration will be quite painful.

      The PDF generation API in Nx only runs on M$

      If you are in 4Tier make sure your TC server processes are not relying upon any M$ specific stuff.

      Make sure that you do NOT make a “new” BMIDe project to support the Linux. If you do, then your template will get a new UID and you will get pretty well hosed until you fix that.

Optimization WordPress Plugins & Solutions by W3 EDGE