cancel
Showing results for 
Search instead for 
Did you mean: 

Best Practices for Organization use in Multi-site

Valued Contributor
Valued Contributor

Hi everyone,

 

I'd appreciate some opinions on something that I've been meaning to take care of for a while...

 

We have 3 sites each with their own Organization and local users created in those sites. In most cases, the users work in their home site and don't need to login to any of the remote sites. We do have some users that work in all three databases depending on projects they are assigned to. For these users we've created accounts for them at the remote sites (same username/person, etc that exists in their home site). We did this back in TCeng and was suggested to do so by UGS Services at the time. 

 

I know that there are a number of ways to share organization objects now, and I'm wondering what the best way to manage a global organization is. We are growing and I have about 200 users (vs the 20 or so currently) that will need access to all 3 databases. I would rather not have to manage each of these users individually, even though make_user is simple enough, it is a pain when someone quits and you have to make them Inactive in each site.

 

Is there a suggested way to manage orgs like this? I'm really interested to hear how others are doing it, I'm sure I could make some adjustments to make this easier on us.

Thanks for any suggestions!

Jeff

7 REPLIES

Re: Best Practices for Organization use in Multi-site

Solution Partner Phenom Solution Partner Phenom
Solution Partner Phenom

With site consolidation being more the normal instead of the exception, I haven't had a lot of opportunity to administer multisite these days. However, I can offer some advice despite not knowing which flavor of multisite you employ to share objects:

  • Classic Multisite (Item Regisitry, ODS and IDSM).
  • Global Multisite (J2EE, INSWEB: Global Services Framework and BPEL).
  • Briefcase Browser.
  • Export/Import (PIE), aka the poor man's multisite.

The best practice is to have all users defined at all sites. The reasons are multifold but mainly it is to retain the owning user when sharing objects across sites. If the user doesn't exist at the importing site then the user running the import will become the owning user.

 

The quality of this advice is dependent on which Teamcenter version you're running, assuming you're running the latest Tc11.2.1:

  • admin_data_export, admin_data_import

For older version of Teamcenter, the data_share utility is best. I avoid running make_user at each site since this will create "unique" users that don't have the same PID. Basically, they have the same name but are unique at each site which doesn't help when you start sharing objects owned by those users.

 

You may also employ the Multisite Administration utility (MSA) which is a separate download from GTAC (not included in the install media) to help you compare objects across sites and create reports. A little known feature of this utility is the ability to populate a folder with Items.

 

Now you know, the best practice is to share all users at all sites and to use admin_data_export and admin_data_import to share administrative data across sites (and across environments like DEV, TST and PRD).

 


Randy Ellsworth, Teamcenter Architect, Applied CAx, LLC
NX 11.0.1.mp01 | SW 2016 | TcUA 11.2.3
Evaluating:AW 3.2

Re: Best Practices for Organization use in Multi-site

Valued Contributor
Valued Contributor

Hi Randy, Thanks for the response.

We are currently utilizing Classic Multisite.

I'm running 10.1.4 on windoze in production right now.

 

My multisite experience is pretty much self taught and whatever UGS services told me during config about 7 years ago. I was instructed to create a person/user at each site that matched the user's master site person/user info. From what I understood, users that performed a multisite export to another site (where the same username existed), the replica objects would be owned by that user. If the same user didn't exist, the objects would be owned by the user that the IDSM service in windows is running as.This also seems to behave as I explained above.

 

The above seems to be working as I explained, but based on your comments, it seems like it shouldn't? All of the user accounts that I've created at the remote sites were most likely created via the Organization gui, or possibly make_user, it was a long time ago and can't remember. So in that case they wouldn't have the same PID. I did verify a some data at the remote sites, and all the remote objects are owned by the proper people.

 

We are running MSA on a regular basis, but I can't wait for the day that we don't have to. I just wish the sync jobs we run daily would actually work completely, there seems to always be something to clean up.

 

So at this point, now that I have some manually created users at the replica sites that already own a lot of replica objects, what would  you suggest that we do moving forward? Just let the existing users live "as is" and use Data_share to import my remote users as replicas? Something else?

 

 

