Adaptive Cards and Viva Cards. 28 January 2022 Michael-Van-Wesemael Office 365 The last version of SPFX, the SharePoint Framework, comes with a new extension: the Adaptive Card Ex [More]
PowerApps Portals are available 17 October 2019 Michael-Van-Wesemael Office 365, PowerApps A new functionality we have with powerapps now are "Power Portals". This allows you to create a port [More]
Creating connectors for your Logic Apps/Flow (Part 1–regular Connectors) 24 February 2017 Michael-Van-Wesemael Office 365, SharePoint, Azure, Logic Apps, API Apps, Flow Azure logic apps have been around for a while now, most of the time as a preview. These apps allow you to create workflow-like apps, by connecting so called Connectors together. These connectors are actually just REST-services, with some extra's, like the exposure of metadata by using Swagger. These Logic apps have also been made available through Office 365, where it is known as "Flow". Office 365 Flow, or Azure Logic apps have access to a library of Connectors, like connectors for Twitter, Facebook, Outlook Mail and Calendar, SharePoint and many more. At the moment I write this there are 84 connectors available. But of course we can add our own connectors. You can find information on how to do this on the internet, however I found myself struggling with Azure because of incomplete information, even in the official Azure documentation. So, I decided to complete the information. From a developer perspective, there are two types of connectors we can create: "regular" connectors and triggers. A regular connector can just be used within your flow, but not at the start. It can take input from connectors preceding it in the flow, and it can return output to the flow. A trigger can be used in the beginning of a flow and is responsible for starting the flow. Creating a regular Connector Connectors are REST services. In my example I will do this with Web API, but it can be done in any other web-technology. While creating a web application just choose Azure API App. I will create a simple example in which I just reverse an incoming string. The code is pretty simple : [SwaggerResponse(HttpStatusCode.OK,Type =typeof(StringManipulator))] [SwaggerOperation("GetReversedString")] public IHttpActionResult GetReversedString(string id) { var temp = ""; foreach (var item in id) { temp = item + temp; } return Ok(new StringManipulator { Original = id, Reversed = temp }); } .csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, "Courier New", courier, monospace; background-color: #ffffff; /*white-space: pre;*/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; } However, the second argument in your SwaggerResponse-attribute, the Type, is super important. Without this argument Logic apps, using your API, will just assume your function returns nothing ! It took me some time to find this out, since it used to work fine without Type in an earlier version of Logic apps, and it's nor really clear from the documentation. So, beware. After deploying your API app to Azure, there are two more things to do. Locate your API app in the Azure portal, and go to the API settings. The API definition should point to your swagger metadata. Make sure you refer to it using https !!!.Also make sure that CORS is enabled for your logic app, or just use * here. After that you need to restart your app. Otherwise your logic app will not pick it up. There you go. If you want to use it in a Logic app just add the Action App Services, select you API app, and select the action you want to use. And there you go, the following connectors have access to the output of your API app. Pretty straightforward, if you don't forget the Type in your SwaggerResponse-attribute. Using API apps as triggers is somewhat more work. We'll discuss that in part 2.
New version of U2U CAML Query Builder 11 March 2014 Michael-Van-Wesemael CAML, Office 365, SharePoint The original U2U CAML Query Builder has been around for many years, and is being used by many SharePoint professionals. So we thought it was time for giving it some small changes, and bringing it to version 4.2.0.0. The query builder now uses CSOM for connecting to SharePoint, and it also allows connecting to Office365 now.Next to these changes we also have two smaller changes: The different types of queries that can be created has been reduced to two for simplification. We added some tabs for directly copying Server- and Client-side code: There you go, I hope you’ll enjoy it as much as previous versions.We’ll try to get you some more CAML query goodies later ! For now: you can find the Query Builder at http://u2u.be/software. (function(d, s, id) { var js, fjs = d.getElementsByTagName(s)[0]; if (d.getElementById(id)) return; js = d.createElement(s); js.id = id; js.src = "//connect.facebook.net/nl_NL/all.js#xfbml=1"; fjs.parentNode.insertBefore(js, fjs); }(document, 'script', 'facebook-jssdk')); Tweet !function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0],p=/^http:/.test(d.location)?'http':'https';if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src=p+'://platform.twitter.com/widgets.js';fjs.parentNode.insertBefore(js,fjs);}}(document, 'script', 'twitter-wjs');