Определение отправителя и получателя любой сущности (Entity)

[SLenik]

Приветствую уважаемых разработчиков!

Пусть имеется MessageId + EntityId некоторой сущности.
Вопрос: как правильно определить направление (входящая она или исходящая) и кто контрагент (другая сторона документооборота)?

Сейчас я делаю запрос GetMessage по MessageId, далее смотрю на EntityType + AttachmentType сущности и действую в соответствии с ними.
Для краткости IsOurBox(boxId) - true если мы отправитель (boxId совпадает с нашим)

EntityType	AttachmentType	Как определить контрагента и направление
Signature	любой	entity.SignerBoxId != "00000000000000000000000000000000@diadoc.ru" => direction = IsOurBox(entity.SignerBoxId) ? Outgoing : Incoming
Attachment	XmlTorg12 or Torg12 or Invoice or InvoiceRevision or InvoiceCorrection or Nonformalized	direction = IsOurBox(GetDocument(..., MessageId, EntityId).CounteragentBoxId) ? Outgoing : Incoming

Вопросы:

1. Как получить данные контрагента для исходящих сущностей типа Attachment (CounteragentBoxId в этом случае содержит адрес ящика отправителя - то есть наш)?
2. Как определить направление и контрагента для сущностей типа Attachment, которые не умеет обрабатывать GetDocument, в первую очередь для XmlTorg12BuyerTitle, RevocationOffer и XmlSignatureRejection?

[asvyazin]

1. Контрагент - это всегда ящик, отличный от моего, правильно? Можно просто из Message взять FromBoxId и ToBoxId, и выбрать из них тот, который не равен моему BoxId.
2. Это гораздо сложнее. Способ определения отправителя произвольной Entity зависит от ситуации, обычно надо сначала представить себе схему соответствующего документооборота.
   Если Entity - документ, то его отправитель - всегда FromBoxId (из Message). Лайфхак: Entity - документ, если у него пустое поле ParentEntityId, все остальные сущности являются потомками какого-либо документа.
   Если Entity - не документ, то придется анализировать его тип. Для всех подписей отправитель - SignerBoxId. Для сущностей, замещающих ответную подпись (все SignatureRejection-ы, BuyerTitle-ы) отправитель - всегда ToBoxId. Сущности, связанные с согласованием (Resolution, ResolutionRequest, ResolutionRequestDenial), никогда не попадают в ящик контрагента, поэтому их "отправитель" - всегда текущий ("мой") ящик. Для сущности InvoiceReceipt (и Receipt) проще всего определить отправителя, найдя единственную подпись под ней (для этого надо найти подпись с ParentEntityId равным EntityId нашей сущности), отправитель самой сущности и ее подписи - совпадают.
   Самый сложный случай - RevocationRequest, потому что он может быть отправлен как из FromBoxId так и из ToBoxId, и в худшем случае (если документ уже окончательно аннулирован) под запросом на аннулирование будут уже две подписи - по одной из каждого ящика, то есть лайфхак с отправителем подписи не поможет. Внутри системы у RevocationRequest есть специальное поле - InitiatorBoxId, по которому можно понять, кто изначальный отправитель запроса на аннулирование, но похоже в GetMessage это поле не выставлено (это наша недоработка). Наверное пока единственный способ (весьма окольный) - это сначала добраться до соответствующего документа (через ParentEntityId), узнать его идентификатор, затем при помощи метода GetDocflows добыть структуру DoсumentWithDocflow, и в ней глубоко, как смерть Кащея, будет зарыто значение InitiatorBoxId (конкретно по пути .Docflow.RevocationDocflow.InitiatorBoxId).

[SLenik]

Лайфхак: Entity - документ, если у него пустое поле ParentEntityId

Внесите это куда-нибудь в api-docs (хотя бы в описание того же GetDocument'а) - крайне полезная штука.
ЗЫ. Писал пару месяцев назад в техподдержку с вопросом как узнать для каких из Entity типа Attachment вызов GetDocument отработает корректно - тогда столь внятного ответа не было, пришлось перебирать типы.

InitiatorBoxId, по которому можно понять, кто изначальный отправитель запроса на аннулирование, но похоже в GetMessage это поле не выставлено (это наша недоработка)

А сколько времени потребуется для добавления этого поля в Entity, получаемые из GetMessage?
ЗЫ. Вообще мне кажется, что структура Entity как-то больно перегружена. Было бы здорово оставить в Entity только базовые поля + добавить 3 поля:

• Signature - объект, с данными подписи (если EntityType = Signature), в противном случае null.
• Document - (документ первичный типа ТОРГ-12, СФ или неформализованный) с добавлением полей специфичных именно для первичного документа.
• Service - (документ служебный типа Уведомления о получении, предложения об аннулировании и т.п.) с добавлением полей типа InitiatorBoxId и остальных полезных в этом случае полей.

[asvyazin]

Поле InitiatorBoxId думаю надо добавить для полноты, да, тем более на это нужно совсем немного времени. Про документацию тоже согласен.

Насчет изменения формата Entity - не думаю, что это произойдет в обозримом будущем, хотя идея интересная.

[protwill]

Лайфхак: Entity - документ, если у него пустое поле ParentEntityId, все остальные сущности являются потомками какого-либо документа.

Это правило точно справедливо для всех сущностей? Работая с событиям столкнулся с Entity имеющими EntityType == Attachment, пустой ParentEntityId и AttachmentType == DeliveryFailureNotification, документами такие сущности не являются.

[asvyazin]

Действительно, DeliveryFailureNotification - это единственное исключение :)