Импорт продукта в Adobe CQ5

У меня есть вопрос о том, как мы можем импортировать/синхронизировать продукты из нашего бэк-офиса с интерфейсом CQ5.

Архитектура должна быть довольно простой - собственный бэк-офис, управляющий всеми продуктами (по сути, это будет источник правды). Веб-сайт, управляемый CQ5, для отображения результатов поиска (управляемый Adobe SearchAndPromote) и сведений о продукте. Транзакции покупки будут обрабатываться за пределами CQ5.

Я просмотрел http://dev.day.com/docs/en/cq/current/ecommerce/eCommerce-framework.html, и я думаю, у меня есть некоторое представление о том, в каком направлении нам следует двигаться, но я хотел бы, чтобы кто-нибудь подтвердил правильность моего понимания.

1) Мне нужно создать запланированное задание, работающее на узле Author, которое будет вызывать бэк-офис и импортировать продукты в виде json-канала. Я использую @Service(Runnable.class) на основе аннотаций. Есть ли способ настроить его так, чтобы он запускался только на узле Author?

2) Создайте собственную службу (названную моей службой выше), которая фактически создаст все узлы в crx. Если у меня есть настольная и мобильная версии сайта, нужно ли мне создавать все эти настройки дважды? Есть ли какие-нибудь советы по более простому способу их создания?

3) Позвольте CQ5 реплицировать эти продукты для публикации узлов.

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

Ваше здоровье.


aem sling jcr
person Kostya    schedule 31.01.2013    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Вот несколько ответов:

1) Вот хорошая статья о разных конфигурациях для разных режимов работы: http://helpx.adobe.com/cq/kb/RunModeSetUp.html вы можете создавать конфиги для режимов запуска pub и auth с определенным флагом, который будет искать ваш код, который скажет, выполнять ли импорт или нет.

2) Это зависит. CQ имеет тенденцию иметь копии контента для мобильного сайта, поэтому может иметь смысл делать копии узлов для мобильного сайта, но только в том случае, если эти узлы являются страницами (cq:Page и cq:PageContent), которые вы создаете на основе импортированных данных. В противном случае вам просто нужно где-то сохранить импортированные данные и получить их в какой-то момент (с помощью запросов JCR или методов, таких как .getNode()). В этом случае, конечно, имеет смысл не копировать ваши данные.

3) Здесь тоже все зависит. Я бы рассмотрел следующие факторы, которые могут возникнуть у вас: должны ли импортируемые данные быть редактируемыми? как часто обновления? насколько массовыми являются обновления? насколько критична согласованность между пабами? В случае, если обновления не являются массовыми, не частыми и имеют значение согласованность, импорт для аутентификации с последующей репликацией может работать. Также это может быть в случае, если вам нужно иметь возможность редактировать импортированные данные. В случае массовых и/или частых обновлений, а согласованность между пабами не имеет большого значения (вы можете позволить, чтобы некоторые люди могли видеть разные результаты из разных пабов во время импорта), я бы предложил запустить импорт во всех пабах одновременно, так как массовая репликация импортированных данных может повлиять на регулярную репликацию страниц/изображений.

Спасибо, Макс.

person Maksim Kviatkouski    schedule 31.01.2013
comment
Привет Макс, спасибо за ответ. Могу я просто уточнить пару вещей? В настоящее время я использую сценарий, в котором я импортирую продукты и сохраняю их как cq: Pages, который отлично работает, за исключением двух вещей, которые мне очень не нравятся: я должен делать копию каждого продукта для каждого сайта; Контент кажется слишком привязанным к представлению. Итак, если бы я НЕ использовал cq:Page, как еще я мог бы сопоставлять URL-адреса (сохраняя их SEO-дружественные) с моим контентом, принимая во внимание, что CQ очень ориентирован на данные. - person Kostya; 01.02.2013
comment
Привет, Костя, если у тебя отношение продукт 1 к 1 → страница, я бы остался с ним. Вместо того, чтобы копировать данные о продукте в процессе импорта, вы можете использовать механизм развертывания, предложенный bit.ly/XXhUiL. от Adobe. Если вы хотите разделить содержимое и представление, вы можете использовать какое-то соглашение об именах. Скажем, страница /content/yourapp/catalogue/product1.html будет искать узел /var/import/products/product1. Также вы можете заполнить страницы ссылкой на импортированный узел. Таким образом, страница будет содержать свойство, указывающее на узел /var/import/products/product1. - person Maksim Kviatkouski; 01.02.2013