yabs,

1. IIS по умолчанию не предназначен для запуска фоновых процессов, он вырубает приложение через 20 минут бездействия, поэтому нужен внешний процесс
2. очередь можно построить либо на реляционной базе данных, либо с использованием MSMQ и аналогов
3. запуск обработки может быть либо по таймеру, либо когда появляются данные

решения:
1.
1.1. загуглите hangfire и аналоги, эта штука будет вызывать фоновые процессы на вашем IIS сервере, что-то вроде планировщика как услуга
1.2. если по каким-то причинам не хочется использовать внешний сервис - обернуть свой планировщик в виндовый сервис, загуглить Quartz.NET или аналоги и использовать в качестве основы
2. я не вижу особой сложности приложения, запредельной производительности, поэтому для простоты необходимо использовать реляционную базу данных как очередь. MSMQ надо изучать, разворачивать, настраивать, использовать провайдеры/библиотеки для доступа к функциям. лишнее звено, тем более, если надо будет синхронизировать данные в БД и в очереди с учетом транзакции - это потенциальная точка риска, а однозначных плюсов я не вижу. делаете таблицу в БД, туда сливаете свои документы, добавите статус (новый, в обработке, обработано), потом запускаете фоновый поток, который будет брать очередные 10-100 записей и обрабатывать их. если понадобится увеличить производительность - запускаете второй поток и синхронизируете доступ к таблице через сериалайзед транзакцию и изменение статуса новый -> в обработке -> обработано
3. по умолчанию планировщик запускает фоновый процесс по расписанию (каждую минуту например), так же желательно предусмотреть, чтобы следующий цикл не запускался, пока не завершится предыдущий. можно предусмотреть внеочередной запуск обработки. этот метод можно будет вызывать из UI, когда например пользователь нажмет кнопку "сохранить"

отдельно про UI - в системах на массовый ввод документов необходимо очень хорошо подумать - подойдет ли веб интерфейс для быстрого ввода документов. декстопное приложение будет более отзывчивое и надежное с точки зрения пользователя

вопросы?

yabsнагрузка, думаю, смешная будет
в день поступает приблизительно 200-300 счетов
около 20 пользователей
hangfire или аналог и запускать фоновую задачу после каждого "сохранить", можно передавать ид документа по одному или пачкой

yabs, skyANA
еще бы знать время обработки одного документа
* если будет минута и выше, пользователям будет казатся что сайт/приложение зависло, поэтому было бы хорошо сделать фоновую обработку
* если обработка занимает несколько секунд - то да, делать ее сразу же, и никаких фоновых задач

да кто знает что там, может опрос десятка внешних систем по 30 секунда каждая

про веб воркер не знал, не пользовался, не могу ничего сказать, а если случайно браузер закроют - что будет?

skyANAЧто-то на схеме нет внешних систем :)
ну вон же EDI, там либо документы хранятся (они оттуда поступают, либо их надо скачать), либо данные для сверки, и как вариант там может и не быть веб-клиента - тогда по идее некуда будет пихнуть web worker

yabsшеф кстати вообще настаивает на вот таком варианте
по идее она самое православное, только мне не хочется делать Мэппинг из Persistence объектов в Business сначала в Backend'е
и потом еще раз в ASP.NET
не будет такого двойного маппинга, бэк-енд отдает всем потребителям (и принимает от них) модели, которые внутри него мапятся один раз (но в обе стороны) на сущности ORM например

бэк-енд как уже сказали - можно в виде WebApi, а можно и wcf отдельный и только на публичные методы для EDI

а тут опять же, если EDI сам документы присылает - это одно, если надо их скачивать оттуда - другое

yabsтак вопрос не в том, нужен Worker или нет, а в том, как хостить модуль обработки(я его обозвал BACKEND'ом)
модуль обработки хостить как сервис (web-api или wcf)
можно сделать так, чтобы сайт тоже работал с сервисом, но там надо лезть глубже

но нужно еще средство вызова обработки, которое не давало бы сбой, тут три варианта:
1. не делать фоновой обработки вообще (если позволяет время ожидания и скорость алгоритмов и отклика внешних систем) - тогда как только документ поступает каким либо образом в систему - сразу же идет проверка
2. сделать планировщик на сервере (виндовая служба, либо воспользоваться внешним сервисом - hangfire)
3. сделать планировщик на клиенте (web worker), как предложили - но тут мне лично не понятно, а что если файл придет ночью, никто не работает в веб приложении - как воркер запуститься?

yabs,
теоретически можно обойтись только одним набором моделей - типа объекты предметной области, их же использовать в качестве контрактов для сервисов и уровень сериализации/десериализации будет на границе между бэк-ендом и потребителями (EDI/ASP.NET)

эти же сущности можно замапить на таблицы БД через ОРМ, я видел однажды очень хороший пример - довольно сложные сущности, но с помощью замысловатых маппингов с тонкой настройкой это все отражалось в таблицы БД через nHibernate

но на практике постоянно возникают всякие проблемы, то с контекстом ORM, то сущности становятся слишком перегруженными, то с отображением на UI (когда одна сущность имеет несколько экранов с немного разным набором полей для разных ролей пользователей), и т.п.

поэтому делают два слоя - объекты (сущности) предметной области (они же маппятся на БД) и модели для отображения (они же контракты для сервисов), маппинг соответственно между сущностями и моделями, наружу отдают модели, третий по идее лишний