Здравствуйте, Tatyana,

"Тот мессадж который я получил в ресив" -я не инициализирую, зачем, ведь если я его получаю с порта в обьект Ресив, он должен там инициализироваться. Я пытаюсь взять данные из мессаджа, который я получил из ресива и использоваться их для запроса в мультипартовом мессадже! А мультипартовый мессадж инициализирую руками так как в трансформайшен шайпе его не получается инициализировать!!!.

p/s сумбурное получилось обьяснение проблемы, возможно с Вами можно связаться другим путем, например по телефону или
icq.

p/p/s мой емаил — Vkiselev@IT.ru




Вы писали:

T>Message из схемы никогда автоматически не инициализируется.
T>Надо либо инициализировать его в expression shape, либо в Transformation shape.

T>Вы в message assignment пытаетесь еще раз инициализировать тот мессадж, который получили в Receive?

T>

---

данное сообщение получено с www.gotdotnet.ru
T>ссылка на оригинальное сообщение

В чем может быть ошибка?
There was a failure executing the receive pipeline: "Microsoft.BizTalk.DefaultPipelines.XMLReceive" Source: "XML disassembler" Receive Location: "D:\Projects\Receive\*.xml" Reason: The disassembler cannot retrieve the document specification by using this type: "Forum". Either the schema is not deployed correctly, or more than one schema is deployed for the same message type.

Здравствуйте, Slonyara, Вы писали:

S>В чем может быть ошибка?
S>There was a failure executing the receive pipeline: "Microsoft.BizTalk.DefaultPipelines.XMLReceive" Source: "XML disassembler" Receive Location: "D:\Projects\Receive\*.xml" Reason: The disassembler cannot retrieve the document specification by using this type: "Forum". Either the schema is not deployed correctly, or more than one schema is deployed for the same message type.
Неуверен, но что то ты напутал с namespace в XSD схеме. Проверь еще раз все. Валидность документа по схеме проверял?

Здравствуйте, Татьяна!
Т.к. нет отдельного форума по бизтоку то придется "отдуваться" Вам.
Попытался реализовать с виду простой процесс, но не смог. Подскажите плз как его можно сделать "в принципе", ну и если получится, укажите наиболее изящное (я имею ввиду с минимумом кода) решение.
Задача упрощенно выглядит так:
Есть входное сообщение, содержащее N записей, состоящих из 2 полей. Надо получить точно такое же выходное сообщение, но запись содержит 3 поля. Первые 2 поля заполняются значениями из входного собщения, а вот третье поле должно быть заполнено в оркетсрейшн значением из переменной.
Напр. вх. собщение:
<root>
<record><f1>Value1</f1><f2>Value2</f2></record>
<record><f1>Value3</f1><f2>Value4</f2></record>
...
</root>

Вых. сообщение должно быть:
<root>
<record><f1>Value1</f1><f2>Value2</f2><f3>MyConstant</f3></record>
....
</root>

Заранее благодарен!

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Можно сообщение прогнать через map чтобы создать поле(я) f3.
Если вы можете вычислить ту же переменную в map, а не оркестрейшн, то вообще здорово.

Если все это делать без map, то надо писать код либо в expression shape, либо в другой dll и вызывать ее, чтобы сделать то что вам нужно.

Если бы поле уже было созданно в исходном сообщении, тогда можно было бы использовать property promotion чтобы просто установить значение. Однако в вашем случае поле еще не создано.

Татьяна

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Добрый день, Татьяна... поскольку форума по Бизтолку все еще нет...

У меня проблема следующая — процесс бизтолка будет "пропускать" через себя вызовы 2х других систем.. система А хочет получить ответ на некий запрос от системы Б.. Между системами ставится бизтолк, который как бы перенаправляет запросы.. Нужно разработать оркестровку и опубликовать ее в виде вебсервиса — собственно к нему и будут обращаться системы.

Я прочла, что при публикации каждый порт становится вебсервисом, а операции, которые сдержатся в нем- вебметодами.
В моей постановке вебсервис-бизнес-процесс должен иметь 3 вебметода. Другими словами оркестровка должна иметь один порт (будущий вебсервис) с 3мя операциями по типа реквест-респонс.

Я не могу понять как должен быть организован сам бизнес-процесс... операции порта будут привязаны к разным типам сообщений. Значит инициировать оркестровку по получению сообщения по любому из вебметодов не получится...

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

если я получу сообщение типа 1, начну его обрабатывать, и до окончания его обработки получу сообщение типа 2 (другая ветка распараллеливания)? примет ли его мой бизнес-процесс?

помогите, пожалуйста идеями — или статьями..
спасибо большое

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Предусмотрена ли для бизтока возможность запуска оркестровки по расписанию и чтобы получив данные из Receive port'a и обработав их сборка перешла в неактивное состояние? Или надо писать что-то самописное для обращения к методам СОМ объектов бизтока для активации/деактивации сборки.

А возможно ли сделать исходящий xml фаил без namespace`ов?

Здравствуйте, gaploid, Вы писали:

G>А возможно ли сделать исходящий xml фаил без namespace`ов?
а что за ошибку выдает? Не задаешь namespace для схемы и сохраняешь её в файл. Не пробовал, но проблемы вроде не вижу. Через свою сборку можно в кр. случае

