Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Expand
titleТестовая среда для работы sso?

Ктест тест https://test.sso.corteos.ru/

продуктив https://prd.sso.corteos.ru/

...

Expand
titleЕсли у клиента уже поддержана sso аутентификация например через Azure AD, то возможно ли будет использовать Azure AD и для входа в Corteos?

да, SAML 2.0. Необходим мод SSO (настройка sso saml) + в настройках темы домена задается спец. ссылка https://yourdomain.ru/mods/sso/AuthNRedirect/?redirectUrl=

на стороне AD в настройках указываются:

Entity ID - ваш домен

Assertion Consumer URL - ссылка на sso

pass id_Group (в claims) - идентификатор группы

...

Expand
titleКоллбек необходимо отправить в систему, которая работает во внутри внутренней сети

Необходимо захостить брокер сообщений(например, rabbitmq), а внутренняя система сможет из него забирать сообщения

Expand
titleПомимо русских ФИО, я должен ещё передать транслитерацию. По какому из стандартов необходимо транислитерировать?

Можно по таким правилам https://transliteration.pro/zagranpasport

Expand
title Можно ли вообще не передавать латинский вариант ФИО? Очень хотелось бы, чтобы это делалось автоматически на вашей стороне.

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

Expand
titleВ запросе есть параметр Gender="true". Почему в параметре пол проставляется флаг true или false? Какая здесь логика?

true = мужской, false = женский

Expand
titleDictionaryName="Табельный номер". Этот параметр всегда константный и всегда принимает значение "Табельный номер"? Или в разных случаях нужен разный набор для блока PersonalCodes? Если да, то просьба расписать эти сценарии

Берутся названия словарей и коды, прикрепляемые к персоне.

Это определяется интеграционной логикой и настройками, которые выполняет агентство

Expand
titleВ этом же тэге есть isPrimaryKey. В каких случаях он должен быть true, а в каких false?

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

Данное значение обязательно должно быть уникальным.

Ключ isPrimaryKey = true позволяет определить, какой код отвечает за идентификатор пользователя. По этому параметру синхронизуются данные из запроса с данными в БД и обновляются значениями, передаваемыми в запросе.

Если такого параметра нет, то мы пробуем искать по документу, а потом по ФИО + ДР. Если никто не нашелся, создаем нового.

Expand
titleEmail в тэге AccountDeatils - это email тревел-менеджера?

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

Expand
title<sso:CountryAlpha2>RU</sso:CountryAlpha2> что за параметр? Он всегда константа?

Это ISO-2 код страны гражданства персоны. Является международным стандартом

Expand
titleОбязательно ли передавать пол?

Да

Expand
titleОбязательно ли передавать INN и KPP?

Нет, если не будет передано, то персона привяжется к первой найденной организации

Expand
titleОбязательно ли передавать дату рождения?

Да

Expand
titleЕсли изменились данные по командировке, например, даты или направление поездки, а также данные пассажира, как обновить командировку в Кортеос?

Необходимо осуществить повторный переход в Кортеос, для обновления данных по командировке передать спецфлаг

Code Block
<CustomOptions>
	<CustomOption>
		<Key>updateMode</Key>
		<Value>update</Value>
	</CustomOption>      
</CustomOptions>
Expand
titleМожно ли без использования sso создание пользователя на лету создавать пользователя по sso создания новой командировки (данные по командируемому сотруднику отправляются и там и там одинаковые)?

Создание пользователя в момент перехода можно только с помощью PersonToCreate в AccountDetails SSO: создание пользователя на лету

Но пользователей можно создавать и через Api: Orchestrated API или простой CRUD , тогда можно не создавать пользователя на лету

Expand
titleМожно ли для начала тестирования создавать командировки без отправки данных по персональным кодам?

Можно, но опишем как работает определение пассажира:

  • система смотрит наличие структурного кода с флагом IsPrimaryKey="true" - если такой есть, то поиск персоны происходит по привязке к этому коду. Подразумевается, что код уникальный, например, табельный номер

  • если кода нет, система смотрит наличие документов в запросе, если есть документы, то берет первый переданный и ищет по нему персону

  • если документов нет, то поиск персоны в системе происходит по переданным ФИО и дате рождения

Expand
titleПравильно понимаю, что для создания командировки мы также не заполняем AccountDetails (указано как опциональные атрибут)

Необходимо заполнять, id_Group, GroupSecurityKey - необходимы для авторизации, корректного поиска\создания персон и командировок. Email - это пользователь инициатор(создатель) командировки