?Как система BPM предлагает синхронизировать множество справочников, ведущихся в разных системах?Стремиться к систематизации и унификации НСИ нужно, никто этого не отрицает. Но при вынужденном использовании множества приложений иногда вынужденно приходится использовать несколько мест хранения схожей информации. Сам факт установки BizTalk на какой-либо компьютер "испарить" эту проблему как волшебная палочка не сможет. Но если вы действительно задались целью выделить источники и приемники информации и устранить дублирование ее ручного ввода, который должен быть заменен систематизированным автомтическим дублированием и только из источников в приемники, то в решении этой задачи BizTalk очень даже может помочь. Он в состоянии отследить появление новой информации в источниках и произвести автоматический перенос ее в приемники, по заданным правилам преобразовав форматы представления информации - для этого имеется очень удобный визуальный инструмент для настройки XSLT-преобразований. При этом можно не только разбить одно поле "ФИО" на три "фамилия", "имя" и "отчество", но и осуществить куда более сложные действия, связанные, например, с извлечением информации, которая в источнике в принципе отсутствует, из каких-то других мест (например, из СУБД). Такие более сложные действия производятся с помощью встраиваемых в схему XSLT-преобразования функтоидов. В BizTalk имеется очень богатый выбор функтоидов, можно также настроить и свои собственные.
?Что делать, если не все гладко с интеграцией между локальными системами? Например, приложение с, в принципе, открытым интерфейсом, позволяющим извлекать информацию из файлов его формата не может работать на сервере по причине нестабильности.Обработка ошибок - есть, если вы об этом. Есть также возможность с заданным интервалом предпринять несколько попыток выполнить некоторое действие, и только если по истечении заданного таймаута, либо числа попыток, выполнить его не удалось, только тогда сгенерить ошибку. Если в сам бизнес-процесс встроена логика реакции на ошибку, то он пойдет работать дальше по соответствующей траетории. Если обработка ошибки изначально в бизнес-процессе не была предусмотрена, но ошибка произошла и какой-то шаг не смог выполниться по непонятным причинам, "длинная транзакция" (о ней речь чуть ниже) попадает в пул аварийно остановленных, который должен мониторить некий администратор и реагировать на все неординарные ситуации.
?Как решены проблемы надежности передвижения информации, включая транзакционное поведение при взаимодействии с финансовыми системами и т.д.В BizTalk присутствует ДВА понятия "транзакция", и чтобы их как-то разделить, традиционная для СУБД ACID-транзакция называется "короткой транзакцией", а совокупность действий, инициированных по заданному алгоритму на одно элементарное воздействие (например, на одну конкретную поступившую от клиента заявку) - "длинной транзакцией". Длинная транзакция может выполняться днями, неделями, месяцами и даже годами. Требования ACID на нее не распространяются. Следовательно, такая транзакция не может быть "откачена" или "накачена", если не прописан конкретный механизм отката или наката. "Длинные транзакции" не блокируют данные и практически не задействуют вычислительные ресурсы, потому что основное свое время они представлены уже сохраненными в специальной бизтоковской базе записями и находятся в "спящем" состоянии. При перезагрузке серверов они восстанавливаются в том же состоянии, которое имели до перезагрузки - восстанавливается фаза алгоритма, на котором его выполнение было приостановлено в ожидании некоторых событий. Число одновременно выполняющихся "длинных транзакций", запущенных по одной и той же схеме бизнес-процесса может достигать космических величин. Не говоря уже о том, что и схем может быть множество.
Когда в BizTalk идентифицирует наступление какого-либо события (например, поступление по такому-то информационному каналу некоторого электронного документа или истечение анее выставленного таймаута), BizTalk сначала производит разборку поступившей информации с целью идентификации, к каким "спящим" длинным транзакциям это событие имеет отношение. Выявив эти длинные транзакции, он их "будит" (поднимает их из базы данных), передает им на обработку поступившую информацию. Длинная транзакции в соответствии с логикой действий на данном шаге бизнес-процесса куда-то лезет, что-то извлекает, куда-то компонует, передает дальше на обработку, поадает (например) в режим ожидания ответа и снова "засыпает". Когда ответ придет, BizTalk сам определит, что это ответ именно вот на ту конкретную порцию информации, снова "разбудит" длинную транзакцию и продвинет ее еще на один шаг. Длинная транзакция считается завершенной только тогда, когда ее выполнение достигло конечной точки бизнес-процесса. Тогда она помещается в пул выполненных длинных транзакций - по нему можно лазить OLAP, BI и т.п., чтобы, например, проанализировать статистику продаж.
ACID-транзакции могут запусаться на отдельных "шагах" длинной транзакции. При этом BizTalk может сам орагнизовать такую транзакцию и вторгнуться в конкретную БД конкретной СУБД. А может обратиться к услугам WEB-сервиса, положившись, что механизмы, за ним спрятанные, реализуют нужную ACID-транзакцию. Или, напротив, НЕ полагаться - тогда в алгоритм можно встроить некоторую проверку, типа "получилось ли выполнить всё, что задумывалось?".
Для обеспечения необходимой надежности каналов информационного обмена BizTalk может воспользоваться протоколами с гарантированной доставкой. Если нет возможности ими воспользоваться, можно использовать и более простые протоколы обмена информацией, но на уровне самого BizTalk настроить получение "квиточков", подтверждающих получение приемником информации от источника. Правда, для организации подобного квитирования желательно разместить BizTalk как на стороне приемника, так и на стороне источника. Или найти другой инструментарий, который будет выписывать квиточки и отправлять их, например, по электронной почте.
Если на стороне приложения, принимающего информацию, могут возникать ситуации, когда в связи с высокой загрузкой приложения оно не сможет принять и обработать информацию в момент обращения к нему BizTalk, можно воспользоваться очередью MSMQ или аналогичной очередью от IBM.
Короче, пространство для маневра имеется... :)
?Как работает такая система с файлами, занимающими в родном формате сотни мегабайт (фильмы, картинки, приложения САПР) при их пересылке, извлечении информации и т.д.?Так, как пожелает ХОЗЯИН... :) Можно передавать сами сотни мегабайт, можно передавать ссылки на файл, можно лазить в конкретную СУБД и извлекать BLOB по идентификатору записи...
?как решаются проблемы групповой работы над единым пакетом документов?Если деййствия включенных в группу сотрудников должны выполняться последовательно, они так же последовательно разрисовываются п алгоритме. Если они могут выполняться параллельно, в схему бизнес-процесса включается блок "fork" (вилка) с одним входом и несколькими выходами. Траектории, привязанные к нескольким выходам, могут выполняться параллельно. То есть, "длинная транзакция" будет считаться находящейся одновременно на нескольких стадиях бизнес-процесса разными своими ветвями и будет "просыпаться" и реагировать на множество разных событий, относящихся к ее разным ветвям.
Распараллеленные ветви вполседствии можно обратно свести в одну с помощью блока, смысл которого противоположен блоку fork. В этом блоке настраивается, считается ли он выполненным, когда пройдет выполнение по каждому входу, или хотя бы по одному из них.
?И еще много других вопросов, которые возникнут при внедрении на местах.Задавайте, если смогу - отвечу... :)
?Складывается такое впечатление, что решение этих вопросов находятся вне системы. Но тогда давайте отведем BPM свое место в автоматизации где-то рядом с почтовым сервером и контроллером домена и не будем пытаться отлить очередную серебряную пулю.BizTalk - это не серебрянная пуля и не волшебная палочка. Это просто инструмент, который имеет смысл прилагать там, где в нем есть необходимость и не имеет смысла прилагать там, где необходимости в нем нет (например, для планирования и автоматизации разовых работ использовать его бессмысленно).
инженер планового отделаВы ведь так и не объяснили почему 10+еще одна систем лучше корпоративной системыЯ не объяснил потому, что я так не считаю. Одна КИС, разумеется, лучше множества приложений, если она охватывает собой все участки, на которых предполагается использование других приложений. Да, было бы здорово, если бы кто-нибудь такое приложение сбацал. Но на практике это слишком сложно, и ни один поставщик софта еще не смог подать CAD+ERP в одном флаконе. Может быть когда-нибудь какой-нибудь Microsoft (например) сможет это сделать. Но, наверное, это будет "не в этой жизни" (моей, я имею в виду). Пока что Microsoft-овский Access может по-человечески коннектиться к базам Microsoft-овского же FoxPro только через борландовое BDE... Куда уж там до человеческой интеграции MS CRM с MS Axapta (например).
А есть еще приложения, которые мы
вынуждены использовать, потому что не от нас зависит - их использовать или не их. Например, если мы хотим иметь возможность обмена информацией в электронном виде в банком, то мы
ОБЯЗАНЫ поставить то ПО, которое нам банк притащит. При этом каждый из 10 банков, с которыми мы работаем, притащил своё
уникальное ПО. А еще мы подаем налоговую инспекцию сдаем отчетность в электронном виде. Заполняться она должна в "
Балансе-2 ", ответная часть от которого торчит во всех налоговых инспекциях Москвы. Форматы взаимодействия этих частей известны только "Овионту". А еще мы сдаем в электронном виде данные по персонифицированному учету, СЗВК и по неподтвержденному экспорту с помощью ПО, разработанного ГИВЦ Москвы. А еще мы пользуемся ПО наших эксклюзивных поставщиков для выбора из их каталогов оборудования по заданным характеристикам.... Список можно долго продолжать...
Да, я тоже считаю, что нужно постараться максимум информации сконсентировать в едином центре обработки - в КИС, но я также отдаю себе отчет, что на практике это удастся выполнить только до некоторой степени, а не абсолютно.
инженер планового отдела...какая именно информация о движении материи в простанстве и времени относится к "бизнес-процессу", а какая - нет ?О!... Какая обширная тема!... Столько буковок мне на винчестер не влезет... Ладно, попытаюсь быть краток... :)
По-моему, имеет смысл говорить о "бизнес-процессах", когда речь идет о планировании и управлении какими-то повторяющимися действиями. Пусть эти дейсвтия даже отчасти меняются, пусть повторяются они конечное число раз, но только если они могут расцениваться как повторяющиеся, только в этом случае имеет смысл рисовать в BizTalk или в какой-то другой BPM схему бизнес-процесса. Если речь идет о выполнении каких-то уникальных одноразовых действий, пусть их совокупность и сложная, тогда имеет смысл рассматривать управление такими действиями с точки зрения "управления проектами".
Оптимизация и автоматизация этих двух видов управления и в японском менеджменте, признанном наиболее эффективным во всем мире, разделяется на "кайкаку" (в американской терминологии - "таргет-костинг") - радикальное разовое усовершенствование и "кайзен" - эволюционное циклическое усовершенствование. В разных подразделениях разных предприятий акцент делается либо на первом, либо на втором. Методы, подходы - совершенно разные. Но на многих японских предприятиях они сосуществуют и гармонично дополняют друг друга. На этапах стратегического планирования обычно используют таргет-костинг. При разработке новых продуктов - тоже. Для управления уже запущенными в производство продуктами используют кайзен-костинг. Так вот, о "бизнес-процессах" имеет смысл говорить только в ракурсе кайзен-костинга.
Только . Но если они не охватывают собой всю концепцию мироздания, то это не значит, что их нужно выкинуть на помойку!
Ну надо же, уложился в размер винчестера! :)
