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; } } }

Resuing Content between various sites from two branches

dineshkumar

Dear All,

Following is my requirement, please suggest me which approach I should choose.
My current application design:
We have a branch(Branch-A) with a workarea. It has 100+(multilingual) sites in it. DCRs are used for managing content.

New requirement:
We have to manage content for a new application, where as 50% of the content are same which we have in current workarea(Branch-A), which I mentioned above.
Following are the key points of the requirement:
1. Content from (Branch-A) needs to be used as it is for the new application. No user from the new application group should have modify access to (Branch-A) content.
2. No duplicate of content, as 50% are to be re-used

Approaches I thought of:
1. Just use the same branch and workarea for the new application and create sites in it. Create a new category for managing dedicated content for the new application and re-use the existing DCRs as it is. Set the permissions accordingly.
Challenge in this approach is. There are already 100+ sites in (Branch-A) workarea. If we will go with this approach, then the sites count will become double. Results in poor scalability. And Setting folder level permissions will become more complex.

2. Publish (Branch-A) workarea content to DB and use the db content in new application.
Challenge in this approach is, we have to publish all the existing content to DB first. And old components will render the content from DCRs but the new ones will render from DB.

3. Going with a new branch and workarea for the new application and copy the reusable content to the newly created branch and workarea from the existing one.
Challenge in this approach is, duplicating (50%) content and for any future change, we have to in corporate the same in two places.

Is there any other best approach or design? Please suggest with your ideas.

I am using : Autonomy Interwoven TeamSite 7.1.0 on windows

Find more posts tagged with

Comments

Adam Stoller

Of the three approaches you mentioned, this one would appear to be the best:

2. Publish (Branch-A) workarea content to DB and use the db content in new application.
Challenge in this approach is, we have to publish all the existing content to DB first. And old components will render the content from DCRs but the new ones will render from DB.

You could consider this as the beginning of a phased approach to replace old components with new components that use the DB.

I wouldn't suggest doing this too quickly. You'd want to make sure that the DB schema / table design supports the functionality you need (both what you know you need and what you can reasonably think of needing in the future) - then design the new components to provide the query input information you need to drive the different sites.

Once you get that done, and actually implement the new components - you can then carefully examine the old and new .page files ("old" using existing components, "new" using the new components) and try to determine a scripted manner of translating from one to the other. Such a script doesn't have to be too elegant, as it would be intended to get you through the transition - after which you would be able to get rid of the old components and then have no further need for the script.

Obviously, such a script would need to be tested thoroughly - to do that, you'd preferably have a DEV box that you can work on, with a copy of the PROD server's content, and an edition cut before you run the script so that you can easily get back to the original starting point to re-run the script as many times as it takes to "get it right".

The "big positive" in this approach is that the DB-driven site should be good performance-wise and scaleability-wise (both are assuming a well thought out design and implementation) - such that what you perceive as a "challenge" could be a golden "opportunity".

No - I have not "done this" - the above comments are just based on "gut" feelings given the information you provided. Personally, I think it would be an interesting (perhaps, dare I say it, fun) thing to work on; but that's me.

There might be additional alternatives beyond the three you mentioned - I'll leave it to other's to expand on such ideas - but of the three you mentioned, I truly think that this is the best approach.

dineshkumar

Dear Ghoti,

I always feel, Dev net is much much better as compared to support site in case of quick response for any type of queries/issues. This is due to you and few more guys with us. Thank you so much.

About the DB approach, this may lead in re-designing the existing components or else atleast in their current workflow (to map DCRs to DB). Whereas, I may have to convince business team to take it forward. Here, the existing application team don't want to undergo any change due to the intervention of new application. These are two different business groups. But as you highlighted the benefits, lets propose the golden opportunity to them, its their call to take it forward or not.

BTW, I gone through TS admin pdf, there I could see few explanations under "iwproxy_preconnect_remap" and "iwproxy_preconnect_redirect". Is there anything we could achieve this requirement using these two features?

XML_Scripted Data Source_using_E4X__cwong.rptdesign

ISCBorisB

BTW, I gone through TS admin pdf, there I could see few explanations under "iwproxy_preconnect_remap" and "iwproxy_preconnect_redirect". Is there anything we could achieve this requirement using these two features?

Doubt it. You use iwproxy to configure access to various resources of your (Customer) Web Server, not TS Web Server.

To elaborate a little, TeamSite's web daemon (iwwebd Module) redirects all http requests to either servletd for the TS Store
access or iwproxy to access Customer Web Server. These two are mutually exclusive. DC Form Editing goes through servletd,
proxy server is not used for that.

Karthik_SP

If this content is going to be used in Livesite and the requirement is to show the DCR content directly without any search, then you can read the DCR directly in the LSDS.
When DCR is deployed to Server A from Branch A or from Branch B, DCR will be going to the same path in the Server A. So both the sites in the Branch A and B will be having access to all the contents in LSDS. This will not work in SitePublisher where you have to build the folders from root to get the data.

dineshkumar

Boris,

Thanks for providing the information about proxy remap and redirect.

Karthik,

Yes as you said, there will not be any issue in runtime, as there is no branch and workarea concept there. But Authors will not have an option to see the actual page without deploying it to any runtime environment.

To provide this feature, then we may have to customize the tool behavior, which leads in various other issues.

Seems, there is no other option to reuse the content with out DB approach. Else we may have to use the existing branch for the new application as well.

Thanks for all your support. Will update once, the design is finalized. Beside, I am open to think through further suggestions, from others.