Я ищу лучшее решение, позволяющее нашим пользователям загружать электронные таблицы XLS, чтобы их можно было использовать для заполнения таблиц в нашем хранилище данных (DW).
Наши пользователи являются активными пользователями Business Object (BO), а BO позволяет экспортировать в XLS. Когда у них есть данные в электронной таблице, которые необходимо загрузить в DW, им нужен процесс для загрузки данных в XLS в базу данных DW. В результате мы получаем множество таких «интерфейсов», когда я думаю, что нам действительно нужен программный автоматический канал. Использование Excel в качестве источника данных для межсистемных каналов, на мой взгляд, кажется мне плохой идеей.
Вопрос № 1: Хотелось бы узнать, согласны ли вы с этим и почему или нет.
Ладно, против этого течения нет никакого смысла, так что теперь я понимаю, что загрузки XLS здесь, чтобы остаться для нас. Теперь мне нужно найти лучшее решение. Сначала я объясню, что мы делаем сейчас, а затем, что мне не нравится в этом:
На веб-страницах мы предоставляем пустые файлы XLS (без строк) с определенным набором столбцов. Каждый файл предназначен для обновления другой целевой таблицы. В каждой таблице есть кнопка «Загрузить». Нажатие кнопки «Загрузить» приводит к макросу в электронной таблице, сериализующему содержимое файла в CSV и отправляющему данные в папку на сервере. Периодически планировщик запускает задание Informatica ETL, которое использует CSV-файл в качестве входных данных и загружает данные в пользовательскую промежуточную таблицу, специфичную для XLS, а затем, если записи проходят редактирование, в соответствующую целевую таблицу. Все обнаруженные ошибки заносятся в таблицу ошибок. Для каждого загруженного файла XLS данные попадают в отдельную таблицу подготовки и ошибок, специфичную для этого файла.
Некоторые вещи, которые мне не нравятся в нашем процессе:
1) Код макроса в XLS слишком открыт, включает, например, пароли, может быть подделан и существуют проблемы, гарантирующие, что пользователи используют последние шаблоны XLS.
2) Изменения бизнес-правил помещаются в программу ETL, где они, вероятно, должны быть, но, поскольку мы хотели бы отследить ошибки как можно скорее, то есть в электронную таблицу, изменения также добавляются в код макроса. Это приводит к дублированию деловых изменений. Я хочу, чтобы эти правила находились в одном месте и контролировались централизованно. ИМХО, я думаю, что помещение любого макрокода в XLS приводит к проблеме обслуживания, даже к вызовам хранимых процедур (некоторые из которых у нас есть) или к веб-службам (мы еще не пытались вызывать .NET Web Services из макросов XLS. )
3) Каждый шаблон загрузки файла XLS имеет свой собственный процесс с отдельным набором таблиц подготовки и ошибок и настраиваемым экраном для сообщения о найденных ошибках. Похоже, нам нужно более обобщенное решение для многократного использования.
Помимо частого получения данных, экспортируемых в XLS из BO, пользователям также нравится Excel, потому что редактировать большое количество записей проще и проще, чем редактировать отдельные записи через веб-интерфейс.
Это общее направление, о котором я думаю:
Во-первых, я хочу, чтобы пользователи имели простоту редактирования Excel с помощью редактирования, но без включения встроенных макросов в электронную таблицу. Я экспериментировал с сеткой Farpoint с совместимостью с Excel ...
http://www.fpoint.com/netproducts/spreadweb/tour/excel.aspx
... и я обнаружил, что было довольно просто дать пользователю возможность открывать файл XLS, который находится на его ПК, открывать его в браузере и иметь легкий доступ к данным, считанным с сервера. .NET веб-код. Excel не запускается локально в их браузере, но функциональность Excel воспроизводится, предположительно, через множество сценариев на стороне клиента, которые, как я ожидаю, будут настоящей болью для дублирования себя. Вы можете даже вырезать и вставить из локальной таблицы в электронную таблицу. Это звучит здорово, самой большой проблемой является стоимость. Наша компания близка к смерти и не позволит нам приобретать новое программное обеспечение.
Далее я хочу определить общие компоненты для всей обработки загрузки электронных таблиц и предложить общий код обработки. Например, я представляю таблицу, которая определяет каждую из наших электронных таблиц и формат каждой, включая имена столбцов и определения типов данных, возможно, с точки зрения их целевых столбцов вместо жесткого кодирования. На основе этого определения шаблона таблицы я могу сгенерировать шаблоны XLS для загрузки из этого определения таблицы. Я также могу выполнить простые общие изменения, чтобы убедиться, что введенные данные соответствуют определению таблицы. И одна общая веб-страница может использоваться для представления данных и разрешения ошибок несоответствия типов данных отчета и позволяет пользователю их исправлять. Я также определил бы общую таблицу для хранения данных в «промежуточной» таблице, используя таблицу с двумя столбцами, номер отправки, номер строки, имя и значение, возможно. «Больше ничего не нужно» - цель.
Далее мне нужно решить, куда поместить бизнес-правила. MGT моего отдела твердо верит, что вся загрузка данных должна выполняться пакетными процессами Informatica ETL, и поэтому правила / изменения принадлежат «Informatica». У меня нулевой опыт работы с инструментами Informatica, я скорее парень .NET. Поэтому я не уверен относительно того, как эти правила реализованы, но я подозреваю, что их нельзя использовать повторно в том смысле, что они могут использоваться веб-страницей .NET для проверки конкретной записи. Видите ли, в некоторых случаях, когда пользователь не выполняет массовую загрузку, у него есть возможность редактировать определенную запись, и я хотел бы, чтобы те же изменения, которые были применены процессом массовой вставки ETL, были применены к отдельному обновлению попытка одной записи через веб-страницу. Если решение написать один веб-сервис или хранимую процедуру, которая может быть вызвана либо с веб-страницы, выполняющей обновление одной записи, либо вызывается тысячи раз для каждой записи в массовой загрузке? Последнее звучит неэффективно.
Ваши мысли по поводу всего вышесказанного будут очень приветствоваться.