In the general case, the UserTokenIdentifier can come from any source. The UserTokenIdentifier is provided by received messages. Value of the UserTokenIdenfier acquired ahead of time by exporting the static ports. The demo scenario is based on a simple orchestration: The same UserTokenIdentifier can be used by multiple ports.UserTokenIdentifiers remain valid regardless of whether a dynamic or static send port exists or not, and after port deletions.They are not needed once the UserTokenIdentifiers are known. Static send ports can be deleted afterwards.For a given sign-in, the value of the UserTokenIdentifier may be the same for all Office 365 transport types, but static send ports need to be created for each transport type nonetheless. A static send port needs to be created for each Office 365 transport type in order to get an identifier for each. Note that the UserTokenIdentifier is tied to a signed-in account and a transport type.
Once a user is signed-in, the UserTokenIdentifier is retrieved from the bindings, as shown below, in the case of an exported Mail send port (placeholder vt="8" />This identifier is created when the user signs in to Office 365, which is done when creating a static send port, in the transport properties of the Office 365 Outlook adapters as documented in Office 365 Outlook adapters in BizTalk. Messages sent from a dynamic send port with transport type set to one of the Office 365 Outlook adapters need to provide the UserTokenIdentifier context property.
In this post, we go over this improvement into more details. BizTalk 2020 CU1 introduced support for dynamic send ports in the Office 365 Outlook adapters.
0 kommentar(er)
