Итак, я провел некоторое время, говоря о том, что вам может не понадобиться WebReport — так что давайте поговорим о том, когда вам следует подумать об использовании WebReport. Теперь у каждого консультанта-разработчика/OpenText будет свой собственный подход — и то, что я описываю, — это подход, который мы используем.

Речь идет о слоях

Примеры, которые мы использовали в предыдущих сообщениях по этой теме, мы, как правило, фокусировались на веб-вариантах использования, где мы расширяем пользовательский опыт в OpenText Content Server — этот пост ничем не отличается.

Однако в каждом из этих постов мы использовали следующую диаграмму в качестве приблизительного руководства о том, как подходить к этим проблемам.

Теперь очевидным вызовом здесь является Smart UI. Однако я бы сказал, что даже если вы используете виджет Smart UI WebReport для отображения настройки пользовательского интерфейса, вы ограничиваете фактическую функциональность тегов WebReport уровнем данных.

Я видел, как решения WebReport терпят неудачу, когда они делают две вещи:

  • Использование WebReports выше по стеку на бизнес-уровень и уровень представления
  • Замена существующего REST API специальным массивом WebReports (этот подход страдает от масштаба).

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

Установка

Чтобы продемонстрировать этот подход, мы создадим форму, которая будет выполнять следующие действия:

  • Создайте подключенную рабочую область и заполните ее метаданными.
  • Зарегистрируйте форму вместе с расположением рабочей области в базе данных Content Server.

Вспомогательные материалы — Категория

Дизайн категории будет иметь три поля:

  • Категория — которая будет поиском в базе данных
  • Подкатегория — поиск в базе данных в зависимости от категории.
  • И Тема

Вспомогательные материалы — рабочее пространство

Используя это (и некоторые другие материалы, например, классификацию), мы можем затем определить тип нашего рабочего пространства.

И шаблон рабочей области

Вспомогательные материалы — шаблон формы для ввода записей

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

  • Категория
  • Подкатегория
  • Предмет
  • Идентификатор рабочей области

Создав шаблон, мы хотим, чтобы записи сохранялись в базе данных Content Server. Для этого мы используем функцию «Управление реляционной таблицей».

И выбираем нашу базу

Вспомогательные материалы — Форма для подачи заявок

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

Давайте сделаем веб-отчет

На высоком уровне я планирую использовать в своей форме два WebReports:

  • который возвращает метаданные для формы
  • возвращает идентификаторы узлов в среде Content Server, которые мне понадобятся для выполнения вызовов REST API, которые мне понадобятся.

Веб-отчет по метаданным

Этот отчет вернет категорию и связанную с ней подкатегорию в одном сообщении JSON, которое будет использовано формой.

Есть много способов сократить этот отчет, мой подход к этим из них состоит в том, чтобы начать с простого и наращивать сложность сверху. Имея это в виду, у нас есть два LiveReports:

  • Тот, который возвращает все категории

  • Как только это вернет подкатегории для данной категории

Далее мы создадим WebReport вокруг этих LiveReports.

В этом случае использования — поскольку эти значения атрибутов не меняются постоянно (и, следовательно, статичны), мой план состоит в следующем:

  • Создайте WebReport, который возвращает все связанные категории и подкатегории.
  • Экспортируйте полученный JSON в место

Теперь запуск этого отчета вернет значение

Теперь, когда этот отчет возвращает статические значения, вместо использования REST API для подачи этого JSON в качестве статического актива.

Support Asset Volume существует с 16.2.10 Content Server (сентябрь 2019 г.). Чтобы использовать его, вам нужно убедиться, что вы настроили виртуальные папки на ваш веб-сервер и указал его в нужном месте.

Чтобы настроить местоположение, просмотрите раздел Support Asset Volume и создайте папку Support Asset.

!!! Предупреждение об ограничении !!!

На момент написания вы не можете экспортировать WebReport как узел в Support Asset Volume 😥😥

