Реализация шаблона публикации контента

Пакеты Publishing Web Content Management, Portal Document Manager и персонализация артефактов в WebSphere Portal V6.0

В статье рассказывается о том, как архитекторы могут координировать размещение или перенос всех находящихся на портале артефактов контента из среды разработки или тестирования на рабочий сервер. В понятие артефактов контента портала включается всё, что хранится в IBM Workplace Web Content Management (далее - Web Content Management), Portal Document Manager (далее - Document Manager) и WebSphere Portal Personalization (далее - Personalization).

В сценарии предполагается, что вы публикуете контент, соответствующий правилам персонализации, при исполнении которых возвращаются документы из определенной папки библиотеки документов. Вы увидите, как опубликовать весь имеющийся в хранилище портала контент.

При прочтении статьи пригодится, однако не обязательно, хорошее понимание XML и понимание синдикации Web Content Management. В Информационном Центре WebSphere Portal V6.0 вы найдёте более подробную информацию о синдикации Web Content Management.

Олусола Омосайе, сотрудник службы технического обеспечения клиентов, IBM Workplace Web Content Management, IBM

Олусола Омосайе (Olusola Omosaiye) работает программистом в IBM Research Triangle Park в Северной Каролине. Он занимает должность специалиста по техническому обеспечению клиентов в подразделении IBM Workplace Web Content Management and Portal Content.



19.04.2010

Введение

Предполагается, что вы уже разместили управляемый Web Content Management и Document Manager контент в WebSphere Portal V6. Вы уже организовали для своих пользователей целевое распределение контента, основанное на профилях, определенных в объектах, таких как пользовательская информация на портале. Также вы организовали целевую доставку контента в зависимости от локальной и прочей информации, которую можно получить из браузера пользователя.

Теперь все готово к началу работы. Для этого вам надо определить повторяемый процесс для перемещения правил, документов и Web-контента со своих тестовых серверов на рабочие.

Например, на рисунке 1 показано правило, которое вы можете создать для поддержки функций персонализации вашего портала.

Рисунок 1. Правила персонализации для примера сценария портала
Рисунок 1. Правила персонализации для примера сценария портала

В этом сценарии, как показано на рисунке 2, вы обращаетесь ко всем документам в библиотеке Document Manager.

Рисунок 2. Документы в библиотеке Document Manager
Рисунок 2. Документы в библиотеке Document Manager

В Web Content Management есть сущности, так называемые компоненты персонализации и компоненты Document Management, которые ссылаются на правила Portal Personalization и документы Portal Document Manager. Эти артефакты являются локальными для установки Web Content Management. Такое размещение правил и документов создает определенные проблемы при развертывании в среде поэтапного развертывания, поскольку они недоступны из рабочей среды даже после синдикации. Среды поэтапного развертывания позволяют провести тестирование контента до того, как он будет размещен в рабочей либо «публикационной» среде.

В данной статье представлен шаблон, определяющий повторяемый процесс, с помощью которого можно управлять передачей контента портала. Мы начнём с описания процесса публикации, настройки задач Портала и Web Content Management для осуществления экспорта и импорта контента Портала, а в заключение дадим определение всего повторяемого процесса.


Обзор процесса

В данном шаблоне процесс состоит из трёх основных этапов.

Во-первых, вы настраиваете Web Content Management, чтобы стала возможной публикация его компонентов, включая элементы Personalization и Document Manager.

Во-вторых, вы добавляете в настройки WebSphere Portal задачи на экспорт и импорт библиотек документов и папки с правилами персонализации. Эти задачи добавляются и в исходную, и в целевую установки WebSphere Portal.

И, наконец, вы определяете сам процесс, руководящий переносом всех трёх групп артефактов на рабочий сервер.


Настройка Web Content Management

Компоненты разработки Web Content Management (такие как компоненты персонализации) по умолчанию создаются в "живом" (Live) состоянии. Наш сценарий основывается на синдикации в пределах "живых" элементов. После создания любого компонента разработки (включая любой компонент персонализации или Document Manager) он становится "живым", а следовательно – переносится в рабочую среду.

Чтобы смягчить действия сценария по умолчанию, вам следует выполнить следующие три шага:

  1. Добавить рабочий поток (workflow) для компонентов.
  2. Создать простой рабочий поток утверждения, который будет запускаться всякий раз при создании компонента в данной библиотеке.
  3. Создать пару синдикатор/абонент с использованием специальной библиотеки, состоящей из «живых» элементов.

Добавление рабочего потока для компонентов

Чтобы добавить рабочий поток, надо:

  1. Разместить и открыть файл WCMConfigService.properties на тестовом сервере в папке <WPS_HOME>/wcm/shared/app/config/wcmservices.
  2. Найти раздел # control properties.
  3. Поменять control.Cmpnt=key на
    control.Cmpnt=com.aptrix.pluto.workflow.WorkflowControl

