Доброго времени суток. На данный момент я хочу разработать приложение на marketplace, но исходя из документации у меня возникло много вопросов. Ситуация следующая
Если API определнного продукта, который будет возвращать список документов, при необходимости документы можно открыть в iframe отредактировать и так далее, после чего iframe закрываеться, документы храняться на нашем сервере и все манипуляции происходят на нашей стороне.
Идея заключаеться в том что бы сделать custom section (для sales, marketing и так далее) при переходе на которую будет делатся call на наш сервис и получаться список документов, или если человек не авторизирован, он должен пройти процес регистрации/авторизации на нашем ресурсе. после чего человек выбирает документ и смотрит какие действия он может сделать, скажем удалить, изменить, переименовать, загрузить новый.
Итак, следующие вопросы:
1) Для создания приложения достаточно сделать add package набросать туда элементы сделать экспорт и в панели разработчика закрепить архив на созданом приложении?
2) Можно ли кастомизировать отображение, а точнее сам layout что бы при нажатии на секцию было скажем две колонки левая хранит список документов, правая информацию о документе и действия с ним
Как-то так: http://joxi.ru/GrqgDLRFQKQyL2
3) Достаточно ли для таких целей использовать лишь bpmonline studio с js кодом?
4) Если есть необходимость хранить токены закрепленные за юзером, можно ли хранить их на стороне bpmonline, что бы каждый пользователь имел доступ к своему личному аккаунту нашей системы, если да то как.
5) Есть ли какие-то вебинары по разработке приложений для marketplace (знаю что скоро будет проходить, но возможно есть старые какие-то)
6) https://academy.bpmonline.com/documents/technic-sdkmp/7-9/developing-adv... - здесь в примере указан код из hook.io (последний сниппет), но как я понял код дожен быть в bpm studio который показывает как открыть iframe, это ошибка или я чего-то недопонял.
Заранее благодарю за ответ
Очень странный вопрос) В моей голове примерно такая схема:
1) Выбираешь свой префикс, добавляешь свой пакет и в нём ведёшь разработку.
2) Разрабатываешь что угодно, как угодно (главное чтобы работало). Мы в разработке и интерфейсы перепиливали, и виджеты сторонние вставляли и разделы новые добавляли. Все доработки ограничены лишь вашим воображением)
3) Коммитишь всё в маркетплейс. С тобой связывается аналитик террасофта, проверяет устанавливается ли пакет с доработками(+справочники, сист. настройки и т.п.) Вроде бы протом надо ещё презенташку продукта защитить, но тут я не уверен.
Конкретно по вашим пунктам:
1) Да
2) Да
3) Да
4) Можно использовать справочник, добавить туда поле(тип - зашифрованная строка), туда складировать пароль.
5) Не слышал. Да и чисто логически - чем разработка дополнений/расширений отличается от обычных добаботок по тз? Заказчик иногда такое хочет, что влезло бы в 2-3 маркетплейс-расширения :smile:
6) Тут вообще другой код. С документацией какая-то фигня происходит)
Очень странный вопрос) В моей голове примерно такая схема:
1) Выбираешь свой префикс, добавляешь свой пакет и в нём ведёшь разработку.
2) Разрабатываешь что угодно, как угодно (главное чтобы работало). Мы в разработке и интерфейсы перепиливали, и виджеты сторонние вставляли и разделы новые добавляли. Все доработки ограничены лишь вашим воображением)
3) Коммитишь всё в маркетплейс. С тобой связывается аналитик террасофта, проверяет устанавливается ли пакет с доработками(+справочники, сист. настройки и т.п.) Вроде бы протом надо ещё презенташку продукта защитить, но тут я не уверен.
Конкретно по вашим пунктам:
1) Да
2) Да
3) Да
4) Можно использовать справочник, добавить туда поле(тип - зашифрованная строка), туда складировать пароль.
5) Не слышал. Да и чисто логически - чем разработка дополнений/расширений отличается от обычных добаботок по тз? Заказчик иногда такое хочет, что влезло бы в 2-3 маркетплейс-расширения
6) Тут вообще другой код. С документацией какая-то фигня происходит)
Спасибо дружище))) А вот по поводу создание своего префикса, я его создаю в developers page а потом захожу на акк bpmonline там в online studio я делаю сождание пакета скажем qweTestPackage и в него набрасываю элементы? И еще там в доке написано что типа потом надо зайти в Section Wizard и добавить свою секцию, и уже там почему-то префикс стоит Usr и его нельзя сменить http://joxi.ru/Y2L0OXwS9GEvq2, для пакета marketplace оно по другому создаеться?
Доброго времени суток! Прошу объяснить принцип установки пакета из репозитория.
Объясню причину данного обращения, есть около 7 пакетов которые были созданы нами и вот когда мы попытались засетапить их на другую среду (заранее проясню что их версии и сборки абсолютно идентичны), после выполнения необходимых первоначальных действий установки зависимостей пакетов друг от друга, генерации исходного кода компиляции, обновлении структуры базы данных и, наконец, установки данных мы получаем ряд ошибок связанных с отсутствием необходимых колонок, если быть конкретнее то справочных полей.
Когда смотрим в таблицу в БД обнаруживаем, что действительно, данных колонок там просто нету.
Так вот вся суть в чем, каким образом тогда выполняются этапы установки пакета и чем стоит пользоваться при их установке?
Это будет SVN или лучше с помощью workspace console?
Прошу более детально ответить на данный вопрос.
Данная функциональность разрабатывается в рамках проекта РусТехЭксперт.
Попробуйте выполнить установку пакетов по очереди, начав с первого по иерархии.
Установить его из SVN (+ выполнить генерацию исходного кода, компиляцию, обновлении структуры базы данных).
Дело в том, что сюда я и написал, потому что тех поддержка отклонила по SLA.
Хотя никакой новой логики здесь нет. Пытаемся пользоваться базовым функционалом по установке пакетов.
Добрый день. Ситуация следующая:
Есть два замещающих объекта Case. Один находится в пакете для разработке. Второй - в пакете Custom. Возникла необходимость реализовать логику в casePage, затрагивающую поля из Case в пакете Custom. Но дилемма в том, что логика должна быть реализована в пакете для разработки.
Вопрос как перенести объект Case из Custom в пакет для разработки (слить два замещающих объекта), чтобы не затереть существующую логику, уже реализованную в Case пакета разработки?
В данный момент времени, механизм автоматического слияния изменений в объектах из разных пакетов отсутствует. Есть механизм ручного переноса изменений, который мы рекомендуем использовать.
Во-первых, нужно проверить не нарушена ли у Вас иерархия пакетов. Пакет Custom должен быть последним в иерархии всегда. И по-хорошему наследоваться от всех других пакетов в системе и от пакета разработки, но это уже не обязательно.
Перед выполнением указанных действий обязательно выполните бекап БД.
Слияние необходимо выполнить для 2-х типов схем: EntitySchema и ClientUnitSchema
Рассмотрим слияние EntitySchema:
В объекте Case из пакета Custom добавлены кастомные колонки, которые Вы хотите перенести.
Открываем объект Case из пакета разработки на редактирование добавляем колонки, которые сейчас есть в объекте Case пакета Custom с такими же именами и соответствующими типами. Не закрывая дизайнер удаляем объект Case из пакета Custom и сразу сохраняем и публиуем объект Case, в который Вы переносили изменения.
Рассмотрим слияние ClientUnitSchema:
Сливать ClientUnitSchema намного сложнее, так как необходимо анализировать обе схемы и сливать их значение в одно. Для примера выполним сливание схемы ContactPageV2 из пакета Custom в схему ContactPageV2 из пакета разработки.
1.Открываем обе схемы в дизайнерах. Если посмотреть на содержимое схем, то можно заметить, что некоторые свойства объекта содержат значение (в данном случае diff). Пример на скриншоте "image2".
2. Дальше необходимо анализировать содержимое каждого элемента в diff-е.
3. Ищем совпадающие элементы по полям «opperation» и «name»
4.Анализируем значение полей свойства «values»:
- Если в новой версии такого поля нет, то добавляем
- Если в новой версии такое поле есть, то подменяем его значение
5. Если в схеме, в которую переносим данные, нет элементов с соответствующими полями «opperation» и «name», то переносим элемент целиком. Пример на скриншоте image3
6. Выполняем п.п. 3-5 для всех элементов объекта, который возвращает функция.
7. После переноса/слияния всех данных, схему из пакета Custom можно удалить.
Михаил, здравствуйте!
Спасибо за ответ!
Как раз таки слияние ClientUnitSchema не взывает затруднения.
А вот к EntitySchema есть вопросы. Не затрётся ли содержимое переносимых полей при реализации описанной схемы?
Добрый день, Игорь!
Описанный ранее метод слияния EntitySchema вполне рабочий и несколько раз сам его применял.
Если все делать согласно инструкции, то проблем быть не должно. Единственный совет, откройте данные объекты (который будете удалять и который будете изменять) в разных браузерах, так будет надежнее. Если у Вас есть предостережения, Вы можете протестировать на тестовой сборке.
Добрый день. Переношу пакет с доработками 7.4 на 7.5 средствами SVN и MD файлами.
В процессе переноса выявлена, что для замещающих клиентских модулей ActPageV2,
CorrespondencePageV2 отсутствует родитель.
Как быть в этой ситуации? Как переносить доработки с версии на версию, если от версии к версии изменяются схемы ядра?
Спасибо за Ваш вопрос.
Действительно, ранее в системе были отдельные страницы для различных типов документов. В версии 7.5 данных схем не должно быть, вместо них реализована страница DocumentPageV2.
В утилите и пакетах обновления на версию 7.5 предусмотрен учет данного изменения.
Прошу детализировать проблему и описать шаги, которые выполнялись Вами в письме на адрес support@tscrm.com.
Я переносил указанные доработки md-файлами на другую базу, т.к. обновление не предполагалось.
Предоставьте, пожалуйста, инструкцию по использованию утилиты для корректного переноса доработок.
Вариантом решения Вашего вопроса будет выгрузить пакеты с доработками через WorkspaceConsole и накатить их на другую базу. Для этого:
1) Сначала важно указать параметры подключения к БД, которые будет использовать WsC. WsC использует строку подключения из конфигурационного файла Terrasoft.Tools.WorkspaceConsole.exe.config (должен находиться в каталоге с WsC).
В секции указывается используемая строка подключения
В секции указываются значения строк подключения к БД.
...............................................................
2) Выполнить 1, 3 и 4 пункты из прикреплённой инструкции.
3) Сделать выгрузку пакетов из первой базы с помощью WorkspaceConsole, запустив файл update.bat со следующими параметрами:
Terrasoft.Tools.WorkspaceConsole.exe -operation=SaveDBContent -workspaceName=Default -destinationPath=D:\Temp\Repository\ -contentTypes=Repository
4) Выполняем первый пункт, указав теперь путь к базе, на которую накатываются пакеты.
5) Выполняем полностью прикрепленную инструкцию. Накатятся пакеты с доработками на другую базу.
Не будет ли конфликта при обновлении, т.к. необходимый пакет будет выгружен со всеми наследуемыми им пакетами, а эти пакеты в целевой BPM 7.5 уже есть?
Перед выполнением инструкции обязательно сделайте бэкап базы данных.
Конфликтов возникнуть недолжно, так как устанавливатся только пакеты новее уже установленных.
В SDK bpm'online добавлена серия статей, посвященных вопросам работы с системой контроля версий и пакетами в версии 7.6. Заходите на сайт Terrasoft Academy в раздел "Документация SDK" и узнайте как
Данная ошибка также происходит и при копировании конфигурации в списке конфигураций.
По данным ошибкам зарегистрирован инцидент и направлен в департамент разработки.
Выпущен урок для разработчиков в интерактивном формате.
В ходе урока вы получите теоретические знания о механизме добавления SQL-сценариев в пакет, познакомитесь с демонстрацией добавления представления базы данных. Кроме того, в ходе практического упражнения, вы научитесь добавлять представление в базу данных.
При поставке пакета клиенту, может возникнуть ситуация, что для корректной работы функционала пакета, необходимо, что бы с пакетом поставлялись клиенту еще какие то данные.
Например, для корректной работы пакета 1С необходимы дополнительные типы и состояние документов, какие в стандартной поставке (напр. CRM) отсутствуют. В таком случае нам необходимо создать привязку данных к пакету с типом «Первичная установка» или «Установка».
Также может возникнуть ситуация, например: мы обновляем клиенту пакет, и для корректной работы обновленного пакета, изменились какие то данные, которые необходимо изменить на базе клиента. В данном случае нам опять приходит на помощь привязка данных к пакету. При обновлении пакета на базе клиента, таким образом, будут обновлены все данные, которые поставляются с пакетом с типом «Установка» и «Обновление существующих».
Существует три типа привязки данных пакету:
«Первичная установка» - при первой установке пакета, данные, которые привязаны к пакету, будут добавлены в соответствующие таблицы
«Установка» - при установке уже существующего пакета, записи, которые уже существуют, будут обновлены данными, которые поставляются с пакетом, если записей нет, то они буду добавлены в соответствующие таблицы из данных, привязанных к пакету
«Обновление существующих» - при установке уже существующего пакета, записи, которые, уже есть в таблице, будут обновлены данными из пакета
Рассмотрим пример привязки данных к пакету на примере привязки к "Пользовательское действие процесса" (SysProcessUserTask):
Что бы привязать данные к пакету нужно выполнить следующие действия:
Выбираем пакет, к которому будем создавать привязку данных (рис.1)
В разделе «Конфигурация» заходим на вкладку «Данные пакета» (рис.1)
Добавляем новую привязку (рис.1)
Заполняем поле «Название» (рис.2 пункт 1)
Выбираем объект, к которому будем делать привязку (рис.2 пункт 2)
Выбираем «Тип установки» (рис.2 пункт 3)
При необходимости можем отредактировать колонки объекта, по которых хотим сделать привязку (рис.2 пункт 4)
Нажимаем кнопку «Загрузить данные» что бы загрузились и привязались данные (рис.2 пункт 5), в гриде(рис.2 пункт 6) видим данные которые привязались к пакету, на карточке есть возможность настраивать фильтрацию
Закрываем карточку (рис.2 пункт 7)
Делаем Commit в SVN
Рис. 1
Рис. 2
При Update из SVN у пользователей будут добавлены/обновлены (в зависимости от выбранного типа установки) данные.
