Здравствуйте.
Хотим настроить регулярный запуск интеграции по расписанию в конце рабочего дня.
Дано:
Terrasoft XRM 3.3.2.43, в которой настроена интеграция с 1С7.7.

Как удобнее всего настроить регулярный запуск этой интеграции по расписанию?
Если я и могу запустить с помощью sheduler'а террасофт, то как стартовать саму интеграцию?
Спасибо.

Нравится

3 комментария

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

Прежде всего, не совсем понятно, что Вы имеете ввиду под sheduler Terrasoft, если имеются ввиду Задачи, то там возможности такой нет.
Начиная с версии 3.4 для таких целей можно будет использовать утилиту TSJobManagerService.

На данный момент можем предложить Вам следующие варианты:

1. Реализовать выполнение синхронизации из окна Terrasoft:
- в качестве утилиты для запуска используем некий scheduler ОС, который способен выполнить командную строку;
- в Terrasoft нужно будет реализовать окно(назовем его wnd_1CAutoSynchro), которое на подготовке будет запускать нужную интеграцию. Скрипт самого запуска будет примерно такой:
var Attributes = GetNewDictionary();
Attributes('IsMain') = true;
Attributes('IsShowError') = true;
ImportAllObject(DataflowID, Attributes); // в скрипте scr_Dataflow1CUtils
- командная строка будет выглядеть примерно так:
“[путь к terrasoft]\bin\tsclient” /wnd=wnd_1CAutoSynchro /usr=??? /pwd=??? /cfg=???
или для windows авторизации
“[путь к terrasoft]\bin\tsclient” /wnd=wnd_1CAutoSynchro /wauth=true /cfg=???
- в любом случае здесь возникает вопрос, так как в командной строке нужно будет хранить пароль, это плохо. В случае же windows-авторизации - такая проблема отпадает.

2. Реализовать вызов синхронизации из обычного js-скрипта
- из js-скрипта (обычный текстовый файл, обычно с расширением js) можно создать COM-объект подключения к Terrasoft (назовем файл Auto1CSynchro.js);
- в этом скрипте будет выполняться подключение, получение скрипта scr_Dataflow1CUtils и вызов его функции ImportAllObject с передачей нужных параметров.
- как и в первом варианте в scheduler-е операционной системы выполнять командную строку вида:
cscript “[путь к js файлу]\Auto1CSynchro.js”
cscript – стандартная команда Windows,
- вопрос с хранением пароля остается, но теперь его можно будет куда-то спрятать\зашифровать и в js-файле считывать.

Инна Безверхняя,
II линия службы поддержки Terrasoft.

Третий вариант, не дотягивает до первых двух, но может быть проще в реализации для новичков и проблемы с паролем отпадают. Для этого нужно добавить Timer и на его событие OnTimer отрабатывать необходимую синхронизацию из самого СРМ.

Если проблема с паролем критична, то можно создать маленькое приложение, на каком-нибудь C# и из него так же как и во 2ом варианте Инны использовать СОМы террасофта, ну а пароль захаркодить. Ну и запускать его все тем же ОСевым sheduler, хотя возможно лучше сделать его на автозагрузке и уже внутри по таймеру запускать синхранизацию, но думаю это не принципиально ...

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

Добрый день помогите пожалуйста, возникла проблемка при удалении контрагента. Все существующие связи контрагента были удалены. При удалении самого контрагента возникает такая вот ошибка: "Ошибка удаления записи. Недопустимое имя объекта "dbo.Name". Я так подозреваю, что это ошибка в тригере, вот только не могу найти где это.

Нравится

4 комментария

Проверьте текст триггера [dbo].[tr_tbl_Account_ID]. Скорее всего, в нём.

Да именно там мы искали. Вроде как нашли текст ошибки, а вот что вместо неё должно быть не можем понять. Текст тригера прикреплён с подчеркнутыми предполагаемыми проблемными местами. Помогите разобраться!

Попробуйте заменить текст

,(select [Name].[tbl_Country]
from [dbo].[Name] as [Name]
where [Name].[ID] = [D].[CountryID])
as [CountryName]

на такой:

,(select [tbl_Country].[Name]
from [dbo].[tbl_Country] as [tbl_Country]
where [tbl_Country].[ID] = [D].[CountryID])
as [CountryName]

Большое спасибо Олег, всё получилось.

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

Добрый день всем!
Недавно обнаружена необычная особенность в ограничении доступа по полям.
Поскольку в руководстве администратора об этом не сказано, думаю, об этом будет полезно узнать всем, кто собирается ограничить доступ по полям для пользователей системы.
Итак, постановка задачи.
Есть некоторая группа пользователей, для которой необходимо запретить просмотр и редактирование некоторого поля (например, Зарплата) в разделе, например, Контакты.

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

Пример:

Есть группа Все пользователи, группа Операторы, группа Начальство. Требуется для обычных пользователей скрыть доступ на поле Зарплата карточки Контакта, причем сделать это на уровне прав доступа на поле.

Решение, которое подходит для MSSQL: для группы Все пользователи доступ по полям не ограничивать (по умолчанию полный доступ), всех обычных пользователей поместить в группу Операторы, и группе Операторы запретить чтение поля Зарплата в таблице Контакт. Группе пользователей Начальство не изменять прав доступа по полям (по умолчанию полный доступ).
Недостаток - все обычные пользователи должны быть помещены в группу Операторы.
Преимущество - высокая скорость работы, т.к. используются "родные" механизмы СУБД MSSQL.