Как насчет версии? Нет…..но и да 😕😕. Во-первых, я создаю на своем компьютере два пустых файла JSON:

  • businessrequest.json — здесь будут храниться метаданные
  • Constants.json — он будет содержать различные узлы, которые мне понадобятся для выполнения запросов REST API.

Создав их, мы создаем два объекта поддержки в папке ресурсов поддержки.

Затем, если мы перейдем на вкладку назначения WebReport и выберем версию Content Server, мы обнаружим, что не можем выбрать фиктивные файлы.

Ах, но у нас есть константы. Чтобы обойти это, добавьте целевой файл JSON в качестве константы в WebReport.

Затем на вкладке назначения вместо просмотра объекта на Content Server мы используем значение [LL_REPTAG_$TargetJSON /].

И теперь, запустив это, мы видим, что добавляется версия

Тестирование этого узла через PostMan дает правильный ответ JSON 😁😁😁

Конфигурация веб-отчета

Конфигурация WebReport производится аналогично — однако в данном случае мы будем выводить статические константы, которые нам потребуются для создания нашего рабочего пространства, а именно:

  • Идентификатор родителя — где мы будем создавать рабочую область.
  • Тип — в данном случае это будет 848.
  • идентификатор типа рабочей области. Это можно сделать, перейдя к типу рабочей области на экранах конфигурации подключенной рабочей области.

  • и идентификатор шаблона — идентификатор рабочей области, которую мы используем для создания.

Воспроизводя те же шаги, мы экспортируем два статических файла json.

Создайте представление формы и объедините все это

Прежде чем мы начнем — учитывая, что мы делаем это на новой установке Content Server, есть одна новая зависимость WebReport, которую нам нужно обсудить.

Для новых установок старый добрый LLCookie теперь является файлом cookie только для HTTP. Это означает, что к нему больше нельзя получить доступ через JavaScript. Чтобы обойти это, мы нарушим наше основное правило и будем использовать WR Power View.

Нет, вместо запроса значения LLCookie мы можем использовать тег `[LL_REPTAG_OTCSTICKET /]` в нашем WR Power View.

Однако вся остальная логика, значения JSON будут обслуживаться статически. А с помощью HTML из моего предыдущего поста я могу привести форму в порядок.

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

Итак, мы меняем это

<INPUT class="valueEditable dlvalidate" TYPE="text" NAME="_1_1_2_1" TITLE="Category" ID="_1_1_2_1" VALUE="[LL_FormTag_1_1_2_1 /]" SIZE="32" MAXLENGTH="32" ONCHANGE="markDirty();">

Что-то вроде этого:

<select class="valueEditable dlvalidate binf-form-control" NAME="_1_1_2_1" TITLE="Category" ID="_1_1_2_1">
  <option>Select Category</option>
</select>

Внесите статические ресурсы и заполните выпадающие списки.

Используя вызов AJAX, я могу ввести статические ресурсы, заполнить раскрывающиеся списки и добавить бизнес-логику.

Мы также загрузим это в нашу папку поддержки.

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

Добавить логику отправки

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

И поддерживая контроль над бизнес-логикой, я также сохраняю записи о записи.

Подведение итогов

Если есть один вывод — если у вас есть статические значения, активы (файлы CSS или javascript), вам действительно следует использовать объем ресурсов поддержки (зная, что многие клиенты все еще размещают свой собственный контент в томе поддержки).

Это будет означать, что:

  • Вы можете разрабатывать независимо от Content Server (учитывая, что вам нужно только обслуживать статический ресурс).
  • Это производительно (без рукопожатия API или накладных расходов)
  • И он будет масштабироваться со многими узлами в вашем кластере Content Server (чтобы вы могли развернуть его на облачном Content Server OT).

Да, избегать WebReports становится все труднее, однако при правильном подходе вы можете избежать некоторых серьезных проблем WebReports и создать более надежные решения.

Подключайтесь к Driver Lane через Twitter и LinkedIn или напрямую на нашем сайте.