¿Cómo puedo utilizar mejor Tridion Broker como única fuente de contenido para múltiples sitios web?

Question

Estoy trabajando en esta implementación de Tridion que tiene un montón de sitios web muy diferentes, pero algunos contenidos (como noticias) se comparten a través del principio básico de Tridion de creación de planos. Los sitios están todos en el mismo idioma, por lo que solo nos ocupamos de las diferencias de marca.

Situación actual: Existe una publicación llamada Contenido global en la que se crea este contenido global. En el esquema, se pueden seleccionar algunas casillas de verificación donde debe aparecer una publicación secundaria de este contenido. Cuando el componente se guarda, el sistema de eventos se activa y crea páginas con los componentes, lo publica, etc. No ocurre la eliminación de los componentes, solo un resave con todas las casillas de verificación sin marcar eventualmente eliminará las páginas mediante un proceso por lotes. .

Corredor situación: Me gustaría comenzar a utilizar el intermediario. Más aún, porque en la situación futura los sitios web también comenzarán a compartir más contenido en sitios web externos, lo que yo iba a hacer a través de fuentes RSS o una API básica, que funciona mejor con el contenido del Broker.

Los escenarios:

1. permitir que esta publicación de contenido global para publicar contenido dinámico, y en los otros sitios de extracción que el contenido directamente desde el Broker
2. Marca (con el ID de publicación de contenido global?) un objetivo vacío falso en contenido global para que puedan decir "publicar/anular publicación en todas las publicaciones secundarias"? (Todavía puede usar las casillas de verificación para permitir su publicación en ciertas publicaciones)
3. ¿Utiliza un sitio web de contenido global para publicar contenido dinámico y crear los feeds de API/RSS para que los usen los sitios web internos y externos?
4. ¿Algo más?

Mi pensamiento inicial se dirige al primer escenario, pero puedo ver el inconveniente principal de que sería más difícil mezclar noticias locales (izadas) y noticias globales.

El segundo escenario parece ser la segunda mejor oportunidad. ¿Alguien tiene experiencia con una implementación como esa?

Answer 1

En la implementación en la que estoy trabajando estamos utilizando algo así como la segunda solución. Agregué la publicación principal del sitio web (en la que creamos todas las páginas) al objetivo de publicación que usamos para todos los sitios web, de modo que podamos usar publicar en todas las publicaciones secundarias desde allí. Si encaja en su modelo, preferiría esta opción ya que continúa otorgándole el control sobre los artículos mediante la localización en publicaciones para niños.

Dado que no teníamos ganas de tener el contenido presentado en la publicación principal del sitio web (ya que esto no va a ninguna parte y será un desperdicio del tiempo de procesador de editor y también un desperdicio de almacenamiento intermediario cuando se pone implementado), creamos un ChildOnlyPublicationResolver (SDL Tridion 2011). En esta resolución, examinamos todos los ítems resueltos, y si el ítem proviene de la publicación principal del sitio web, lo eliminamos de la lista.

El resultado es que verá que la publicación principal del sitio web aparecerá en la cola de publicación, pero se establecerá en el éxito casi instantáneamente, ya que no hay nada que mostrar en ella. Por lo tanto, no requiere ningún rendimiento del editor ni se implementa, pero usted conserva el beneficio de las publicaciones de su hijo y tiene una forma fácil de publicarlas de una sola vez.

Si está interesado, aquí es un ejemplo para el código de resolución:

using System.Collections.Generic; 
using Tridion.ContentManager; 
using Tridion.ContentManager.Publishing; 
using Tridion.ContentManager.Publishing.Resolving; 

namespace SDL.Example.Resolvers 
{ 
    public class ChildOnlyPublicationResolver : IResolver 
    { 
     /// <summary> 
     /// Master Publication TCMURI 
     /// </summary> 
     private const string MasterPublicationTcmUri = "tcm:0-2-1"; 

     /// <summary> 
     /// For publish and unpublish, remove all items from the master publication from the list. 
     /// </summary> 
     /// <param name="item">Item to be resolved (e.g. a page, structure group, template)</param> 
     /// <param name="instruction">Resolve instruction</param> 
     /// <param name="context">Publish context</param> 
     /// <param name="resolvedItems">List of items that are currently to be rendered and published (added by previous resolvers in the chain)</param> 
     public void Resolve(IdentifiableObject item, ResolveInstruction instruction, PublishContext context, Tridion.Collections.ISet<ResolvedItem> resolvedItems) 
     { 
      List<ResolvedItem> itemsToRemove = new List<ResolvedItem>(); 
      TcmUri masterPublicationUri = new TcmUri(MasterPublicationTcmUri); 

      // check for items from master publication (these do not need to be published or unpublished) 
      foreach (ResolvedItem resolvedItem in resolvedItems) 
      { 
       // mark all items from website structure publication for removal 
       if (resolvedItem.Item.Id.PublicationId == masterPublicationUri.ItemId) 
       { 
        itemsToRemove.Add(resolvedItem); 
       } 
      } 

      // remove all items that we need to discard 
      foreach (ResolvedItem itemToRemove in itemsToRemove) 
      { 
       resolvedItems.Remove(itemToRemove); 
      } 
     } 
    } 
} 

Answer 2

En una arquitectura tradicional Tridion, la mejor opción podría haber sido para heredar a través del proyecto. Esto significaría tener el contenido disponible en todo el agente en todas las publicaciones, y determinar qué elementos mostrar a partir de los metadatos.

Como Bart ha sugerido, hay algunos aspectos dispendiosos en este diseño, por lo que podría pensar en términos de que el contenido global esté "federado" en un único sitio web. Para esto está destinado el servicio web de Content Delivery. Si está en Tridion 2011, puede elegir efectivamente su opción 3, pero con más soporte inmediato de lo que solía estar presente, por lo que no tendría que crear la API, solo consumirla.