Multiple Organizations in PDMLink

[cswaner]

Hello Gurus,
Some time ago I tested creating a second organization in an existing
PDMLink instance that had a single Org that had significant
configurations and changes made. I found that some of the
configurations in the newly created did not work, in particular those
rules etc. that conflicted with the first Org created. I found it
impossible to fully configure the new Org independent of the first Org,
almost like the second Org was subordinate to the first.

After some discussion with some PTC consultants, I discovered this to be
a known issue that can be resolved with creating a "dumby" Org first and
not configuring anything in that Org. Then create and configure the
second and third Org independently.

Does anyone know what I am talking about? Can you confirm the proposed
solution? What specific issues have you had with the use of multiple
Orgs?

Thank you in advance, I appreciate any feedback on this.


Cameron Swaner
Engineering e-Tools Administrator
GE Healthcare

T 801-536-4514
E -

384 Wright Brothers Drive
Salt Lake City, UT 84116

GE imagination at work <">http://www.gehealthcare.com/worldwide.html>

[ZacharyAlexande]

What you were told is correct. During installation of Windchill Services, a
default, or first, organization container is defined/created. This default
organization principle "owns" the site container. A default organization
container is optionally created during the Base Data loading process. The
default org will act differently then other orgs (i.e. soft types created in
the context will be available site-wide).

PTC has said:
"It is recommend that if you intend to use multiple organizations now or in
the future, do not create the default organization container during Base
Data loading. As a result, you must create an organization context (using
the GUI or bulk loading) before users can access the solution.
Note: If you do create the default organization container, the above issue
can still be avoided as long as this container is not used - create another
organization container (and automatically this will not be associated with
the site owning organization principal) and use this for the customer data."

Hope this helps

On Sat, Oct 3, 2009 at 12:59 AM, Swaner, Cameron (GE Healthcare) <
-> wrote:

> Hello Gurus,
> Some time ago I tested creating a second organization in an existing
> PDMLink instance that had a single Org that had significant configurations
> and changes made. I found that some of the configurations in the newly
> created did not work, in particular those rules etc. that conflicted with
> the first Org created. I found it impossible to fully configure the new Org
> independent of the first Org, almost like the second Org was subordinate to
> the first.
>
> After some discussion with some PTC consultants, I discovered this to be a
> known issue that can be resolved with creating a "dumby" Org first and not
> configuring anything in that Org. Then create and configure the second and
> third Org independently.
>
> Does anyone know what I am talking about? Can you confirm the proposed
> solution? What specific issues have you had with the use of multiple Orgs?
>
> Thank you in advance, I appreciate any feedback on this.
>
>
> *Cameron Swaner*
> Engineering e-Tools Administrator
> GE Healthcare
>
> T 801-536-4514
> E -
>
> 384 Wright Brothers Drive
> Salt Lake City, UT 84116
>
> GE imagination at work <">http://www.gehealthcare.com/worldwide.html>
>
>
>

[MikeLockwood]

We had the same experience just experimenting a while back. We have only one Org but it's very possible that at some point we will need to add another - and we're stuck with the situation you describe below.

It's one of those many things about the system that:
a) is extremely important
b) is not documented (at least not well - it may be buried somewhere)
c) once you select one way or the other and implement in production you have to live with basically forever
d) the GSO consultants also didn't clearly understand

Possibly the most valuable thing we could do on this forum is create a collection of this type of thing, under the heading of "lessons learned" or "things I'd do differently if I could."

[dtkach1]

Mike,

What about the case if to have two separate Windchill instances each one
for single organization instead of having single Windchill instance for
multiple orgs?

Thanks,
Dmitry

[dtkach1]

Yes, you are right. But the point is that 2 systems should be integrated
somehow for example via Web services (not limited Info Engine API). And
I believe that it will give more flexibility for entire enterprise
solution than using single system with several organizations. So the
question is how 2 Windchill instances can be integrated, how they can
talk to each other without process or data exchange limitations.

Thanks,
Dmitry

[dtkach1]

There are two ways how you WC instances can talk: using RMI or SOAP. Its
not a problem, the issue is under Business side. What the benefits we
can get having one single Windchill instance for enterprise and having
several Windchilll instances. I just believe that distributed
configuration infrastructure (multiple Windchill instances) is work
better down on the road and trying to investigate how multiple
Windchills can have single solution with integrated Processes such as
Product Development, Change processes, etc.

Thanks,
D

[achukwuka]

Just to chime in here. Given the scenarios that Dymitry described below, Would this be a case for PLM connectors? I could be wrong of course.


Thanks


Alexius C. Chukwuka
IT Analyst, PDP Systems
John Deere Power Systems
Product Engineering Center
*Voice: 319-292-8575
*Mobile: 319-429-5336
*FaxFax:319-292-6282
*E-Mail: -

CONFIDENTIALITY. This electronic mail and any files transmitted with it may contain information proprietary to Deere & Company, or one of its subsidiaries or affiliates, and are intended solely for the use of the individual or entity to whom they are addressed, shall be maintained in confidence and not disclosed to third parties without the written consent of the sender. If you are not the intended recipient or the person responsible for delivering the electronic mail to the intended recipient, be advised that you have received this electronic mail in error and that any use, dissemination, forwarding, printing, or copying of this electronic mail is strictly prohibited. If you have received this electronic mail in error, please immediately notify the sender by return mail.

[dtkach1]

I believe that every product has own lifecycle from concept up to
utilization. And if products have own unique product lifecycle - does
it mean that product change management and product configuration
management depend on product lifecycle and the nature of the product? In
this case we cannot have single change process for all products, we
cannot have the same configuration management for all products.
If Change and Conf processes are different does it mean that its a good
practice to have single Windchill instance for all products? May be it
make sense to think about possible solution having distributed Windchill
instances configuration (more couple of course; that Groups and
Principals will be shared between several Windchill instances and may be
library and some product contexts will be shared too as well). Of course
there will be some cases when Windchill instances should be merged - for
example acquisition of the company when common products data should
exist in one Windchill instance.

p.s.: just thinking loudly and trying to come up with differrent ideas.


Thansk,
Dmitry

[patrick.chin1]

Stating the same question as I did in the other post:

What issues did you guys have with working with multiple organization containers?Do you have thedetails in terms of methodologies and rules did you fail?

[patrick.chin1]

In response to my own question, the reason why I'm asking because there are cases where you apply OIRs and ACLs at all levels from SITE, Organization, Program, Project, Product, Library and Domain (folder) level for fine tuning, standardizing and globalizing your controls.There are cases where OEMsand partners may have their own information that specifically belong to them and your internal assemblies call out the the top assemblies. If you efficiently use Supplier Management, they can check into their ownorganization context and ORGID tied/associatedto thier own MFG or supplier part. Or you can call itin your internal ProE BOM without any conflicts of number and organization. Hence, full collaboration. Sometimes using the ProjectLink workspaces are confusing because ProE users just like to check in their top assemblies.

I haven't had issues with multiple orgs.