Установка процесса рабочего потока утверждения

Добавив рабочий поток для компонентов, можно переходить к установке процесса рабочего потока Web Content Management. Этот процесс позволит нам контролировать, когда и какие компоненты разработки надо синдицировать или переносить в рабочую среду.

Наш процесс рабочего потока должен состоять по крайней мере из 2-х этапов. На первом этапе процесса рабочего потока не должно быть потоковых действий, связанных с вводом либо выполнением шагов, поскольку это этап "проектирования". На рисунке 3 показан пример первого этапа рабочего потока.

Рисунок 3. Первый этап рабочего потока - этап "проектирования"
Рисунок 3. Первый этап рабочего потока - этап 'проектирования'

Следующий этап рабочего потока должен содержать действие - публикацию, связанное с выполнением ввода на данном этапе, как показано на рисунке 4.

Рисунок 4. “Живой” этап рабочего потока
Рисунок 4. “Живой” этап рабочего потока

На рисунке 5 показан портлет Web Content Management Authoring при создании компонента персонализации с поддержкой рабочего потока. Здесь также показан рабочий поток, который мы создали выше.

Рисунок 5. Создание компонентов разработки в рабочих потоках
Рисунок 5. Создание компонентов разработки в рабочих потоках

Подробнее установка рабочих потоков описана в Информационном Центре WebSphere Portal

Установка синдикации между тестовой и рабочей средами

На предыдущем этапе мы создали компоненты. Для их публикации при помощи синдикации Web Content Management нам понадобится контролировать временные рамки передачи наших компонентов в рабочую среду. Получить этот контроль можно, выбрав библиотеку в качестве источника и выделив для синдикации исключительно “живые элементы". Синдикатор мы определяем через Portal Administration Portlet. В Информационном Центре WebSphere Portal вы найдёте более детальное разъяснение создания пары синдикатор/абонент.

Рисунок 6. Определение синдикатора для области “живых элементов”
Рисунок 6. Определение синдикатора для области “живых элементов”

Чтобы выделить для синдикации только "живые" элементы, надо:

  1. Нажать кнопку Add libraries.
  2. Выбрать PublishCompLib и, как показано на рисунке 7, поставить переключатель в положение Live items ("живые" элементы).
Рисунок 7. Установка синдикации библиотеки только на “живые элементы”
Рисунок 7. Установка синдикации библиотеки только на “живые элементы”

Настройка Document Manager и Personalization

Настроив Web Content Management так, чтобы мы могли контролировать передачу компонентов из тестовой в рабочую среду, перейдем к передаче документов и правил.

Нам предстоит настроить имеющуюся утилиту импорта/экспорта путем внесения изменений в XML-файлы конфигурации, находящиеся в каталоге <WPS_HOME>/jcr/migration/conf. Кроме того, чтобы разрешить вызовы задач импорта и экспорта из исходной и целевой сред, вам надо добавить новую цель в настройки задач WebSphere Portal.

Настройка Portal Document Manager и передачи XML посредством Portal Personalization

В пакете, который вы можете загрузить в конце статьи, есть готовое определение задачи для WebSphere Portal - pzn-pdm-Import-Export.xml. В этой задаче упрощается реализация экспорта и импорта документов и правил. Вам надо будет правильно настроить файлы pzn_conf.xml и pdm60_s2p_conf.xml, находящиеся в каталоге <WPS_HOME>/jcr/migration/conf.

Для установки настроек для вашей среды выполните нижеуказанные шаги.

Настройка экспорта и импорта XML в Portal Personalization

  1. Загрузите код с примером и извлеките из zip-архива файл pzn_conf.xml.
  2. Найдите и отредактируйте нижеуказанные элементы, определяющие тестовую и рабочую среды (см. рисунок 8):
    SourceServerPort
    TargetServerPort
    ExportNode   ссылается на путь к вашей папке с правилами, должен начинаться с “/”
    SourceExportData
    TargetExportData
    SourceRepositoryUserId
    SourceRepositoryPassword
    SourceWorkspace  должен быть RULESWORKSPACE
    TargetRepositoryUserId
    TargetRepositoryPassword
    TargetWorkspace

    Важно: в файле XML Source относится к тестовой среде, а Target - к рабочей.

    Рисунок 8. Настройка элементов pzn_conf.xml
    Рисунок 8. Настройка элементов pzn_conf.xml
  3. Убедитесь, что в командах экспорта и импорта у вас установлен правильный URI. Правильным URI является:
    Рисунок 9. Установка URI для команд экспорта/импорта в pzn_conf.xml
    Рисунок 9. Установка URI для команд экспорта/импорта в pzn_conf.xml
  4. Сделайте резервную копию файла pzn_conf.xml, находящегося в <WPS_HOME>/jcr/migration/conf.
  5. Замените файл pzn_conf.xml тем, который вы загрузили и настроили на первом шаге.