Решение, которое подойдет для Oracle и Firebird: для группы Все пользователи запретить доступ на поле Зарплата сущности Контакт, для группы Начальство не ограничивать доступ по полям.
Достоинство - простота настройки.
Недостаток - искусственная реализация на уровне запросов и ядра, более низкая скорость.
Кстати, этот материал актуален для 3.3.0, 3.3.1. Для других версий не проверял, очень вероятно, что это справедливо для всех версий начиная с 3.1.1.

 

Нравится

Поделиться

4 комментария

О, наконец-то появилось аргументирование объяснение этому "спецэффекту" с правами доступа на поля.

Точно, Большое спасибо,
а то вроде права раздал правильно, а в результате - "зарплату" никто не видит ;)

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

Дмитрий, спасибо за разъяснения.

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

Добрый вечер, путник зашедший на мой блог.
Если ты еще не спишь (а завтра рано вставать) вот тебе мой совет по исправлению Delete Query на администрируемую по записям таблицу, который использует Exist фильтры со ссылками на основную таблицу Delete Query.
Если ты, дорогой путник, не заснул после предыдущей фразы, вот тебе функция, которая исправляет данную проблему:

function ReplaceDQTablesAliasesByViewsInExistFilters(DeleteQuery, TableName, ViewName) {
        var IsAdmin = Connector.CurrentUser.IsAdmin;
        if (IsAdmin) {
                return;
        };             
        var Filters, ExistFilter, Filter, LeftTableAlias, RightTableAlias;
        for (var i = 0; i DeleteQuery.Filters.Count; i++) {
                ExistFilter =
                        DeleteQuery.Filters.Items(i);
                if (ExistFilter.FilterType != ftExists) {
                        continue;
                };
                for (var j = 0; j ExistFilter.TestExpression.ExpressionSelectQuery.Count; j++) {
                        Filters = ExistFilter.TestExpression.ExpressionSelectQuery.Items(j).Filters;
                        for (var k = 0; k Filters.Count; k++) {
                                Filter = Filters.Items(k);
                                if (!IsStringInArray(Filter.FilterType, [ftIsNull, ftCompare, ftLike, ftBetween, ftInclude])) {
                                        continue;
                                };
                                LeftTableAlias = Filter.TestExpression.TableAlias;
                                if (!IsEmptyValue(LeftTableAlias)) {
                                        Filter.TestExpression.TableAlias =
                                                LeftTableAlias.replace(TableName, ViewName);
                                };
                                if (Filter.FilterType == ftCompare) {
                                        RightTableAlias = Filter.ValueExpression.TableAlias;
                                        if (!IsEmptyValue(RightTableAlias)) {
                                                Filter.ValueExpression.TableAlias =
                                                        RightTableAlias.replace(TableName, ViewName);
                                        };                                     
                                };                             
                        }
                }
        }
}

Данная проблема может возникнуть где-угодно в версиях вплоть до 3.2.1.17 (а может и выше), но в базовой версии на написание сего меня подвергла операция "Раздать права доступа как у родительского элемента" детали Файлы. Под пользователем данная операция просто валится, т.к. для выполнения использует dq_GiveRightsByParentItem, которая не лишена проблемы описанной выше. Для исправления можно в scr_FilesDetailGridArea подправить ф-ию DeleteExistingFileAccessRecordsByParentItem: перед "DeleteQuery.Execute()" вызвать ф-ию описанную выше как-то так:

ReplaceDQTablesAliasesByViewsInExistFilters(DeleteQuery, 'tbl_FilesRight', 'vw_FilesRight');

Я не сомневаюсь, дорогой путник, что ты давно спишь. Счастливых тебе снов.

Нравится

Поделиться

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

версия terrasoft crm x25 3.2.0.33 для Oracle
Создал раздел согласно документации с курсов.
Что необходимо сделать для обеспечения возможности администрирования прав доступа для данного раздела?

Нравится

1 комментарий

Добрый день, Александр.

Права доступа бывают нескольких типов.

1. Администрирование по правам по группам таблиц. Для настройки такой возможности в Вашем разделе необходимо:
а) в разделе Администрирование - права по группам таблиц добавить новую запись, назвать по имени Вашего разделав таблице раздела, в поле Имя объекта SQL указать некоторое латинское обозначение (см. существующие примеры).
б) в Администраторе в таблице Вашего раздела указать созданное значение в поле Группа таблиц и сохранить таблицу.

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

2. Администрирование по правам на записи. В случае, если создавали раздел с деталью Доступ, то, скорее всего, администрирование данного типа уже включено. В любом случае, проверка прав по записям включается, если в таблице раздела установить признак "Администрируется по записям" и сохранить таблицу. Будет создана новая таблица с правами на записи. Для управления доступом такого типа в разделе необходимо реализовать деталь "Доступ". Реализация ее достаточно типовая, можно "подсмотреть" ее реализацию в существующих разделах и создать по аналогии.

3. Также стоит обратить внимание на раздел Администрирование - Права доступа по умолчанию.

Подробно о всех видах прав можно прочитать в Руководстве Администратора, прилагаемом к продукту.

P.S. В версиях 3.2.0.x и выше есть возможность создавать разделы автоматически (в том числе создание детали Доступ).
Данная возможность запускается так:

tscrm.exe /wnd=wnd_CreateNewWorkspace

Желаю успехов!

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