Некоторые Receive Adapters (HTTP и SOAP, например) могут вызвать ISSOTicket.IssueTicket() и, в случае успеха, записать результат в (promoted) context property "SSOTicket". Самое важное в этом то, что делается это для user'a, успешно прошедшего authentication в Receive Port. Сам этот user ( в форме domainName\userName ) записывается в property "WindowsUser" .
Как именно осуществить authentication, решает сам адаптер, а в случае SOAP или HTTP, оба они используют для этих целей свой Isolated Host, т.е. host, кот. бежит в IIS, т.е. его Windows Authentication. (IIS7 по умолчанию устанавливается без Windows Authentication, соответствующий модуль должен быть добавлен дополнительно прежде чем администратор или радивый программист получат возможность разумно убрать Anonymous Authentication с IIS Application).
Если конфигурация адаптера включает вызов IssueITicket, но без аутентикации, то "SSOTciket" context property сгенерирован не будет, a property "WindowsUser" будет содержать пустое значение (хотя сам этот property будет записан в контекст сообщения).
Все это делается для того, чтобы соответствующий Send Adapter мог вызвать RedeemTicket(), и тем самым получить искомые внешние mappings для исходного user'a. Понятно, поэтому, что необходимым условием для этого сценария будет тот факт, что оба API - IssueTicket и RedeemTicket - вызываются для одного и того же user'a. Собствеено, этому и служит упомянутый property "WindowsUser". Без него вызов обоих ISSOTicket-методов лишается смысла, и поэтому вообще не стоит пробовать применять SSO без authentication.
SSO устанавливается по умолчанию без поддержки tickets. ssomanage.exe или MMC 3.0 решают и этот вопрос.
При этом я не имею в виду authentication, запрашиваемую на уровне Receive Port, а механизм, с помощью которого сам адаптер может провести authentication, как "Windows Authentication" в случае SOAP/HTTP и IIS.
Сообщение, кот. было опубликовано в MessageBox с установленными "SSOTicket" и "WindowsUser" может попасть оттуда или в оркестрацию, или в Send Port. В случае оркестрации, эти context properties должны быть скопированы из поступившего сообщения в то, кот. будет послано в Orchestartion Send Port, например, так (Message Assignment Shape):
msgOut(BTS.SSOTicket) = msgIn(BTS.SSOTicket);
msgOut(Microsoft.BizTalk.XLANGs.BTXEngine.OriginatorSID) = msgIn(Microsoft.BizTalk.XLANGs.BTXEngine.OriginatorSID);
Второй оператор в этой записи гарантирует, что обсуждаемый RedeemTicket метод будет вызван для того же user'a, для которого раньше вызывался IssueTicket. В случае, если сообщение попадает в SendPort, этого гарантировать нельзя, что и приводит к подобным ошибкам.
Все сказанное относится только к тем адаптерам и оркестрациям, кот. работают под Trusted Host. И наконец, напоследок, еше одно замечание о Send Adapters : помните о первом параметре в RedeemTicket! Это ваш affiliate application. Sic! В конце концов, мы ведь хотели всего-навсего перевести credentials вызывающего user'a в external credentials. Именно affiliate application и хранит этот mapping. Properies, доступные аднинистартору Send Adapter'a при конфигурации Send Port'a должны давать возможность выбрать из списка установленных affiliate applications, тем более что BAF поможет в этом - см. baf:SSOList.

Те receive orchestration-порты, кот. нужно "опубликовать", должны быть public. После публикации для этих портов будут созданы Web serices по одному для каждого "публикуемого" порта и (опционально) BTS receive-locations (SOAP transport) для каждого созданного Web service.
Самому такому Web service не требуется receive location, т.к. он пользуется специальным BTS Web адаптером, однако, поскольку MessageBox по умолчанию не принимает не аутенцифицированных сообщений, обычно опубликованный WS запускают в специальном IIS pool, настроенном бежать под тем аккаунтом, кот. имеет разрешенный доступ к MessageBox.
При обрщении к опубликованному orchestration через созданный после publishing recice location, orchestration получит сообщение через SOAP-adapter.
В обоих случаях нельзя забывать, что orchestration может получить сообщение только одним путем - через правильно определенный subscription, а в данном случае это значит, что для orchestration нужно сделать rebind с новым receive location!

