Как адаптировать код для веб-клиента Directum RX

Предисловие

Десктоп-клиент всё ещё популярен у пользователей Directum RX. Один из аргументов в его пользу - это неработающая заказная разработка.

Но подождите, ведь заказную разработку мы делаем сами, почему она не работает в вебе? Примерно об этом мы сейчас и поговорим.

В общих чертах

Прежде всего имеет смысл оговорить, что всё нижесказанное действительно в первую очередь для клиентского кода, поскольку именно его выполнение отличается в вебе и десктопе. Отличие в том, что в вебе весь клиентский код выполняется на веб-сервере, а в декстопе – тут же на клиенте.
Все прикладные функции стандартного базового решения Directum RX написаны с учётом этого факта, и все платформенные методы тоже работают с его учётом. Однако сторонние библиотеки, подключаемые в Directum RX Development Studio (далее DDS), чаще всего об этой разнице не знают, поскольку она им не нужна. Поэтому к выбору сторонних библиотек также следует подходить с оглядкой.
И немного о работе с запрещёнными классами .NET. Запрещено всё, что не разрешено, а список разрешённых классов можно найти в справке. Игнорирование этих запретов всегда на совести разработчика, но если вдруг вам потребовалось использовать что-то из запрещённых классов, то и здесь лучше заранее подумать, как это будет работать в вебе.
Теперь, когда у нас есть некоторые вводные, перейдём к разбору конкретных случаев.

Выгрузка документов

В нашей практике эта функциональность в подавляющем большинстве случаев работала только в десктоп-клиенте. Например, у одного заказчика вплоть до версии 3.4 для выгрузки документов использовался алгоритм следующего вида:

1. Запросить у пользователя на клиенте список документов или параметры для поиска.
2. Запросить у пользователя на клиенте адрес папки для выгрузки.
3. Где-то на сервере осуществить поиск документов по переданным параметрам и/или их обработку, например, преобразование в PDF, а результат передать на клиент.
4. На клиенте сохранить обработанные документы в указанную папку.

Запрещённые конструкции использовались на шаге 4, в частности, классы из пространства имён System.IO. На шаге 2 подключалась внешняя библиотека, которая внутри также использовала запрещённые конструкции. Использовать такие обёртки разрешено, но как уже упоминалось выше, делать это нужно с умом. На версии 3.4 заказчик захотел перевести всех своих пользователей с десктоп-клиента на веб, но столкнулся с проблемой – выгрузка документов в вебе, что называется, не завелась. Код падал с ошибкой, и вот почему:

1. Веб-сервер не может обработать вызов диалоговых окон из System.IO и передать их в веб-клиент для отображения пользователю.
2. Веб-сервер просто не имеет доступа к клиентскому компьютеру. Даже если запросить у пользователя путь к папке для выгрузки в виде строки, файлы в лучшем случае сохранятся там же на веб-сервере, а в худшем код снова упадёт с ошибкой.

Исправить ситуацию решили заменой алгоритма выгрузки на такой:

1. У пользователя на клиенте так же, как раньше, запрашивается список документов или параметры для поиска.
2. На сервере выполняется поиск и обработка документов, после чего результаты упаковываются в ZIP-архив, который передаётся на клиент. 
3. На клиенте выполняется экспорт ZIP-архива. Загрузка и сохранение файла будут произведены средствами используемого браузера.

У этой реализации есть один нюанс: способ с экспортом ZIP-архива работает только в веб-клиенте. Старую схему с использованием System.IO можно оставить для совместимости (например, сделать в коде ветвление в зависимости от типа клиента), а можно убрать, в зависимости от того, требуется ли форсировать переход пользователей из десктоп-клиента в веб. 
Также есть альтернативный вариант выгрузки документа не в локальную папку на компьютере пользователя, а в общую папку на сервере. Такую выгрузку можно реализовать в асинхронном обработчике, который по завершении своей работы пришлёт пользователю уведомление об успешной выгрузке со ссылкой на выгруженный файл.

Отправка документов по электронной почте

Эта функциональность, напротив, была самой экзотической для адаптации, но в то же время самой простой. Возможность вложить в письмо приложения к документу появилась в Directum RX сравнительно недавно, в версии 3.3. До этого разработчики выкручивались примерно так:

      var docs = new List<Sungero.Content.IElectronicDocument>();
      foreach (var doc in documents)
      {
        docs.Add(doc);
        if (doc.HasRelations)
          docs.AddRange(doc.Relations.GetRelated(AppModule.Constants.Module.AddendumRelationName));
      }
      
      var versions = docs.Where(d => d.HasVersions).Distinct().Select(d => d.LastVersion);
      
      var content = AppDomain.CurrentDomain.GetAssemblies().Where(a => a.FullName.Contains("Sungero.Content.Client,")).SingleOrDefault();
      var helper = content.GetTypes().Single(t => t.Name == "ElectronicDocumentHelper");
      var method = helper.GetMethod("SendByMail");
      if (method != null)
        method.Invoke(null, new object[] {versions});

И это прекрасно работало, если не учитывать, что:

1. Использование рефлексии тоже запрещено.
2. Имена классов/типов и т.д. могут изменяться от версии к версии (отчасти именно из-за этого существует п.1).
3. Приведённый кусок кода сработает только в десктоп-клиенте.

После обновления на версию 3.3 заказчик решил использовать веб-клиент вместо десктопа, где и выяснилось, что приведённый кусок кода превратился в тыкву. Хорошая новость была в том, что теперь его можно было с чистой совестью удалить, потому что аналогичная функциональность появилась в стандартной разработке Directum RX.

Здесь могла быть ваша реклама история

За всё время, что существует веб-клиент Directum RX, у нас было достаточно случаев, когда пользователи не могли работать в веб-клиенте, чтобы увидеть в этом некую тенденцию. Тем удивительнее для нас оказался результат - все эти случаи удалось описать всего в двух историях выше. Мы уверены, что у вас тоже найдётся похожий кейс, а может быть, и не один. Делитесь ими в комментариях - возможно, именно ваше решение окажется полезным другим пользователям сообщества :)