Gsraju91



HYPERLINK "" Using Azure ServiceBus for Debugging SharePoint 2013 Apps with Remote Event Receiver-Part 1von Toni Pohl, 20. April 2015 08:00The new app model has a lot of benefits, especially for Web Developers who are writing solutions for Microsoft SharePoint Server 2013 or SharePoint Online. A very common request of Line-of-Business (LOB) apps is that actions in SharePoint lists shall trigger special operations, for example to start a workflow or to exchange data with other, external systems. This can be accomplished with “Remote Event Receivers” in SharePoint. With SharePoint 2013? the new concept uses Azure ServiceBus to transport events and data between the SharePoint Server system and a remote App (which while developing usually is running on “localhost”).For developers it’s very important to debug code during the development process. Since this is not possible by default with Remote Event Receivers I want to pint out how to accomplish this task and how to setup the (ServiceBus) environment for debugging your own SP apps.Why is this necessary? Well, Microsoft changed the user experience in the Azure portal for Service Bus namespace creation, see the details in this blogpost here. The short story is that new created Service Bus namespaces in the Azure portal only have SAS authentication enabled by default (which is used by the the majority of use cases). The accompanying ACS namespace is not automatically created. What’s the default in the Azure PortalThis is how it looks like when you would create a new ServiceBus namespace in the Azure Portal.Again, that’s not what we need for debugging our App, just to point out the difference…In the ServiceBus area click “Add” in the menu bar, enter a namespace name, the region and the type and tier:After the ServiceBus was created (this takes just some seconds), look into the connection properties.Under “ACS” the dialog says: “Looking for ACS connection information? Please see here for more information regarding using ACS with Service Bus.”ACS features provide claims and federation capabilities and these are necessary for debugging. The essence of the story is this definition:“In order to create a new namespace (with ACS) in PowerShell use the cmdlet New-AzureSBNamespace.”We need to create a new ServiceBus namespace with Azure Powershell.How to create a new ServiceBus namespace with ACS enabledYou need to have an Azure Subscription and to have the Azure PowerShell installed. This can be done with the Web Platform Installer (WPI), you get from the Azure PowerShell and connect to your Azure subscriptions. Add-AzureAccountYou need your Microsoft Account or your Organizational Account to login. This takes a while. If the login was successful the output shows all your Azure subsciptions and your Azure tenants – but only the GUIDs. We need the corresponding names, so we want to list the subsciptions:Get-AzureSubscriptionCopy the name of the subsciption where the Azure ServiceBus shall be created and select the subscription with it’s name:Select-AzureSubscription "MySubscriptionname"The last command creates a new ServiceBus namespace: Use your desired name here.New-AzureSBNamespace 'MyEventReceiver' -CreateACSNamespace $True -NamespaceType Messaging –location 'North Europe'The default location would be “Central US”, so it’s a good idea to add the –location parameter here. The ouput delivers the necessary data for your SP App and looks similar like this:Name : MyEventRecieverRegion : North EuropeDefaultKey : Pq6YAYcb….Status : ActiveCreatedAt : 17.04.2015 12:02:00AcsManagementEndpoint : : : Endpoint=sb://sptxtdemoeventrecieverservicebus.servicebus.;SharedSecretIssuer=owner;SharedSecretValue=Pq6YAYcb….NamespaceType : MessagingWe need the ACS Endpoint for our SP EventReceiver App. Now – of course – you also get this connection string in the Azure Portal. If you check this in the Azure Portal it looks similar like here:The difference to a created ServiceBus namespace in the Azure Portal is that this PowerShell created Servicebux namespace is ACS enabled – and has a connectionstring.Use the ServiceBus with ACS in your AppSo we copy & paste this ServiceBus-Endpoint into the “SharePoint” properties of our app.That’s it. The ACS ServiceBus can now be used by the App.HintWhen you have created an Azure ServiceBus with ACS enabled, you can use this ServiceBus for multiple Apps, it’s not necessary to create a new one for each app. The Endpoint is reachable from anywhere with it’s service address and can hold many EventReceivers. Also it’s easily possible to change the Endpoint in the app properties anytime, you just need the correct connection string (with the address and the secret).For developing a Remote EventReceiver App do not forget to set the permission of the app to “Web” and “Manage”. In Part 2 we continue with developing the app.Autor: Toni PohlReferences:- to Azure Service Bus Portal: Default Authentication Mechanism for Service Bus Namespaces now SAS?What are we changingA change has been made to the user experience in the Azure portal for Service Bus namespace creation.? When creating a Service Bus namespace in the Azure portal only SAS authentication will be enabled by default.? The accompanying ACS namespace will no longer be created and paired to the Service Bus namespace.??Why did we change itThe vast majority of our customers only use ACS for the access key functionality, not for identity federation.? SAS provides better capabilities and higher scale for these use cases so we have decided to make it our default in the portal experience.? This simplifies our customer experience for the majority of use cases.?How does this impact customers and how can you use ACSCurrent namespaces will not be affected in any way.? Customers who were dependent on ACS features such as claims and federation will also not be affected if they use automation to create their namespaces; namely PowerShell, the Azure CLI?and the REST API.??In order to create a new namespace in PowerShell use the cmdlet?New-AzureSBNamespace?New-AzureSBNamespace -Name 'MyNamespace' -Location 'Central US'?This will create the Service Bus namespace and a paired ACS namespace.? The ACS connection string will appear in the Azure portal.??In the future there will be a new optional parameter to this cmdlet which will allow you to control ACS namespace creation.? At first this cmdlet will default to creating ACS namespaces, but further in the future this default will be reversed and ACS namespaces will not be created by default.??In?Azure CLI, you will run:sb namespace create ‘MyNamespace’ ‘Central US’?For the REST API:?By default the ACS companion namespace will be created, unless you specified a x-ms-version header bigger than '2014-05'?As we continue to expand and improve our Azure messaging platform the Service Bus team will continually examine customer usage, dependencies, and impact.? Creating namespaces without a paired ACS namespace is faster and creates one less dependency for our customers.? This change streamlines the user experience for the majority of our customers today.??Are we moving away from ACS?No!?ACS is still fully supported in Service Bus and will be for the foreseeable future.? As Azure Active Directory (AAD) expands to support more service federation identity scenarios we will increasingly align with the AAD service offering.? ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download