1). Любое сообщение, попадающее в MessageBox, становится доступным для live-tracking на то время, пока сообщение находится в MessageBox : HAT меню "Operations" (Service Instances, Messages) выполняет "живые" запросы () на BizTalkMsgBoxDb, показывая, таким образом, только те сообщения, кот. еще находятся в MessageBox.
TDDS (Tracking Data Decode Service) service (aka BAM Event Bus) отвечает за перенос обработанных сообщений из MessageBox в базу BizTalkDTADb, a HAT меню Reporting/Fing Message исполняет запросы к BizTalkDTADb.
2). Расширить меню "Queries" в HAT очень просто : для этого достаточно поместить файл с расширением .trq в директорию C:\Program Files\Microsoft BizTalk Server 2006\Tracking\Queries (or the equivalent on your server.)

1. DataCache - "Database lookup" and "Value extractor" functoids см. здесь.
2. Вообще о BTS cache - см. здесь

Добавление фильтра к send port не влияет на messages, кот. попадают в такой send port через orchestrations : фильтр для send port и для send port group создает дополнительный subscription.
Этот дополнительный subscription чаще всего используют в pass-through scenario. Вот как, например, может выглядеть фильтр для самого обычного копирования файлов : BTS.ReceivePortName == recPort1.
P.S. С точки зрения BTS services, subscription для orchestration обслуживается XLANG, a subscription фильтрa в send port - EPM.

Наиболее простой способ создать объект, который становится известным только на эпапе выполнения, это Type.GetType(). К сожалению, этот путь и самый неэффективный : Type.GetType() не только пытается загрузить указанный assembly, но запрашивает полный достун к его metadata для того, чтобы возвращаемый результат был, как и специфицировано, типа System.Type.
С другой стороны, Activator.CreateInstance() возвращает object handler без попытки доступа к metadata. Этот путь в несколько раз быстрее, но и, как следовало ожидать, нельзя пожертвовать metadata без каких-либо потерь : возврашаемый Activator.CreateInstance() ObjectHandle можно использовать разве что для немедленной передачи в другой domain, и, видимо, в этом и состоит предназначение этото метода, потому что никакой функциональной нагрузки этот ObjectHandle без соответствующей metadata не несет. Или сразу же после передачи в другой domain, или в непосредственно в вызывающем, первое, что делают с таким ObjectHandle - вызывают его Unwrap(), кот. собственно и загружает недостающую metadata для объекта.
Отметим, что без Unwrap() никакие операции с возвращенным объектом не имеют смысла : так, например, даже если он является реализацией интерфейса, то поскольку это становится известным CLR только с помощью metadata, cast на родительский интерфейс без Unwrap() не будет успешным.

WSE представляет два новых класса, имплементирующих IHttpHandler :
SoapHttpRouter и SoapReceiver. Как и любые другие реализации IHttpHandler, эти добавляются в ASP.NET-приложение секцией в в <system.web>, как например:
<system.web>
<httpHandlers>
<add type="namespace.myHttpHandler, assemblyName" path="*.ashx" verb="*" />
</httpHandlers>
...
</system.web>

при этом, если приложение настроено для WSE, то WseCongigEditor узнает такую конфигурацию :

[528x594]

Это, конечно, означает, что вне зависимости от чего наследует ваш handler - от SoapReciver или от SoapHttpRouter - он будет вызван при любом запросе сервера через ashx, т.е. во всех трёх случаях ваш handler может переадресовывать сообщения, только вот из разных методов, зависящих от реализации.

Имплементация		Метод
1.	IHttpHandler	public void ProcessRequest(HttpContext ctx)
2.	SoapHttpRouter	protected override Uri ProcessRequestMessage(SoapEnvelope message)
3.	SoapReceiver	protected override void Receive (Microsoft.Web.Services2.SoapEnvelope envelope)

