Number of Relator CCE Widgets in CTD

Has anyone else experienced issues with having multiple relator CCE widgets in a CTD? We have 7 relators in a single CTD. We were able to render everything fine using the data from these relators in preview. Once we 'deployed' and published to our DSM, we were getting a 500 server error. Through trial and error, we discovered that if we limited the number of relators to just 6, it was fine. Seems like 6 is the magic number. Or does this mean we have something wrong with our DSM configuration that is causing us to have this 500 server error? If so, where do we start looking?

Thanks!

Find more posts tagged with

Comments

Mario_DAnna

If you have 7 relators your design is certainly wrong. The editor, in any case, will be very slow. I strongly advise against using more then 2 or 3 relator in the same relation. It is a typical design mistake to start making too complex content types putting together and joining any sort of data to build sort of control panel where one can access any data from the same place….

Make smaller CTs and use links instead of relators.

There is no magic number, it is just that 7 relations (which means 7 joins and 7 full load of the content instance every time you open the editor) is probably too much.

At the extreme, I remember that I had once a customer that had designed a content type with 18 relators. The content instance was taking 10 minutes to load…..

Ciao

Mario

From: eLink Entry: Discussion Group - Web Experience Management [mailto:v7webcontentmanagement@elinkkc.opentext.com]
Sent: mercoledì 1 luglio 2015 16:37
To: eLink Recipient
Subject: Number of Relator CCE Widgets in CTD

Number of Relator CCE Widgets in CTD

Posted byhowellc@franklin.edu (Howell, Christine) On 07/01/2015 10:30 AM

Thanks!

[To post a comment, use the normal reply function]
Forum:	Discussion Group - Web Experience Management
Content Server:	Knowledge Center

William_Thayer

This is an excellent post, thank you Mario.

NOTE: "joins" and "time to load".

I have run into this as well, and seen systems where it took at least 5 minutes to load and most often timed-out before actually loading. Take care with the use of relations, and split up lengthy content types. It should be as simple as possible.

Will Thayer
Principal Consultant Technologist | Avalon Consulting, LLC
P: 720-480-2163

LinkedIn | Google+ | Twitter

On Wed, Jul 1, 2015 at 9:44 AM, eLink Entry: Discussion Group - Web Experience Management <v7webcontentmanagement@elinkkc.opentext.com> wrote:

RE Number of Relator CCE Widgets in CTD Posted bymdanna@opentext.com (D'Anna, Mario)On 07/01/2015 10:44 AM

If you have 7 relators your design is certainly wrong. The editor, in any case, will be very slow. I strongly advise against using more then 2 or 3 relator in the same relation. It is a typical design mistake to start making too complex content types putting together and joining any sort of data to build sort of control panel where one can access any data from the same place….Make smaller CTs and use links instead of relators.There is no magic number, it is just that 7 relations (which means 7 joins and 7 full load of the content instance every time you open the editor) is probably too much.At the extreme, I remember that I had once a customer that had designed a content type with 18 relators. The content instance was taking 10 minutes to load….. CiaoMario From: eLink Entry: Discussion Group - Web Experience Management [mailto:v7webcontentmanagement@elinkkc.opentext.com]
Sent: mercoledì 1 luglio 2015 16:37
To: eLink Recipient
Subject: Number of Relator CCE Widgets in CTD

Number of Relator CCE Widgets in CTD

Posted byhowellc@franklin.edu (Howell, Christine) On 07/01/2015 10:30 AM

Thanks!

[To post a comment, use the normal reply function]
Forum:	Discussion Group - Web Experience Management
Content Server:	Knowledge Center

[To post a comment, use the normal reply function]
Topic:	Number of Relator CCE Widgets in CTD
Forum:	Discussion Group - Web Experience Management
Content Server:	Knowledge Center

Christine_Howell

This still does not answer my question. There is a very good reason why we had this many relators. We have 8 tables - 1 primary table and the rest related by the userid. Very easy to set up the CTD. The data is scanned into the tables via vgncontentscan. Very nice and convenient setup. Works great too.

In preview we were successfully able to display our content using the CTD with all 7 relators. When we moved to DSM, all heck broke loose. We were finally able to determine that this was caused by the number of relators we had in our CTD. This worked fine with just 6 relators in the CTD for DSM. We decided to figure out which two tables we could combine into one and move forward.

Now I am trying to find out why we had this discrepancy between the preview environment and DSM environment. Is there a limitation we were unaware of? If no limitations, then what would be the deal breaker in the dsm environment? Where should we look?

DougForrest

Hi Christine,

I'm having a hard time understanding what you mean by preview vs. DSM. When you refer to DSM, are you just talking about your delivery stage? DSM (Dynamic Site Module) simply refers to the type of CPS (Content Presentation Services) that you are using. The options are DSM and DPM (Dynamic Portal Module). If you are using DSM, you are using it on both preview and delivery.

If you are talking about preview vs. delivery, there is no functional reason that it should behave any differently between the two in regards to relators. All of the product code (and presumably your custom code) should be identical between preview and delivery. Best practices aside, there is no hard limit in the product for the number of relations. You should not see an error when going from 6 relations to 7. At the worst, I would simply expect to see performance issues as has been already noted in this thread.

You mentioned a 500 error. That typically results in a stack trace in the app server log files. Can you share the actual stack trace? Also, have you opened a support ticket?

-Doug