Are you responsible for getting Teamcenter Service Packs or Patches applied to your environment? Are you concerned about how long it will take? Do you remember days when applying a patch took less than an hour?
If your Teamcenter environment has many business logic servers that need to be updated, we are pleased to introduce a new parallel process that will significantly decrease the amount of downtime, whether you’re running Teamcenter 9, 10 or 11.
To update all of your business logic servers faster, this new process involves updating the primary server first, then updating all secondary servers in parallel. The new process results in being able to update your environment much faster than before, resulting in a decreased downtime and increased system availability for your users. With the additional benefit that your IT department will spend less time installing software and more time on other important tasks.
Read Software Field Bulletin (SFB) 11415 “Teamcenter Parallel Patching” (customer-only access) for specific instructions, or continue reading to learn more.
Patching in older releases
In older releases of Teamcenter, a service pack or patch only contained bug fixes for the major release. For example the Teamcenter service pack 8.1.2 contained bug fixes for the Teamcenter 8.1 major release. Typically when a developer fixes a bug, it results in a library that needs to be updated in your environment. To deliver this library to you, the updated library was included in a service pack or patch. The result is that the service pack or patch contained mostly a set of libraries that contain all the bug fixes for a given period of time. When you applied the service pack to each machine in your Teamcenter environment, the TEM (install wizard) would take the libraries from the service pack and overlay on top of the older libraries on your machine. This overlay could be performed very quickly because it was a file copy. Hence you could take your system down, quickly run TEM to update your machines, and bring it back up.
Why did this change?
In older releases of Teamcenter, new features and enhancement requests were only introduced in major releases. Examples of major releases are Teamcenter 8.1, 8.2, and 9.1. These major releases were made available to Teamcenter customers approximately one year apart or longer. Bug fixes were provided through the year via service packs and patches approximately every three months.
Because our customers had to wait a year or more to receive the new features they needed, many of our Teamcenter customers requested that enhancements be made available sooner so they could meet market demands faster. The result is that Siemens PLM Software started to accelerate the release of new features in Teamcenter service packs. Since the service packs were released every three months, which is more often than major releases, our customers could utilize the benefit at a faster pace. This new policy started around the Teamcenter 188.8.131.52 and 10.1.1 releases and continues to this day in the Teamcenter 11.x series.
Faster updates mean faster benefits
Releasing new capability at a faster rate is a big benefit to Teamcenter customers. However, new features often require business logic server library updates, client extensions, administration data, and BMIDE extensions. All of these additional extensions have to be included in the service pack or patch to enable the new feature to function correctly, which takes time, especially when you have to apply them one-at-a-time, or serially.
To speed things up,you no longer have to apply service packs and patches serially … we are pleased to introduce a new parallel process for faster downtimes that you can apply whether you’re running Teamcenter 9, 10 or 11.
New parallel process speeds updates
With the release of Teamcenter 11.4, we have introduced a new parallel process to speed your downtimes, along with workarounds that you can apply whether you’re running Teamcenter 9, 10 or 11. Read Software Field Bulletin (SFB) 11415 “Teamcenter Parallel Patching” (customer-only access) for a detailed description of the issue, resolution, and workaround, which I will summarize here.
When using Teamcenter 11.4, there will be a new process to follow. First you should select one of the four pool managers to update first using TEM. Let us call this the primary business logic server and the other three are the secondary business logic servers. When the update of the primary business logic server is completed by TEM, you can then update all other pool managers in parallel. This means that all secondary business logic servers can be updated at the same time.
When TEM updates the secondary business logic servers, it will not attempt to update the data model or run data base commands because the data model and database has already been updated when the primary business logic server was updated. Thus TEM will only perform a file copy to update the libraries and TC_DATA update on the secondary business logic servers. As a result, the update of the secondary business logic servers will go much faster resulting in shorter downtimes and less interruption to user activities on Teamcenter.
Was this article helpful? This blog post continues our series to help your IT team become more efficient. Read the first blog post on the importance of IT in this age of digital disruption, and catch up on our declarative configuration series to learn how you can you can become faster, and more agile, in tuning Teamcenter to meet the changing needs of your business.
You can also read back through blog posts like , , and Store and Forward with File Management System (FMS) for more topics related to Teamcenter administration