среда, 15 апреля 2009 г.

SAP и уникальность имен файлов

Враг вступает в город, пленных не щадя
Потому что в кузне не было гвоздя.


Уж не знаю, это конструктивная особенность SAP, или у кого-то из наших ребят кривые ручки... но во всяком случае, для каждого типа файлов у нашей SAP есть фиксированное имя. В имени нет ни даты, ни порядкого номера. Каждый тип файла мы отправляем в SAP два раза в день. Получается, что если они по какой-то причине не обработали входящий файл (например, не смогли скачать с FTP), то через какое-то время наш BizTalk этот файл затрёт более свежим. SAP тупо обработает, потому что ей пофиг, в каком порядке приходят файлы. Но вот нашей системе не пофиг, в каком порядке приходят квитанции, она хочет всё обработать по порядку.

Вобщем, случилось то, что и должно было когда-то случится: проблема, а точнее сразу две. Во-первых, из-за пасхальных выходных SAP была выключена, во-вторых, ещё и сеть глюкнула... короче, теперь полный бардак. Файлы за понедельник не обработаны, за вторник частично обработаны, за среду опять не обработаны... А разработчик, естественно, в этот момент оказался в отпуске в ЮАР. Вдобавок SAP стоит в Америке, т.е. я задал вопрос, а из-за разницы по времени ответ получил только под вечер. Второй день пошел, проблема ещё не решена.

Приходится мне сидеть в офисе и ждать. Я тупо отправляю им заново все файлы, по очереди. Но это занимает кучу времени, потому что с их стороны ни у кого нет нужных прав доступа, т.е. в простой операции участвует несколько человек. У меня тоже прав доступа вообще-то не было, но наш админ убегал на футбол, поэтому он предпочел дать права мне, а не сидеть самому допоздна. А сделать это завтра с утра пораньше я не могу, потому что у американцев ещё будет ночь.

"А всё случилось только от того, что кто-то правила не знал одного": имена файлов обмена должны уникальными. Если не совсем, то уж хотя бы в течение месяца; ну, или как минимум, в течение одного дня.

Опять-таки, буржуям есть чему поучиться у украинского Нацбанка. У НБУ имена файлов всегда были уникальные в течение года. И то, только потому, что они использовали досовский формат имен 8:3, т.е. длины не хватало для полной уникальности. Помню, на порядковый номер $A в течение дня выделялось два символа в 36-ричной системе (да-да, именно так; не в 32-ричной!) Таким образом, за день банк мог отправить не более 1296 платежных файлов. Но это было вполне достаточно, потому что в одном файле может быть куча платежей.

Правда, когда началась разработка Системы Срочных Переводов, то Нацбанк дал маху. Меня сразу смутило, что они решили давать идентификаторы транзакциям по таким же правилам, что и файлам $A. Но в одной транзакции ССП может быть лишь один платеж, т.е. выходит, что банк может послать только 1296 срочных платежей в день. Обычно этого тоже достаточно, потому что ССП используется только для "серьезных" платежей. Но если большой банк работает по единому коррсчету, то может и не хватить. По-моему, потом они все же осознали и исправили это.

4 комментария:

Анонимный комментирует...

Ахаха, вот это жесть! Чем больше работаю над большими системами, тем больше понимаю на каких соплях они держатся. Железо умирает, инет лагает, транзакции не закрываются, плюс человеческий фактор. У нас обычно такие файлы также содержат в имени file_name_day_month_hour плюс все в транзакциях, и если запись обработана - в бд меняем флаг.

Спасибо за статью! Кстати как вам SAP ? Как вам Biz Talk? стоит их изучать? Песпективно?

Valik комментирует...

SAP я сам не видел. Только отправляю-принимаю от них интерфейсы, и всё.

А BizTalk вроде неплохая штука. Но надо чётко понимать, что это не панацея для любого обмена сообщениями. Он большой и медленный, но зато очень мощный. Его надо использовать для интеграции приложений, а не внутри приложения.

Для других целей есть другие технологии. Например, SQL Broker, если нужно обмениваться сообщениями между SQL Serverами; Tibco RV, если надо быстро слать, к примеру, биржевые сведения; или новый, еще не выпущенный официально продукт Dublin. Это примерно то же самое, что и BizTalk, но для использования внутри .NET приложения.

Kozhukhar Maksym комментирует...

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

SAP тут ни при чем, это все подход к разработке, который потом приводит к головной боли многих людей.

Пару раз сталкивался когда использовали BizTalk только потому что это не стоило им денег, как партнерам МС. Но на самом деле этот продукт был неподходящим для решения задач и его настройка и разработка отняла гораздо больше усилий и ресурсов.
Как говорится скупой платит дважды. Очевидно, причина кроется в начальстве которое часто очень далеко от понимания технической стороны, и это приводит к принятию неправильных решений.

А что за Dublin, чей это продукт? Не слышал о таком.

Valik комментирует...

Да я и подозревал, что не может быть у SAP такой идиотизм заложен изначально.

А Dublin, насколько я понимаю, будет поставляться вместе со следующей версией Visual Studio. Может, Microsoft его потом переименует в какой-нибудь .NET Applicaion Workflow Server или что-нибудь в таком духе.

Ratings by outbrain