Следующий вопрос, поэтому, как переадресовывать. В первом случае, имея дело только с HttpContext, это выглядит довольно проблематично, и уже поэтому, реализация раутера прямым наследованием от IHttpHandler не будет рассматриваться. Переадресация из SoapHttpRouter - это именно то, что делает встроенный в WSE Messaging.SoapHttpRouter, так что вряд ли его стоит повторять : читаем ReferralCache.config и возвращаем из ProcessRequestMessage() новый Uri - вот и весь раутинг для http, но так и наследуемый класс и называется SoapHttpRouter!
Итак, исталось наиболее интересное : SoapReceiver.Receive().

If you simply open the web config file and add the following, you will be able to access the test form outside of the localhost:

<configuration>

<webservices>
<protocols>
<add name="HttpGet"/>
<add name="HttpPost"/>
</protocols>
</webservices>

</configuration>

Before you even think about Office 2003 (Office 11) automation, take into the consideration these articles - one , two. One of the most annoying aspects of such task - multilanguage deployment. In fact, it's simply worth to explicitly set en-us lanluage culture to current thread to prevent lost of the day.

Все (или почти все) по сабж можно найти здесь

ResourceManager has a BaseName property that actually set during its c'tor call. Later, resources are located and loaded based on this property. It's not obvoius, hovewer, that if you add a resX file to stuio project, say, called 'Foo', the BaseName for the appropriate ResourceManager shoul be .Foo

COM server, метод(ы) кот. возвращают Recordset, интегрируется с ADO.NET с помощью OleDbDataAdapter.Fill(). Этот метод заполняет DataSet записями из передавемого ему Recordset. Поскольку ADO.NET не "знает" объектов ADO, передаваемый Recordset он видит как object:
public int Fill(DataSet dataSet, object ADODBRecordSet, string srcTable);
Microsoft рекомендует использовать для интергации с ADO не reference на ActiveX Data Objects (msado15.dll), а заранее приготовленный Primary Interop Assembly - Program Files\Microsoft.NET\Primary Interop Assemblies" directory in the file adodb.dll.

Q. Что возвращает вызов endpoint?
A. Если query в исполняемой процедуре заканчивается на FOR XML AUTO, клиенту восвращается System.Xml.Element. Если query не содержит FOR XML AUTO, возвращается System.Data.DataSet. В обоих случаях результат - один из элементов возврщаемого массива objects. Обычно, его первый элемент - есть результат исполнения stored procedure (return code), второй элемент - XmlElement или DataSet.

RTM версия SQLServer 2005 не даст создать endpoint на занятом порте, в частности, при запушенном IIS, такой statement не работает ( с сообщением

Msg 7890, Level 16, State 1, Line 2
An error occurred while attempting to register the endpoint 'XXX'. One or more of the ports specified in the CREATE ENDPOINT statement may be bound to another process. Attempt the statement again with a different port or use netstat to find the application currently using the port and resolve the conflict. )

CREATE ENDPOINT XXX
STATE = STARTED
AS HTTP(
PATH = '/sql',
PORTS = ( CLEAR ),
AUTHENTICATION = (INTEGRATED ),
SITE = '*'
)
FOR SOAP (
WEBMETHOD 'webMethodName'
(name='dbName.dbo.sp_Name'),
WSDL = DEFAULT,
SCHEMA = STANDARD,
DATABASE = 'DBName',
NAMESPACE = 'http://tempUri.org/'

);

Конфликт между port listeners решается оператором CLEAR_PORT

CREATE ENDPOINT sql_endpoint2
STATE = STARTED
AS HTTP(
PATH = '/sql',
PORTS = ( CLEAR ),
CLEAR_PORT = 8090,
AUTHENTICATION = (INTEGRATED ),
SITE = '*'
)
...

Для XP, AzMan входит в состав Windows 2003 Service Pack Administration Tool Pack. Этот пакет вообще для must for any developper XP Box.

