Управление контентом Tridion и PDF (большой объем)

У нас есть 5000 PDF файлов, которые должны быть не более 200 гб. Они, вероятно, будут нуждаться в обновлении в течение года в партиях около 1000.

Как я вижу, есть два основных маршрута...

1) Публикация PDF и связанных с ним метаданных через Tridion 2) Импорт непосредственно в среду доставки и управление метаданными PDF в Tridion

Убедительная (деловая) причина для размещения этих PDF файлов через CMS - это путь к их производству - CMS = Easy - не-CMS = Нелегко вообще и контроль, который он дает непосредственно бизнесу.

Мы, конечно же, предпочли бы управлять метаданными, напрямую связанными с двоичным элементом, а также использовать компоновку ссылок (отслеживать, где используется и т.д.), а не сопоставлять компоненты (для метаданных) с "ссылками" на не связанные с CMS двоичный элемент - так что мне кажется через, CMS будет иметь больше смысла.

Теперь - возникает вопрос о раздувании базы данных/блокировании очереди публикации...

Некоторым из этих элементов может потребоваться пройти рабочий процесс (если мы выгружаем пакет через WebDAV, я предполагаю, что мы можем определить конкретные картриджи для определенных папок и, следовательно, связать разные схемы?). Однако использование WebDAV предположительно означает, что PDF файлы (и исторические версии) будут храниться в базе данных, что может быть проблематичным.

Итак... мы могли бы связать их в Tridion в качестве компонентов внешней ссылки, но я предполагаю, что это означало бы, что мы не могли бы использовать WebDAV (или мы могли бы использовать WebDAV с файлами externally_linked), похоже, это не имеет смысла? )

Я уверен, что большое количество исполняемых файлов, управляемых в (или около) CMS, - это то, что многие из нас встретили, и было бы очень интересно узнать, как другие подошли к этой дилемме?

Спасибо

Ответ 1

Просто чтобы ответить на ваш вопрос:

Итак... мы могли бы связать их в Tridion в качестве компонентов внешней ссылки, но я предположим, это означало бы, что мы не могли использовать WebDAV (или могли бы мы по-прежнему использовать WebDAV с файлами externally_linked - кажется, что он не делает смысл?)

Я не уверен, что это возможно с помощью WebDAV, но если вы решите пойти по внешнему мультимедийному маршруту, вы можете написать простое приложение для создания мультимедийных компонентов на основе каталога/каталогов хранения для файлов PDF.

Я видел реализацию, в которой использовалась определенная публикация, позволяющая пользователям размещать файлы и публиковать их через Tridion. Публикация, опубликованная в общей области, в которой была опубликована общая папка, была отображена на требуемые веб-сайты презентаций (виртуальный каталог в IIS).... поле пользовательской схемы было использовано, чтобы помочь пользователям выбрать, как вставлять pdf файлы в контент. Я знаю, это ОЧЕНЬ странное решение, но оно решило множество проблем с точки зрения простой конфигурации безопасности и публикации, а pdf файлы не были реплицированы в db через сине-печать/локализацию.

Ответ 2

Я думаю, что вы (или кто-то из вашей команды), должно быть, попросили об этом на форуме SDL Tridion. Если это не так, это гигантское совпадение, и посмотрите на предложения.

Я позволю другим перекликаться с их опытом, но если вы хотите использовать WebDAV, он всегда будет использовать загруженную версию мультимедийного компонента. Вы должны думать о внешних двоичных файлах как источнике только для чтения, который CMS не контролирует.

Как я уже сказал на другом форуме, я бы посоветовал вам добавить их в CMS, если вам нужен рабочий процесс, и управлять полномочиями пользователей на тех, кто может редактировать двоичные файлы. Если бы вы говорили Terra-байты, я был бы более заинтересован, но я не ожидаю большой проблемы для вашего размера данных.

Подумайте о том, чтобы запустить инструмент очистки довольно часто, чтобы удалить очень старые версии двоичных файлов и не забудьте некоторое время их публикации. Также публикуйте их небольшими партиями, так как публикация транзакций более 500 Мб является, как известно, интенсивной памятью.