nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Teamsite Best Practices

Balu110

In our current environment one team already using Teamsite extensively and deploying contents. Other team will start using the Teamsite in the near future. So I am trying to find some information whether to create a new store or share the existing store between the two teams.

To give some input, both teams has large amount contents (I can say about 1000 to 1500 files) and both of them need minimum of 8 G of hard disk space.
We are currently having TS 6.1 on Solaris. Their might have similar contents but % of similarity is less.

Can some one share their ideas, experience etc.,?

Alos is there any best practices document for creating and maintaining iw-store (backing store), Teamsite maintenance etc.,?.

Thanks in advance.

Find more posts tagged with

Comments

Adam Stoller

The Multi-Store feature is *there* - but to use it legally you need to purchase licences for it (last I knew they ran to about $50K per additional store) - so while this is a very useful feature, you need to consider the costs versus the expected gains.

1000-1500 files is *not* that large - 8gb also isn't all that large (my customer is currently using 552SP2b on Solaris8 with around a 20Gb backing store - we'll be moving to 6.5SP1 on Solaris 9 soon).

Also - if you haven't done it recently - you should probably run iwfsshrink on your existing backing store to find out if it's really 8gb or something [potentially significantly] less.

As for TS maintenance - I believe there's stuff in the documentation (aka RTFM), stuff in a number of KBs on DevNet and/or Support, and training classes available -- I suggest you look to those sources first as they should answer most of your needs.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

jed

One of the real benefits of multi-store is to split up the store onto multiple partitions. 8 gigs is really rather small, so you should have no problems using one partition and one backingstore.

Also, when you use multi-store, you cannot do a "Copy to area" across the stores, so sharing content becomes more non-standard.

--
Jed Michnowicz
jedm@sun.com
Content Management Engineer
Sun Microsystems

gzevin

Also, when you use multi-store, you cannot do a "Copy to area" across the stores, so sharing content becomes more non-standard.

I'd say even more. You can't do virtually anything with multiple store - no sharing the files from different stores in the workflow, etc, etc. They are virtually multiple separate TeamSite instances on one box.

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

jed

True. Good point. Backup/restore also gets interesting since all workflow is not stored with the specific store.

With that being said, I still like some of the benefits of multi-store, but an 8-gig site is usually not a reason to split things out.

--
Jed Michnowicz
jedm@sun.com
Content Management Engineering
Sun Microsystems

Balu110

It is interesting to note that we need to buy additional licenses for multiple stores. This I will check with my team.

I agree if we choose multiple stores then we can't share files, workflow and other features like copy to area etc., But the reason I asked the question is because recently we had a production problem where the workarea (files under $iw-store/workflow) got corrupted and people were unable to use the workflow tab. It took us some time to resolve the issue. So I thought creating multiple stores may help and when such problem occurs then the other team may not be affected. Correct me if I am wrong.

Thanks in advance,
balu

gzevin

you are wrong.

also, If you have such a serious issue it will reuire some serious actions to rectify, so it's very likely that your whole box will need to be brought down for check/fix

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

lhdavis

As a follow-up to this, is anyone actually USING multistore in a Production environment?

If so, how many stores do you have and what did you use for your logical divisions between content on one store versus another? Was it site specific, code specific (all .jsp application on one store versus .asp/.html on another)? And of course, what version of TeamSite and OS are you running?

Luke Davis
Open Technology Group, Inc.
luke.davis@med.va.gov

jbonifaci

The company I am currently at is using it. The break down was simple enough though. There are several individual areas that each have their own site(s) and development team. Each area has their own store for all of their branches.

6.1
w2k
6 stores

jed

We use it:

Solaris 9
TeamSite 6.1

We do a lot of backing store refreshes between our dev/test/prod server. Since our developers only care about 20% of the content, we store all that content on one specific store. This makes refreshing much faster.

Also, we have a branch with 20 gigs of content in it. (Yes--one branch!) Sometimes this leads to "bad" things happening, so we isolate this to its own backingstore so those bad things do not affect the other branches/stores in TeamSite.

One of the biggest hurdles when moving to multi-store is fixing **** code. We have had many developers over the lifetime of our installation make assumptions about vpaths and filesystem paths within TeamSite such as

if( -e myVpath){
...
}

In the above example, if the vpath happens to be '/default/main/WORKAREA/foo/file.text', this will probably work since '/default' is a symlink to /iwmnt during a TeamSite installation. Well, if the vpath happens to be '/store2/main/WORKAREA/foo/file.text', and no one manually created a symlink, the '-e' will always show the file as non-existant.

I have also seen a number of substitutions and matches with the assumption of '/default/main' always being there.

--
Jed Michnowicz
jedm@sun.com
Content Management Engineering
Sun Microsystems