Al,
Your post interested me a lot. Despite using classification extensively at Weatherford the two aspects of Partslink you are having problems with are things we don’t use, Index Search and Counterpart, so I cannot comment on them. Incidentally the reason we don’t use them is because they were not available back in 2002 and we developed alternatives that we continue to use.
Something else you mention in your post is “not in a DMZ on a cluster using Windows virtual servers”, this is something I do have experience with. We also run a clustered environment, and have been using Virtual servers for years. Our database server is physical, and the client facing application layer uses virtuals, which we are currently replacing with Physical machines for performance reasons.
The master server for our cluster also runs a background methodserver and handles all the queue processing, users do not connect to this machine and it was also initially Virtual but had to be replaced with a physical machine for performance reasons. The CPU utilisation was always high on the machine when it was under load and bits of the application stack would drop out sporadically as a result of the CPU being flat out.
For a time we also had identically configured Virtual and Physical slave machines in our cluster, these saw similar loads from behind the load balancer and the CPU utilisation was always significantly higher on the Virtual machine and this leads to stability problems. Basically in our experience if you get a Windchill server with a CPU utilisation that is sustained at more than 90% it will fall over sooner or later, bursting to 100% is fine as long as it is not sustained. With Virtual machines these conditions seem to occur more easily and with no clear or repeatable reason why.
We invested a lot of time working with our hardware and storage group, following all the recommendations for configuration and testing changes. Bottom line is that we cannot get a Virtual Machine to perform anything like as well or consistently as a physical. From a disaster recovery perspective Virtual servers are great, but from an application owners perspective they are as much work as a physical machine and don’t perform as well.
Best regards,
-----
Lewis
In Reply to Albert Anderson:
At Solar Turbines Incorporated, we have a production version of out of the
box PDMLink 9.1 with PartsLink using CounterPart to manage our
classification schema.
We are currently having a terrible time with the stability of the
PartsLink classification Queue for new parts, and with the Update command
when checking in schema changes to production.
While we are very happy with the potential for PartsLink, but it does not
appear to be a stable, enterprise, production worthy system yet - at least
not in a DMZ on a cluster using Windows virtual servers, where we have our
system. We are getting excellent support from PTC so far, and I think we
will work this out eventually. Our sincerely hope is that we can have it
stabilized in a few more weeks. We went live with PDMLink 9.1 and
PartsLink on March 9th, and the Classification Search has been unavailable
for about 50% of that time.
We only made one customization that interacts with PartsLink that applies
to auto-naming classified parts. It is pretty interesting, and very
successful so far, so I'll share it here. This part of the application is
working great since it has nothing to do with the out of the box
classification queuing or schema updates and reloads with which we are
having difficulty.
On Create New Part, we have an out of the box Name field as required even
though we will overwrite it on classification. The removal of this field
would be a JSP change, but it was a type of customization that we have
decided to avoid. Therefore, we live with having it required, but
overwritten.
Every classification node, as this Turbine Nozzle Assy shows, below, has a
pre-set, node-specific, single value, mandatory string set that includes
the Naming Rule for parts of that node. The syntax is
CONSTANT|attributeName1|attributeName2 where we can have any constant, and
any number of attribute names provided that we do not expect attributes
exceeding our site-specific 30 character maximum name. We have a Part
Create and Update service that listens for create and update events that
will evaluate this rule, and then assign the name for this WTPartMaster
according to the node-specific naming rule where the constant is followed
by a comma, followed by the value for the named attribute, followed by a
comma, etc. as shown in the example below.
On save as, the name of the part changes to "UPDATE ATTRIBUTES REQUIRED"
to force a user to check out and check in the part to verify that the
original attributes are correct and/or make changes for the new part
number.
If a part is not classified, then the name changes to "CLASSIFICATION
REQUIRED" until it is classified, and our RTP to the ERP system will not
let that part go over until it is classified.
We pre-classified our 20,000 most frequently used parts prior to go live.
And we allow unmodified, unclassified legacy parts to go to ERP as
components in classified next higher assemblies, but if anyone revises one
of those legacy parts, that part name changes to "CLASSIFICATION REQUIRED"
until it is classified, and our RTP to the ERP system will not let that
part go over until it is classified.
The power of this approach is that is it all configuration managed. In
other words, our Classification Administrator can set or change the naming
rules without code changes. And we can have every node use a different,
node-specific naming convention without any further customization or code
change.
I would be happy to share more information about this off line or on line,
depending on the interest level.
Al Anderson
Solar Turbines Incorporated
Stephen Drzewiczewski <->
04/17/2011 08:41 PM
Please respond to
Stephen Drzewiczewski <->
To
-
cc
Subject
[solutions] - PartsLink - Any lessons learned?
Caterpillar: Confidential Green Retain Until: 05/17/2011
We are about to start a PartsLink implementation and am looking for
anything people have learned from their own implementations.
Did you start with the standard Windchill Classification schema and modify
that or did you create your own from scratch?
Things to avoid?
Data loading approaches?
Thanks,
Steve D.
Site Links: View post online View mailing list online Send new post
via email Unsubscribe from this mailing list Manage your subscription
Use of this email content is governed by the terms of service at:
http://portal.ptcuser.org/index.php?module=sthtml&op=load&sid=s1_010_tos