Здравствуйте, alex_kostylev, Вы писали:

_>Здравствуйте, gaploid, Вы писали:

G>>А возможно ли сделать исходящий xml фаил без namespace`ов?
_>а что за ошибку выдает? Не задаешь namespace для схемы и сохраняешь её в файл. Не пробовал, но проблемы вроде не вижу. Через свою сборку можно в кр. случае

Валит кучу ошибок при компиляции, похоже что наймспес задавать нужно обязательно, я не много описался в вопросе. Хотел сказать как создать исх. xml без namespaceовых префиксов — типа ns0 и т.д. Видел решение через написание своей сборки для удаления префикосов, но возможно есть более цивилизованный способ=)

The same topic (Sorry for english — have no russian installed):

Proposal Solution: accept flat files and process only filtered with “Tran_Type” column value in it.
1) Created flat file schema
2) Created destination flat schema
3) Promoted property Tran _Type in source schema
4) Created schema mapping
5) Created Receiving pipeline and place flat file disassembler to it and specify document schema of source specified in item 1
6) Created Send pipeline and place flat file assembler to it, specify document schema as destination specified in item 2
7) Configured receive port with schema mapping
8) Add receiving place with receiving pipeline
9) Add send port with send pipeline
10) On send port add filter on promoted property
I tried put flat file in receive location, but have got following error:
Receive pipeline….:
Exit Code: 0xC0C01680
Error Info: Could not find a matching subscription for the message.
The Messaging engine failed to process a message submitted by adapter:C:\BTS\FileDrops\In\*.*. Details:Could not find a matching subscription for the message. . This error occurs if the subscribed orchestration schedule or send port has not been started, or if some of the message properties necessary for subscription evaluation have not been promoted. Please refer to Health and Activity Tracking tool for more detailed information on this failure
What I have done wrong?

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

send порты стартованы? У тебя валится на recieve или на send? Что НАТ говорит?

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Добрый день!
С новым годом — всего всем хорошего !

У меня следующий вопрос: я хочу определить систему интеграции исходя из соотношения цена/качество. Основной анализ затрагивает BizTalk и Websphere MQ. Решение Microsoft мне нравится больше, но стоимость его значительно больше, если учитывать весь необходимый спектр ПО, а именно MS windows 2003, MS SQL Server (особенно при установке например на двухпроцессорный сервер). огли бы ли Вы как менеджер развееть мои сомненья, а именно пояснить — правильно ли я провожу расчет стоимости BizTalk, а так же указать явные приемущества (общие) вашего продукта.

Расчет производится для 64 разр 2-х процессорного сервера:
— 6999 $ * 2 процессора = 13998 $ (BizTalk standart edition)
— 3899 $ MS SQL Server (workgroup edition) * 2 процессора = 7798 $
— 1199 $ Win Server 2003 R2 snd edition
итого: 22995 $

продукт конкурента значительно дешевле !

И еще один вопрос: на сайте microsoft можно прочитать следующее

In BizTalk 2006, an application is a logical grouping of all the BizTalk design-time artifacts (schemas, maps, pipelines, orchestrations), messaging components (receive ports, receive locations, send ports) and other related items such as policies that comprise an integrated business process. BizTalk applications simplify the deployment and management of BizTalk based solutions

Прошу более точно определить понятие приложение (application), просто я не представляю какой объем логики я могу реализовать на базе сервера (standart edition) !

Заранее благодарен

Никитин Алексей

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

суть проблемы: на вход Biztalk поступает сообщение, состоящее из 30-40 записей. Сообщение парсится на отдельные сообщения и в цикле они обрабатываются. Первые 15-20 сообщений ложатся в БД сразу, остальные заливаются с промежутком 5 мин по 7 записей. в списке операций для каждого сообщения последним стоит обращение к send порту для MS SQL — вызов несложной процедуры. В HAT видно что для оставшихся необработанных записей request сообщение для этого порта ставится в статус dehydrated и через каждые 5 минут они пачками по 7 сообщений обрабатываются, что очень медленно, поскольку планируется поток до 100-500 сообщений в минуту

5 минут взялось из настроек send порта — retry interval. После установки в 1 минуту ситуация исправилась. Но я думаю что при значительном увеличени числа записей опять получим что они будут обрабатываться небольшими пачками через некий интервал. Видимо на BTS для обработки сообщений есть некий планировщик управления потоком сообщений, который предотвращает зависания BiztalkServerApplication при большом потоке сообщений. Как бы им управлять.

Хотелось услышать мнение знающих людей про эту ситуацию.
Кстати, можно это лечить установкой приоритета для send порта? И как вообще с производительностью у BTS? Может есть у кого практический опыт тестирования BTS под нагрузкой?

Не давно тестировал на нагрузку около 5000 сообщений. получилось так что апликейшен сервер начал валить варнинги и кричать что он не будет ни чего делать пока нагрузка не уменьшиться=) когда кол-во сообщений постумаемых БТС прекратилась я так понимаю уменьшилась кол-во сообщений передаваемых в секунду он просто махом обработал все целиком и выпленул результат. Насколько я помню есть настройки для потока обработки и забора сообщений настраевыемае через реестр.

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Не могу найти, но раскажу что нужно искать. Есть такая настройка как количество одновременно обрабатваемых потоков. По умолчанию по моему мнению 10(15). То есть если поступает 11 сообщений, то 10 начинает обрабатываться, а 1 (11 — 10) стоит в очереди. Как найду сообщу. В 2002 я устанавливал на 100 для работы.

По поводу описания процесса. Не совсем понятно. У вас есть 1 ресив порт и все обрабатывается в нем? Или же из него кладется N сообщений в другой?

Здравствуйте, SEDEGOFF, Вы писали:

SED>Не могу найти, но раскажу что нужно искать. Есть такая настройка как количество одновременно обрабатваемых потоков. По умолчанию по моему мнению 10(15). То есть если поступает 11 сообщений, то 10 начинает обрабатываться, а 1 (11 — 10) стоит в очереди. Как найду сообщу. В 2002 я устанавливал на 100 для работы.

SED>По поводу описания процесса. Не совсем понятно. У вас есть 1 ресив порт и все обрабатывается в нем? Или же из него кладется N сообщений в другой?

вкратце схема такая:
есть Receive из которого получаю ID измененных записей. По этим ID для каждой записи дергаю xml из src БД. Потом идет конвертация этих XML по таблицам справочников для Biztalk. Сконвертированное сообщение (содержащее записи сконвертированных xml) сливается в send port (FILE), из которого читается оркестровкой рассылки. В ней по каждой записи извлекается xml, вызывается Start Orchestration, которая записывает xml в целевую систему и после успешного добавления в БД пишет в справочники звязку старого и нового ID путем вызова send port'a (SQL). Вот перед этим вызовом происходит dehydrated. Оказывается на этом вызове ловим ошибку блокировки (видим через Event viewer) и через retry interval еще раз пытаемся вызвать XP. Тормоза связаны с блокировками. Сразу много потоков пытается обратится к send port и кто уcпел, тот прошел. Получается что на время выполнения BTS ставит блокировку? (внутри ХП никаких транзакций не наблюдается) Что происходит когда много потоков пытаются вызвать send port (SQL)?

Кстати, я думаю надо смотреть на Transaction Type оркестровки рассылки. Главная оркестровка, в которой происходит парсинг входящего сообщения на части, работает в long running, вызывающая send port — Transaction type = none.

Ух. Правильно ли я понял: Есть 3 БД: DBSRC — исчточник ID и XML, DBLIST — справочные значения и DBDES — приемник XML файлов
//первый оркестр
1. SQL Recive port получает измененнные ID из DBSRC
2. На основании этих ID и XML из DBSRC и справочных значений из DBLIST создается один большой XML файл
3. Результат пункта 2 сохраняется в файл
//второй оркестр
1. Запускается цикл, который перебирает все ID. И для каждого ID выполняется
2.1 Сохранение XML в DBDES и получение DBDES.ID
2.2 ID их XML и DBDES.ID передаются в SQL send port. В резльтате это записывается в DBLIST

Правильно?

BTS блокирует только если запущено максимально допустимое значение потоков — остальные ждут когда освободится место под солнцем. Блокировка идет в SQL server. Собственно вопрос — во 2 оркестре у тебя код цикла помещен в try/catch?

Здравствуйте, SEDEGOFF, Вы писали:

SED>Ух. Правильно ли я понял: Есть 3 БД: DBSRC — исчточник ID и XML, DBLIST — справочные значения и DBDES — приемник XML файлов
SED>//первый оркестр
SED>1. SQL Recive port получает измененнные ID из DBSRC
SED>2. На основании этих ID и XML из DBSRC и справочных значений из DBLIST создается один большой XML файл
SED>3. Результат пункта 2 сохраняется в файл
SED>//второй оркестр
SED>1. Запускается цикл, который перебирает все ID. И для каждого ID выполняется
SED>2.1 Сохранение XML в DBDES и получение DBDES.ID
SED>2.2 ID их XML и DBDES.ID передаются в SQL send port. В резльтате это записывается в DBLIST

SED>Правильно?

SED>BTS блокирует только если запущено максимально допустимое значение потоков — остальные ждут когда освободится место под солнцем. Блокировка идет в SQL server. Собственно вопрос — во 2 оркестре у тебя код цикла помещен в try/catch?

пркатически. 2-я оркестровка состоит из 2-х: в первой перебираем сообщение, для каждого ID формируется отдельное сообщение и передается асинхронно (Start orchesration) в оркестровку отправки в целевую БД, которая выполняет п-ты 2.1 и 2.2. Т.е., видимо, получаем большое количество потоков для каждой оркестровки отправки. Я бы сделал синхронный вызов с ожиданием результата отправки, но пропарсить входящее сообщение по записям можно только в атомарной транзакции, из которой нельзя вызывать синхронно другие оркестровки. Это мой первый проект на БТС, такая схема показалась наиболее разумной