И снова здравствуйте.

Уже пару дней сражаюсь с проблемой импорта услуг (они же - номенклатуры в 1С) между базами. Совершенно тривиальная синхронизация - Я переношу услуги по их названию, и в интеграции указано тупо:

1С - НаименованиеПолное из справочника Номенклатуры
Террасофт - Услуга (OfferingName) из набора данных Услуги

Спотыкается при попытке отфильтровать (то есть, использовать ApplyDatasetFilter) на поле OfferingNameS1CF (S1CF он добавляет в процессе). Я так понимаю, это баг Террасофта? Есть ли лечение?

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

Нравится

5 комментариев

Максим, у Вас что поле OfferingName ключевое? Это "плохая" практика :) Проще всего избавиться от этого поля как ключевого - есть ведь UID1C и Object1C.
А вообще сталкивался с таким 2 раза: первый раз помогло следующее:
открыть маппинг этого поля и нажать "ОК", затем открыть настройку самой сущности и также нажать "ОК".
Второй раз это не помогло - создал фильтр вручную в sq (благо он всегда и точно всегда создается с таким именем).

> Максим, у Вас что поле OfferingName ключевое?

Да, поле ключевое.

> Это "плохая" практика :) Проще всего избавиться от этого поля как ключевого - есть ведь UID1C и Object1C.

Интересно. То есть, лучше добавить несколько десятков дубликатов, но с "правильными" UID1C и Object1C, чем привязаться к названию услуги? Я не понимаю, в чём минус такой практики, тут хотелось бы поподробнее.

Насчёт sq фильтра, я видимо не в курсе, как работает фильтр, можно чуть подробнее?

Максим, UID1C - это глобальный идентификатор записи в 1с. Т.е. названия могут и совпадать, а вот UID1C всегда будет разным. Так что во всех сущностях, где есть UID1C (справочник и документы) нет смысла использовать другие ключевые поля кроме UID1C и Object1C.

Жаль, что вопросы про фильтр и плохую практику остались без ответа.

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

Тогда создайте фильтр в ручную: для этого в Террасофт администраторе в SelectQuery продуктов (sq_Offering) добавьте строковый параметр с именем OfferingNameS1CF, и фильтр сравнения OfferingNameS1CF как tbl_Offering.Name = Parameter:OfferingNameS1CF
Перезайдите в Террасофт и проверьте работу.

Показать все комментарии

Добрый день, Коллеги

На днях возник небольшой вопрос, решить который все никак не представляется возможным.
У нас есть ряд workflow-процессов у которых в свою очередь есть большое кол-во свойств (параметров со значениями) процесса.
К сожалению, в связи с одной пунктуационной ошибки ранее, у некоторых процессов поле Parameters в таблице Workflow стало NULL.

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

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

Спасибо за потраченное на прочтение время

Используется Terrasoft XRM 3.3.2.244 и MS SQL

Нравится

6 комментариев

Здравствуйте.

Т.е. у Вас есть незавершенные процессы, параметры которых были удалены, и Вам необходимо восстановить для дальнейшей корректной работы сами параметры и их значения?
Если да, то, к сожалению, это не возможно.
Даже если Вы запустите дубль процесса, дойдете до шага, на котором произошел сбой, и скопируете поле Parameters с одного процесса в другой, то все-ровно значения параметров будут не те, которые Вам необходимы в "некорректном" процессе. Названия же параметров, вы в принципе можете просмотреть в Террасофт Администраторе в свойствах диаграммы процесса.

Посмотреть я их, безусловно, могу
И даже могу поднять бэкап БД за период, когда еще были эти параметры у интересного мне процесса
Но хотелось бы попробовать найти чуть более изящное решение
Если оно есть, конечно же

Вопрос скорее в другом
Можно ли как-то получить их скриптом? Например распарсить в tbl_Service поле XMLData у процесса?!
Или, скажем, через функции террасофта можно получить список параметров у определенного шага\процесса?

Иван, посмотреть параметры конкретного дейтсвия можно в ТС Администраторе по правому клику:

а распарсить BLOB в XML можно следующим способом:

CREATE TABLE	#Sample
		(
			BLOB VARBINARY(MAX) NOT NULL
		)
 
INSERT	#Sample
SELECT	0x3C526F772049443D2231223E5065736F2C204D56503C2F526F773E
 
SELECT	*
FROM	#Sample
 
 
ALTER TABLE	#Sample
ADD		MyXML AS CAST(CAST(BLOB AS VARCHAR(MAX)) AS XML)
 
-- Display the result
SELECT	*
FROM	#Sample

Спасибо за крайне развернутый ответ

Но, к сожалению, он не отвечает на вопрос
Можно ли как-то получить список параметров элемента бизнес процесса скриптом?
Например, кнопку сделать в гриде процессов для получения отсутствующих параметров

И распарсить XML представленный как Varbinary или Image тоже не проблема. Вот только Image у элемента Workflow Diagram в tbl_Service не парсится как XML

Иван, здравствуйте.

У каждого элемента в процессе есть свой набор параметров + у самого процесса могут быть пользовательские параметры.

В скрипте процесса можно получить список параметров:

var a = DiagramItem.Parameters;
var b = Diagram.Parameters;

установить либо получить значения:

WFGetParamValueDirect(DiagramItem.Parameters, ParamName, 
		DefaultValue);
WFSetParamValueDirect(Params, ParamName, ParamValue, ParamType);

Параметры, которые "вшиты" в действия - даже после их удаления при выполнении действия - будут созданы.
Параметры диаграммы, которые пользовательские, восстановить не получится. Но посмотреть их список можно прямо в ТС Администраторе в свойствах диаграммы, если конечно они и там не были удалены.

Спасибо

Показать все комментарии