Настройка экспорта и импорта XML в Document Manager

  1. Извлеките файл pdm60_s2p_conf.xml из загруженного примера.
  2. Найдите и отредактируйте следующие элементы так, чтобы они подходили для тестовой и рабочей сред, см. рисунок 10:
    MigDirSource
    MigDirTarget
    SourceServerPort
    TargetServerPort
    ExportUserId
    ExportPassword
    ImportUserId
    ImportPassword
    DocLib – Библиотека документов, хранящая ваш контент. 
    Рисунок 10. Элементы pdm60_s2p_conf.xml
    Рисунок 10. Элементы pdm60_s2p_conf.xml
  3. Сделайте резервную копию файла pdm60_s2p_conf.xml, находящегося в <WPS_HOME>/jcr/migration/conf.
  4. Замените файл pdm60_s2p_conf.xml тем, который вы загрузили и настроили на первом шаге.

Подробное описание настроек данных файлов XML вы найдёте в Информационном Центре WebSphere Portal, отыскав тему “Staging to Production” (от тестирования к работе).

Добавление задачи настройки в WebSphere Portal

  1. Извлеките pzn-pdm-Import-Export.xml из пакета, который вы загрузили.
  2. Скопируйте этот файл в свой каталог <WPS_HOME>/config/includes .
  3. Добавив задачу, проэкспортируйте контент с помощью таких конфигураций:

    Экспорт: WPSconfig[.bat|.sh] export-pdm-pzn-data

    Импорт: WPSconfig[.bat|.sh] import-pdm-pzn-data


Замечания по процессу передачи контента

Процесс импорта требует, чтобы вначале на рабочий сервер передавались элементы содержимого портала. Каждая корпоративная среда имеет свои уникальные требования безопасности и правила допуска к данным, свои уровни и зоны безопасности. Например, некоторые правила могут разрешать общее пользование файлами на серверах в разных зонах безопасности, а некоторые – не более чем протокол FTP в рамках одной зоны. Таким образом, метод передачи данных мы оставляем на ваше усмотрение.

Можно предположить следующие варианты:

  1. Общий доступ к файлам
  2. Samba
  3. FTP

Поскольку импорт и экспорт процессов может осуществляться при работающем сервере WebSphere Portal, можно автоматизировать экспорт, импорт и передачу элементов. Однако в вашей организации могут быть запрещены методы удалённого доступа или хранение паролей в файлах, что необходимо для автоматизации. Поэтому метод автоматизации мы тоже оставляем на ваше усмотрение.

Можно предположить следующие варианты:

  1. Скрипт типа Ant (например, использовать задачу FTP, обратиться к сервису rexec и установить расписание заданий, используя, например, cron)
  2. Скрипт командной оболочки
  3. ПО для автоматизации

Процесс публикации контента

Процесс передачи настроек и контента был описан выше. Теперь рассмотрим итерационные шаги публикации данных на рабочем сервере.

  1. Создание документов в библиотеке Web Content Management.
  2. Возможно, создание правил персонализации для выбора документов, созданных на первом шаге. В нашем сценарии для выбора этих документов используются правила персонализации. Можно пойти другим путем, применив контент Web Content Management, использующий компонент Document Manager.
  3. Разработка компонента Web Content Management для потребления артефактов.
  4. Проверка компонента на исходном сервере на предмет соответствия требованиям путём просмотра контента в Web Content Management.
  5. Описанный в разделе Добавление задачи в настройки WebSphere Portal запуск настроек export-pdm-pzn-data и import-pdm-pzn-data на исходном и целевом серверах в соответствии с принятым в вашей организации методом передачи данных.
  6. Проверка наличия артефактов на целевом сервере.
  7. Утверждение компонента Web Content Management на целевом сервере. На этом шаге компонент с этапа планирования переходит на этап публикации.
  8. Просмотр реального сайта с компонентом Web Content Management.

Заключение

В данной статье определен шаблон публикации контента, позволяющий вам сконструировать бизнес-процесс с помощью готовых средств. В зависимости от местоположения документов и правил вы можете установить тестовую и рабочую системы однократно или несколько раз. Затем с помощью ручного или автоматического процесса, использующего указания из раздела Передача контента, и синдикации Web Content Management вы можете перемещать контент из тестовой в рабочую среду.


Загрузка

ОписаниеИмяРазмер
Пример кодаcontent-transfer-xml.zip6 КБ

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=WebSphere
ArticleID=483781
ArticleTitle=Реализация шаблона публикации контента
publish-date=04192010