Итак, разобравшись с RoleLinks и Parties, можно приступать непосредственно к BAS - Business Activity Services. В чем здесь идея? Идея в том, чтобы, используя, с одной стороны, инфраструктуру RoleLinks и Parties, связать orchestrations с внешним миром. С другой стороны, этот "внешний мир" представить конечному пользователю через STS(SPS), дав ему возможность оттуда и наблюдать (BAM) за поведением orchestrations (которые оттуда уже будут называться Business Processes) и обмениваться сообщениями с работающими orchestrations (Hws). Таким образом, BAS - это, прежде всего, интеграция BizTalk с SharePoint и InfoPath. На основе BAS работают BAM и Hws. Разобраться с BAS означает разобраться с этой интеграцией. А это, в свою очередь, означает вспомнить (или лучше сказать, познакомиться заново) относящиеся к делу концепции SPS и InfoPath. Начнем с регистрации BizTalk Server в SPS[1]. Установка BAS добавляет к существующему SP virtual server несколько Web services. Сегодня нас будет интересовать TPPubWS из <BTS root>\Business Activity ServicesTPMPublishing. Практически все его методы служат front-end для основной базы BAS : она называется TPM - Trade Partner Management. Например, регистрацией BizTalk Server для BAS занимаются методы UpdateBizTalkRegistration() и GetBizTalkRegistration(), которые работают с таблицей BizTalkServer. Достаточно просто на нее взглянуть, чтобы узнать, откуда BASSite знает эту информацию.
Sunghwa Jin огласил прекрасный список того, почему DestinationParty resolution may fail. Особенно обращает на себя внимание ответ на его пост от Amando Resendez. By default, as far as I remember, both BizTalk hosts run at account - e.g. without domain name. Never mentioned in documentation, hovewer, it's so critical - to run both IIS app pool thru which HTTP receive location will authenticate incoming requests and BTS IsolatedHost. Secondly, I forget this completely (because SSO?) - HTTP send port must use authentication for outgoing requests as well. By default it is configured to use anonymous. Although this happens after DestinationParty is actually resolved, it is also important.
Put attention : authentication trusted flag on BTS host means that MessageBox will adopt the messages not only from the account that runs such a host.
P.S. Some configuration details, for example:
HTTP receive location URI - /PBossReceive/BTSHTTPReceive.dll?PBoss (and receive port must require authentication.
HTTP Send port URI (for partner inbox) - http://<servername>:8080/StsWebReceive/default.aspx?PartnerId=PBoss&FolderType=MessagesInbox (and use Kerberos autnetication)
Is that a good idea to publish (edited by Dan alongside) some addendums to .NET Essentials. I'd call this collection like ".NET Essentails. Simplified". One of the articles to compile is this one by Jan Seda on strong names. Thanks, Jan.
I'm not talking about BPEL. Sometimes you need just to obverve it or discuss with others. Although MS released Visio plug-in for orchetrations, I'd like to point to CutePDF! Really cute and may be powered with SDK! For Office 2003 owners, MS has Office Document Imaging Printer as alternative.
7 application blocks (now called Enterprise Library) still fight against log4net. Besides the winner, both seem to be good for BTS instrumentation. More technical oversight may be found here. Also for instrumentation, worth to consider Paul Bunyan.
DestinationParty property is used to resolve the send port within the RoleLink. Once DestinationParty is initialized, the orchestration looks back (thru bts_Party and bts_party_sendport tables in Management DB) for the associated send ports for desired operation. Therefore, the question of interest is how to initialize DestinationParty?
Generally, it depends on the initiating role of the RoleLink.
If the role stated for initiating is an implements role (thus, the orchestration receives messages thru this role), the DestinationParty property is initialized automatically by receive. Such an initialization occurs as follows:
· involved uses role is determined from RoleLink,
· its enlisted party is determined from configuration settings,
· its PartyID inserted into DestinationParty property.
From here the orchestration resolves the send port as mentioned below.
If the role stated for initiating is a consumer or uses role (thus, the orchestration send messages thru this role), the DestinationParty property must be initialized explicitly in the orchestration:
ConfirmOrder(Microsoft.XLANGs.BaseTypes.DestinationParty) =
new Microsoft.XLANGs.BaseTypes.Party(<value>, <qualifier> );
В прошлый раз я упомянул, что Receive Adapter должен уметь[1] выставить "WindowsUser" property, если его попросят. Осталось разобраться в том, как его "попросить". Во-первых, понятно, что не каждый адаптер умеет провести authetication. Что может значить authentication для, например, File Adapter, когда файл, в котором находится message, попал в receive folder простым xcopy? С другой стороны, адаптер, который умеет проводить authentication (HTTP Adapter, например) и "просить" об этом не надо - пусть себе всегда его и проводит, кому это мешает? Т.е. единственная возможность "попросить" адаптер произвести authentication это потребовать, чтобы, соответствуюший в pipeline, ResolveParty component взаимодействовал с некоторыми другими properties, кот. устанавливаются адаптером. А именно, для этого существует context prperty - AuthenticationRequiredOnReceivePort. ResolveParty component проверяет установлена ли она в false, и если false, неудача в попытке party resolution приводит только к тому, что BTS.WindowsUser и BTS.SourcePartyID остаются пустыми. Сам же передаётся дальше (например в orchestration). Если же AuthenticationRequiredOnReceivePort стоит на true, то неудача в party resolution, приводит к такой ошибке :
"There was a failure executing the receive pipeline: "Microsoft.BizTalk.DefaultPipelines.XMLReceive" Source: "Microsoft.BizTalk.Pipeline.Components" Receive Location: "D:okeyPrintDocIn*.xml" Reason: There was an authentication failure. "The party corresponding to the inbound message cannot be identified".
[1] Из адаптера, как и из pipeline, добраться до этого property довольно просто. Из - сложнее (say, possible) (запись от 4.4.05)
Party можно определить или через BizTalk Explorer или через BASSite. В обоих случаях будет использоваться ExplorerOM. Для party на этом этапе определяется alias. Для BASSite (Create Partner Profile) это выглядит, как выбор Property Name Qualifier из списка, заранее имеющегося в InfoPath. Важнейший qualifier из этого списка - "WindowsUser". Для BizTalk Explorer это выглядит почти также только с той разницей, что здесь вместо слова property используется именно alias и выбор производится не по и выбор производится не из списка qualifiers, а из списка имен (Names). Для "WindowsUser" его Name будет -"Windows User" (с пробелом). Value связет alias с реальным миром. Здесь может быть указан любой член группы 'BizTalk BAS Users'.
После того, как party определен, он сможет быть определен с помощью PartyResolition pipeline component. Если не рассматривать определение party по certificate, этот процесс происходит так: Receive Adapter, если указано, должен уметь провести authentication и поместить в message context propery "BTS.WindowsUser" (не путать с alias qualifier!). ResolveParty pipeline component ищет в Confoguration Database party, соответствующему этому property. (ResolveParty component включен и в XMLReceive pipeline) Если party найден, в orchestartion попадет message, в котором будут установлены следующие context properties : 1). PartyName (http://schemas.microsoft.com/BizTalk/2003/messagetracking-properties - MessageTracking.PartyName), 2) SourcePartyID (http://schemas.microsoft.com/BizTalk/2003/system-properties - BTS.SourcePartyID). Обе properties - not promoted, т.е. доступны из orchestartion как msg(MessageTracking.PartyName) и msg(BTS.SourcePartyID). Относительно OriginatorPID, то этот будет выставлен только если ResolveParty pipeline component призводит resolution by certificate. Во всех остальных случаях OriginatorPID будет stamped with "s-1-5-7", which is the SID of an anonymous user.
Итак, на этом этапе мы умеем определять party, использовать HTTP Adapter в сочетании с IIS для выставления в получаемых messages - "WindowsUser", использовать XMLReceive pipeline для party resolition и наконец, получить context properties - PartyName и SourcePartyID - из orchestartion. Не так уж и мало для одного выходного, да еще и под победную ничью с Ирландией 1:1.
Длинная это история, как кумранские рукописи попали в музеи, как они каталогизировались и как часть из них дошла до Музея Книги в Иерусалиме. Список, известный на сегодняшний день, включает, удивительно совпадающий со знакомым сегодня, текст Исайи, части Псалмов, книгу Еноха (кто такой Енох?) и еще много чего. Но среди этого "много чего" есть и выдержки из книги Бытия (Берейшит). Тут я и хочу остановиться. Я не историк - честно сказать, меня не очень интересует жизнь кумранской общины (1-й векa до н.э.), меня больше интересует, что же было написано в этих выдержках. И причем интересует меня это в свете того, что ортодоксия совершенно однозначно утверждает, что ни одна буква в книгах Торы не была измена со времени ее "данности". Это утверждение имеет для них отнюдь не историческую, а, я бы сказал, методическую ценность. На нём выстроен целый подход к изучению (я уже не говорю - к переводу или даже к переписыванию) этих книг. Сколько светлых голов туманилось в комментариях об орфографии, об инструментировании(огласовании, нижнем и верхнем) или даже о величине написанных букв? И все это благодаря постулату о неизменности Торы в том виде, в каком она была получена Моше.
А вот, оказывается, жители той кумранской общины были гораздо меньше сегодняшних ортодоксов озабочены "подлинностью" Торы. Или не очень грамотными они были, или просто не придавали этому значения, но допустили они в своих свитках отступления от ортодоксального канона. Но никакой смуты, однако, в рядах поборников этого канона кумранские "вольности" не произвели. Их просто спрятали - с глаз долой, из сердца вон. Так посетители Музея Книги, например, и не узнают об апокрифах Торы, а если кто и прослышит чего, то ему тут же и расскажут, что, мол, сектантами были эти кумранцы - Исаю они, в соответствии с установками мудрых равинов из иерусалимских иешив, грамотно переписали, а вот Тору - ересь. И нипочем им, ревностным, что самый древний из известных на сегодня, "кошерных" свитков датируется лишь 1088 годом. Даже Иосиф Флавий его почти на тысячу лет опередил в достоверности переписывания, чтобы не вспомнить ни римлян, ни греков... Все остальное, найденное сейчас или в будущем, будет надежно или припрятано, или об'явлено секстанством.
stsadm вообще может быть с успехом использована клавиатурой во всех случаях, где мышкой используется Central Administration. В частности, и для path exclusion : если вы не хотите, чтобы SPS ISAPI filter (stsfltr.dll) перехватывал обращения к какой-то директории, пишите
stsadm -o addpath -type exclusion -url http://<server> и т.д.
(Заметки к вопросу о том, как работает моя психика)
За давностью лет это было довольно сложно вспомнить, но вычитая детали, осталась в моем памяти такая история : какое-то полу-официальное израильское издательство [1] еще в начале перестройки, когда еврейские массы двинулись на юг, издало новый, на них расчитанный перевод Торы. Перевод был "синхронный", т.е. на одной странице давался текст на иврите, а на ее развороте - русский перевод. Что это был за перевод, нам позволяет судить количество букв "Ы" и "Э" в русском тексте. Мошэ, Йосэф, Пыдуэль были героями той книги. Йырушалаим, Бэйт-Эль - местами действия. Мое первое знакомство с Торой было связано именно с этим переводом. По нему я должен был если не понять, то усвоить один из первых методических постулатов ортодоксии - к написанному в этом тексте не прибавляется ни то, чтобы буква, но и призношение может тебя обличить в неверном толковании прочитанного. Если сказано, например, что сыны Исраэля поселились в Мицраиме - так тому и быть : никакого Израиля и Египта там даже не упоминается. Забудьте о том, что вы когда-то, может быть, читали на эту тему - перевод создан по благославлению таких лиц, рядом с именем которых одно перечисление их заслуг занимает не меньше двух строк. Со знаками препинания там была отдельная проблема. Я легко себе представляю, сколько бород и усов было пожёвано в поисках ответа на вопрос, какого же хрена в русском языке развелось столько запятых и даже не в том дело, что нам, мудрым, с ними делать, а в том, когда же эти несчастные евреи из СССР освоят великий иврит. Дальнейшая мысль мудрых непременно останавливалась на праведности совершаемого труда, и с тяжелым сердцем, но умиротворенные, ставили они запятые там под частые вздохи. Из остальных знаков препинания следует особенно выделить восклицательный знак. Почему-то мне думается, что он как-то просто не пришелся по вкусу переводчикам. Например, "И сказал Бог: "Да будет свет" ". Ставить восклицательный знак? Никаких указаний мудрые переводчики не получали на этот счет, а заглянуть в другие переводы означало, практически, лишиться своего доброго имени. Так и не поставили. [2]
Самой Торе синтаксис, кстати, вообще, не понадобился. Верхние огласовки - тема отдельного поста.
Вернемся, однако, к буквам "Ы" и "Э". Только представьте себе, что вы изо дня в день, из недели в неделю читаете русский текст, в котором превалируют эти быквы. К месту и не к месту. В именах собственных и в словах, для которых мудрые не нашли достойных аналогов. Возможны две реакции : один человек, почитав это, скажет "Я проникся. Действительно, если оригинальное звучание слова передается лучше через Э, то, знать, не доходило это просто до тех, кто корпел над переводами пятикнижия до сих пор. В нашем же поколении удалось, наконец, проникнуть в самую сущность толкования писания - все пишем Пэтах-Тыква, а слова Мелабес и знать не знаем". Так родилось в Израиле то передовое движение религиозной интеллигенции (простите за каламбур), которое не только за пару лет освоило единственно правильное звучание библейских терминов, но и само поднаторело в передаче узнанного другим членам паствы.
Я был, однако, среди других читателей. Я даже заметил во втором издании упомянутого перевода что-то вроде намека на извинения перед читателем. В предисловии ко второму изданию говорилось, что-таки да, русскому глазу не привычно видеть такое количество "Ы" на одной старнице. Верховные указания были получены - ошибки исправлены, переизданный текст приглажен. Со мной же это сыграло злую шутку - я стал бояться "Ы". Даже не отдавая себе в этом отчет, я как-бы интуитивно стал избегать "Ы" в своем письме. Например, "подглядывал" или "подглядовал"? Есть, конечно, правило в русском языке, соглaсно которому глаголы, суффиксы -ива и -ыва сохраняются во множественном числе, если так пишется глагол в форме первого лица единственного числа. Т.е. правильно "подглядывал", потому что "подглядываю", но даже если бы я помнил это правило головой, моя психика, как отражение мною пережитого, не дала бы мне написать правильно.
Вывод : интуицию можно переубедить; верой, увлечением, рвением, в конце концов. Интуиция не дается нам a-priori. Это вопрос воспитания и стиля жизни.
[1] Как оказалось после проверки, это было "מוסד הרב קוק"
[2] А прямой речи я не то что в этом месте, но и во всей книге не нашел.
"If God uses a laptop, I believe it's an X40." :) If Devil tries to establish connection with him, he instruments T30. :)
Additionally to the 'classical' guide from Scott Woodgate, there is yet another walkthrough posted recently by George Nelson.
Выполнить ISSOTicket.IssueTicket() может любой пользователь. Для этого не нужно быть authenticated. Полученный ticket может быть сохранён и передан другим приложениям. Собственно, для этого ticket и нужен. А вот RedeemTicket() может вызывать только authenticated user! Обратим бнимание, что SOAP Adapter, например, в соответствии с этим, будет использовать SSO только если выбрать Аuthentication Type - Basic или Digest; для anonymous users SSO Tickets теряют смысл в плане security - ticket представляет sensitive information, не хотим же мы показывать ее анонимам.
Аналогично работают HTTP и WSE Adapters. Касательно NTLM (для SOAP), Kerberos (для HTTP) и Integrated (для WSE) - пока мне сказать нечего. Почему их нельзя использовать для SSO authentication я не знаю.
Вот что по этому поводу имеет сказать Tomas Restrepo (from BTS newsgroup):
Hi Oleg,
That's a good question. My guess is that [...] the idea here is that you'd only use NTLM and Kerberos if you wanted to logon to the remote erver using the identity of the running BizTalk Application Host, however, that, by itself, doesn't seem very useful (particularly given that the requirement to use integrated security is imposed by the server side, not the biztalk side, usually).
It might be, however, a very simple technological problem... If the HTTP adapter uses the .NET libraries for this, I believe the support in them for integrated security doesn't allow you to use NTLM/Kerberos authentication with alternate credentials [1](and only those of the running thread, instead), but I don't know the implementation details here, so I might be
wrong.
[1] This would be a limitation of the .NET implementation, which probably uses SSPI underneath for the integrated authentication, and SSPI most certainly allows you to use alternate credentials.
Не знаю, сколько стоит SSO, а для домашних пользователей и голову ломать не надо. Загляните в ближайший RadioShack : Fingerprint Reader с клавиатурой или мышкой заменит вам SSO всего за каких-нибудь $60-$75. :)
Несколько предварительных слов. SSO может использоваться в 2-х целях : как непосредственно Single Sign-On и как Configuration Store. Если вы работаете без ActiveDirectory, то первая возможность вам недоступна, т.е. вы можете только определить affiliated applications для local accounts (указав для них в конфигурации соответственно groupApp="no"), mappings для local accounts не поддерживается. Почему? Потому что SSO разрабатывался, как расширение ActiveDirectory. Поклонники Novell и проч. придумают альтернативные решения, даже с WinLogo :) . Для BizTalk же ActiveDirectory не обязательна, он не использует group and individual mappings - с его точки зрения, SSO это исключительно Configuration Store для конфигурации адаптеров. Для каждого адаптера BiztTalk создает 4 affiliated applications - receive handler configuration, receive location configuration, send handler configuration and send port configuration.
Теперь, если все-таки вернуться к Single Sign-On, я бы хотел отметить его сценарий (для CCF hosted) :
1). Создаем affiliated application - ssomanage -createapps 'xml file name'
2). Создаем mapping - ssomanage -createmapping 'xml file name'. Не запутаться - в файле созданная affiliated application почему-то называется 'external application', но это именно affiliated!
MS рекомендует использовать только domain accounts и group mappings. Прислушаемся к совету к закончим на этом администрирование.
3). В коде (CCF hosted) осталось вызвать ISSOLookup1.GetCredentials()!
Вот и весь сценарий. Осталось только заметить, что для affiliated application всегда можно сделать multiple mappings - на столько accounts or groups, на сколько потребуется.
Не могу в заключении не отметить одну очень полезную статью об SSO (published in December, 2004).
...process of configuring the correlation Web Service. This is a common callback Web Service, which is exposed to the Called-out Wrapper Web Service. The Called-out Wrapper Web Service uses the Correlation Web Service to send a response back to the business process. The Partner Web Service (basically custom WSE filters registered in the OSS/BSS system Web server) calls this Web Service with the response of the Web call. It also uses the additional correlation information received during the Web method request. The Web Service intercepts the correlation information embedded in the Soap header and re-hydrates the appropriate orchestration with the response of the Web Service.
Наивность всегда меня подводила. С одной стороны, основа CCF - AgentDesktop и hosted applications. С другой стороны, напрасно было думать, что то, чем занимаются эти hosted applications, CCF не интересует. Интересует, и еще как! Вот, читаем:
[показать]О чем тут речь вообще? Оказывается, вместе с CCF решили поставить WfDACL - Workflow, Data Abstraction, and Caching Layer. Зачем? Чтобы hosted application с ним общалась. Т.е. если вам мало разобраться в том, что такое hosted application и как она попадает в AgentDesktop, если вы по пути успешно освоили AzMan, 3 WebServic'a, кот. там между делом вызываются, обращаясь к 2-м базам, если вы еще не забыли, как вас зовут в поисках несуществующей CCF консоли, то вот вам WfDACL!
Но и это еще не все! WfDACL, оказывается базируется на SKTI - Start Kit for Telecom Integration for BizTalk. Как мило! А где же его брать? На том же диске CCF. Но не спешим облегченно вздыхать. SKTI требует WSE 1.0. Не 2.0, кот. некоторые все-таки уже успели поставить, а 1.0!
Пара безобидных вопросов о caching timeouts и SKTI setup успешно завалится на попытке добавить в BizTalk свои адаптеры!
[показать]Если кто-то когда-то будет это читать, прошу прощения за нецензурные рисунки, но назовите мне хоть одного человека или даже целый коллетив, который в этом может разобраться за меньше чем 3 месяца. А мне мой дорогой босс целую неделю отстегнул, но, правда, заверил, что ждет *безукоризненных* результатов.
Нам осталось разобраться с application adapters и с разными типами hosted applications. Как я уже говорил, основной предмет здесь - IHostedApplication interface, its implementations and uncessors.
Для начала разберемся, как установить разрабатывемое приложение в CCF. Нам понадобится initialization string, кот., в свою очередь, зависит от типа hosted application (defined in Microsoft.NSP.ContactCenter namespace in HostedApplication.dll )
public enum ApplicationType{ // Fields DisabledApplication = -1, ExternalApplication = 2, WebApplication = 1, WinFormApplication = 0}Here's an example of initialization string for Type 0 - WinForm
<
initstring><assemblyInfo>
<URL>C:okeyCCFHostedbinDebugCCFHosted.dll</URL>
<type>CCFHosted.ccfControl</type>
</assemblyInfo>
<displayGroup>MainPanel</displayGroup>
<optimumSize x="470" y="380"/>
<minimumSize x="340" y="180"/>
</
initstring>Workflow's definitions are presented in three tables of ContactCenterAIF DB : 1) все определённые workflows даются в таблице WorkflowsMaster, все определённые шаги (steps) даются в таблице WorkflowStepsMaster, связь между ними, т.е. из каких шагов состоит какой workflow, дается в таблице WorkflowStepMap. Наконец, каждый шаг связан с одной и только одной application через ту же таблицу WorkflowStepsMaster (ксати, что делает непонятным, зачем вообще понадобились steps) .
For example, (assuming clear installation) the following query outputs all hosted applications that intended to run from workflow 1:
select wsmas.StepID, wsmas.Name as 'Step Name',sequence, apps.ApplicationId, apps.Name
from WorkflowStepMap as wsm
left join WorkflowStepsMaster as wsmas on wsm.stepid = wsmas.StepID
left join Application as apps on apps.ApplicationId = wsmas.ApplicationId
where workflowid = 1
order by sequence asc
Output:
StepID StepName sequence ApplicationId Name
1 Account 0 6 Accounts
2 Cell Coverage 1 8 Cell Coverage
3 External App 2 7 StandaloneTestApp
(3 row(s) affected)
Таким образом мы нашли, что workflow 1 состоит из 3-х шагов, которые будут исполняться в указанной (according to sequence column) последовательности и на каждом шаге будет исполняться соответствующая application. Каждый шаг представлен в Agent Desktop своим именем - StepName column.
Какие workflows доступны для какого агента, решаеется с помошью таблицы AgentWorkflowACL.
Дальнейший план такой :
1). Каждая hosted application имеет свой initialization string в своей строчке таблицы Application. В зависимости от типа приложения он несколько меняет форму, но главное в том, что для каждой application, соотвеветствующей исполняемому из workflow шагу, AgentDesktop из нее может узнать во-первых, где найти hosed application и где выводить ее UI. Понятно, что от самой hosted application требуется поддержка некоторого протокола, согласно которому AgentDesktop сможет с ней разговаривать. Таким протоколом является IHostedApplication interface и его реализация в классe HostedControl (в HostedApplication.dll assembly). Т.о. на этом шаге становится понятным как разрабатывать hosted appilcations - имплементируя IHostedApplication - и как установить разработанный assembly into AgentDesktop.
2). AzMan. Попытка выполнить workflow без предварительной кохфигурации AzMan, дает примерно такой результат :
Именно AzMan занимается управлением указанного здесь 'access to the hosted applications'. AzMan (в файле AzManCCF.xml) представляет собой Authorization Store. Введение в тему можно найти здесь. Непосредствено к нему обращается лишь ContactCenterAIF Web Service, в web.config которого и нужно внести путь к самому файлу
<
add key="AzManStore" value="msxml://C:InetpubwwwrootContactCenterAIFAzManCCF.xml
" />