То, что MSStudio генерирует из XSD зависит только от используемого CustomTool. В стандартный комплект Studio входит 2 подходящих tools : MSDataSetGenerator создаст из XSD обычный Typed DataSet, а - XML-классы для последующей сериализаци. Если по каким-то причинам в проект нельзя напрямую добавить Typed DataSet, добавьте сначала просто XML, а потом вручную измените в его properties Custom Tool.

Задача наша состоит в том, чтобы SAP вызывал BizTalk Orchestration.
Для этого мы создадим ReceivePort (и, понятное дело, Receive Location ) с mySAP адаптером. Мы присвоим ему такой ProgramID, который будет известен в SAP, и дальше положимся на сам RFC, который должен уметь найти наш Orchestration по ему известмому ProgramID.
Часть этого процесса, касающуюся конфигурации BizTalk, мы отложим как тривиальную, а здесь займемся конфигурацией SAP. Итак,
1. перво-наперво, нам надо определить RFC Destination. Это такая штука, к которой будет обращаться RFC, когда ему надо покинуть границы SAP. Т.е. с помощью RFC можно не только обращаться к BAPI или RFC-enabled functions, но и наоборот - вызывать внешние программы. Как RFC умеет это делать, т.е. как и где он создает listener - мне не известно, но очень интересно. Все дальнейшее из этого пункта происходит в sm59. RFC Destination можно определить по-разному, включая указание на имя компа и путь на нем к вызываемому модулю (Start on Explicit Host). Но нас сейчас интересует ProgramID - Registered Server Program.
[540x483]
Теперь нам понадобится RFC Port, а строятся эти порты через we21. Поэтому, 2. в RFC Destination нового порта, укажем имя, которое дали на шаге 1

[636x223]
Следующий шаг - это Partner Profile. Что это такое? Приведем цитату: "When data is exchanged between partners it is important taht sender snd recieiver agree about the exact syntax and semantic of that data. This agreement is called partner profile. The information defined with the partner profile are:
- IDoc type and message type as key identifier of the partner profile,
- Names of sender and receiver to exchange the IDoc information,
- Logical Port name via which the sender and receiver will communicate"
Итак, Partner Profile создается для уже существующего partner. А где же определяется partner? Welcome to sale transaction - одну из самых идиотских трансакций во всем SAP (с точки зрения UI). Мы создадим Logical System (LS), который и будет нашим partner:

[455x265]
Теперь можно запускать we20 - Partner Profiles.

[687x248]
"Partner no" и "Partn. Type" - так дружественные к пользователям разработчики SAP решили назвать Partner Name (который мы определили при добавлении Logical System) и соответствующий ему тип. Т.о. в верхней части вы можете выбрать только сушествующего Partner.
В нижней части можно определить Profile для inbound и/или для outbound. Особенно важным здесь является Message Type, Receive Port, Output Mode и Basic Type.

В этом примере показан looping functoid, соединяющий два родительских элемента. Нижний "Not Equal" functoid соединяет один из дочерних элементов из source с тем же родителем, что и looping functoid. В нем проверяется условие на неравенство значения связанного дочернего элемента с какой-то предопределенной константой.
Для каждого родителя looping будет выполняться только если "Not Equal" functoid вернет вернет true для его дочернего. Т.е. если в source было, скажем, два родителя, из которых только один содержал дочерний элемент с необходимым значением, в destination будет создан только один соответствующий родительский элемент.
[699x239]
[700x319]

Разработка в ABAP
se37 - RFC Function builder
se16 - Data Browser
se38 - ABAP environment
se80 - ABAP Workbench
sm35 - Batch Input i.e. Recording
shdb - Batch Inpur Recorder
Разработка в ALE
sale - Display IMG
sm59 - RFC destinations
we20 - Parther Profiles

Всему миру известно, что asp:TextBox имеет property под названием Text. Вот только MSStudio designer обращается с ним вольно. Установка этого property из Designer приводит к записи текста между тэгами
<asp:TextBox>your text here...'TextBox' cannot have
children of type 'DataBoundLiteralControl'"
Только вторая форма (с Text property) является правильной с точки зрения ASP.NET.