Thanks again,

Jeff

Re: Best Practices for Organization use in Multi-site

Solution Partner Phenom Solution Partner Phenom
Solution Partner Phenom

Like I said initially, it's been a while.

 

My recommendation is to use the new admin utilities to share the entire users group across all your sites. Then use the db compare utils to validate that you didn't miss any. Hopefully this action will reduce the number of stubs that get created when importing data.

 

I don't know if Siemens is still offering their Site Consolidation class that enables you to use the sitcon tools but I also recommend that you try and attend that class (you get a key at the end of the class). You'll be shocked by how fast you can share data using the tcxml_export/import tools. It will change your life, I know because I'm a key owner.

 

Best,

/Randy


Randy Ellsworth, Teamcenter Architect, Applied CAx, LLC
NX 11.0.1.mp01 | SW 2016 | TcUA 11.2.3
Evaluating:AW 3.2

Re: Best Practices for Organization use in Multi-site

Siemens Valued Contributor Siemens Valued Contributor
Siemens Valued Contributor

Have you tried out Global Org? Teamcenter documentation will have the relevant information.

Please see :

Home > Sharing Data > Multi-Site Collaboration > Introduction > Multi-Site basic concepts > Global Organization objects

 

Best Regards

Projyal Dev

Re: Best Practices for Organization use in Multi-site

Valued Contributor
Valued Contributor

RandyEllsworth wrote:

Like I said initially, it's been a while.

 

My recommendation is to use the new admin utilities to share the entire users group across all your sites. Then use the db compare utils to validate that you didn't miss any. Hopefully this action will reduce the number of stubs that get created when importing data.

 

I don't know if Siemens is still offering their Site Consolidation class that enables you to use the sitcon tools but I also recommend that you try and attend that class (you get a key at the end of the class). You'll be shocked by how fast you can share data using the tcxml_export/import tools. It will change your life, I know because I'm a key owner.

 

Best,

/Randy


I'll take a look and see, I'm sure they still have something. We are looking to cut down from 3 to 2 after we upgrade to NX10 (from 8.5), so we'll need to do some work in the site con area anyway.

 

I have to say, after living w/ classic for so long...there is a lot of room for improvement, not only in performance, but ease of maintenance and replica management.

Thanks again,

Jeff

Re: Best Practices for Organization use in Multi-site

Valued Contributor
Valued Contributor

Projyal wrote:

Have you tried out Global Org? Teamcenter documentation will have the relevant information.

Please see :

Home > Sharing Data > Multi-Site Collaboration > Introduction > Multi-Site basic concepts > Global Organization objects

 

Best Regards

Projyal Dev


Projyal,

No, as I mentioned, I was looking for the best practice. I have looked at the options, but wanted to get feedback on what others have used to make a more informed decision.

 

It looks like there are some options out there that could help cleanup my few "cloned" organization objects. Has anyone used the migrate_organization command? Am I correct in assuming that if I have the following Org at two sites.(I hope formatting works here)

 

  •  Site A
    • Design
      • John
      • Jane
      • Jack
    • Manufacturing
      • Ken
      • Karl
      • Kelly
  • Site B
    • Design
      • Chris
      • Chad
      • John
      • Jane
      • Jack
    • Manufacturing
      • Shawn
      • Seth
      • Sara
      • Ken
      • Karl
      • Kelly

Site A is the home site for all users in Site A. Site B is only the home site of the users that don't exist in Site A (the users in Site B that exist at Site A were created with the Make_user utility, and aren't shared using data_share or dsa, etc).

 

Does Migrate_Organization help make Design, Manufacturing, John, Jane, Jack, Ken Karl, and Kelly replicas in Site B? I assume that is the ideal scenario, right?

Re: Best Practices for Organization use in Multi-site

Creator
Creator

Also using make_user as scheduled tasks and scripts to sync org. Tried the Global Org. concept, but it doesn't work in 9.1 which we are running today (will fail with inactive users). Also the other data_share utilities haven't worked for organization objects in the current version.

 

Will need to try Global Org. again when we soon upgrade to TC 10.1. Planning to use the migrate organization tools to fix the issue of duplicate users.