1)      Run Get-SPTrustedSecurityTokenIssuer

2)      Make sure you are looking at the correct name (red arrow)

3)      The IssuerID is the first part of the name (before the @ symbol)

The Pi has a few serial ports, in this case I am hooked to the pins 8 and 10. These are the TXD0 and RXD0 (transmit and receive) pins. In the SerialDevice.GetDeviceSelector you use the UART0.

Here are the pins and connections (pretty simple send to the receive and receive to the send AND of course power):

Attached is the code, enjoy! 

[View:https://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-71-48/8547.WP_5F00_20160106_5F00_004.mp4] 

MainPage.xaml.cs

So how do we get data to the Raspberry PI (RPI)? Enter WebAPI! One of my favorite technologies!

At the end of the day, you probably need more data/server site functionality anyway.

Currently I am using a timer to call my Azure hosted WebAPI to send data down to my RPI.

            m_dtTimer                                                       = new DispatcherTimer();
            m_dtTimer.Interval                                          = TimeSpan.FromMilliseconds(5000);
            m_dtTimer.Tick                                               += TimerEvent;
            m_dtTimer.Start(); 

Then in the Timer call use the HttpClient

private void TimerEvent(object o, object e)
{

     MakeWebRequest();

}

public async void MakeWebRequest()
{
            HttpClient http                                                 = new System.Net.Http.HttpClient();
            HttpResponseMessage hrResponse              = await http.GetAsync("https://yoursite.azurewebsites.net/api/yourapi");
            string strProgram                                            = await hrResponse.Content.ReadAsStringAsync();

            //Do coo stuff

On the WebAPI side, for this example I am just returning some data from the Azure Message Bus (Queue) on the Get() method. Here is that code:

Normally I would use a small laptop consuming service bus messages and an Arduino to control relays and all the other “robot” stuff. But today I installed Windows 10 IoT on Raspberry PI; wow life changing! With 17 GPIO and full .Net code support, it’s all you need! So this short post is really about after you install IoT on your Raspberry and need to connect to it via. Web browser (after Windows 10 IoT is installed, it gives you a small webpage to access).

ID: Administrator
PW: p@ssw0rd

Step 1: Copy IP

Step 2: Open in browser and enter above credentials

 
Bam! Awesomeness! 

Step 1: Go to the IIS where your SharePoint is running, open IIS and open Server Certificates.

Step 2: On the upper right, select “Create Self-Signed Certificate”

Step 3: Enter “PHACert” as the friendly name, “Personal” is fine for the cert store

Step 4: Select the newly created cert and select “export”. Set password to “password” and put it to a directory you will remember.

Step 5: Double click on the cert, then click “details”. Then click “Copy to File”. Leave everything default, save the file as “PHACert.cer”

Step 6: Open SharePoint 2013 Management Shell as an Administrator. Save then run the attached PowerShell script like this:

 PS C:\site> ./pha.ps1

For Cert Name: enter PHACert

For Cert Path: enter the full path to PHACert.cer that you saved above.

Save the created Issuer ID at the bottom:

Step 7: Create your app!

• On screen 2 enter your SharePoint server and provider hosted

• On screen 3 enter SharePoint  2013

• On screen 4 select MVC (or aspx)

OK, on screen 5:

• Select “Use Certificate”

• Enter the full path to the PHACert.pfx you exported on step 4.

• Enter “password” for the password.

• Enter the Issuer ID found at the bottom of that PowerShell script.

Done! Press finish and F5. You just made a SharePoint Add-In is 7 easy steps!

PHA.ps1

Step 1: Have a WebAPI. If you do not I have one you can use the zipped up at the bottom of this article.

Step 2: Create your workflow

Step 3: Create “Header” dictionary with the below fields (make sure Authorization is blank!)

 Step 4: Create “Data” Dictionary

Step 4: Create HTTP Web Service Call and use the following settings:

Address: https://YOURSERVER/api/Demo

RequestHeaders: Header

RequestContent: Data

RequestType: HTTP POST

Step 5: Done! Data will post to your WebAPI and you can save it to SQL or send it to your grandmother via email!

OK, that was easy, but let’s dig in a little. Here are some thoughts/notes on this whole process:

• Most issues with the POST are authorization related. Setting the header “Authorization” to empty string forces the system to perform authentication or it will try anonymous (which will fail miserably).

• Workflow will handle a moderately complex object, it does not like arrays. This is about as complex as it should get: {"Action":"Some Action", "ID":"10", "User":"Dan Biscup"}

• Under the covers it is encoding as JSON, claims user names have \\ in there and it will break.

• WebAPI likes 1 parameter in the POST, so use a complex object, I usually keep these in a separate dll/project that we can use in other projects.

• I like to keep a "GetAll" method that just returns the controller name so I can make sure it is running in IIS like /api/demo.

DemoWebAPI.zip

When writing enterprise applications with multiple people on a project team, it is very important to be able to recreate data structures and reference data to different environments accurately, quickly and efficiently. In the SQL application world, people have been doing this forever. They script DB builds and auto load reference data. They sometimes take it up a notch and use tools like Entity Framework and Typed Datasets to help generate compile time errors to prevent run time errors when the data structures change. This is currently referred to as “Infrastructure as Code”.

In the CAM/Add-in world, SharePoint lists can be a challenge to manage. There are ways, like “export to template” that can do this but it is hard to keep the data in-sync and up-to-date with new reference data etc. There are a few admin steps to activate these features and enable them. Some people make a list of the lists they need to move and manually add them to the different site collections. Typos anyone? This can be really hard to trouble-shoot in a new system and in the end, the developer will have to use the “works on my box” line; not good.

Enter the DataApp! A simple solution to get your team to an enterprise development standard. This DataApp should be able to create and load all data structures and any reference data your application needs. It does not have to be glamorous or efficient. The DataApp just has to be able to create the data structures and data. When a change is needed, you make it in the DataApp and have the DataApp push it to your SharePoint site. This allows your projects to always have a way to reproduce data and structures. To take it one step further, this DataApp can also generate constants for your application to use. If your application uses the constants, when a column is renamed or deleted, the complier will give you an error; runtime error avoided! How cool is that!

Let’s walk through the DataApp, it consists of a JSON file with all the configurations and a CSOM app.

JSON Configuration File

In this file, you define your tables and relationships. You can also add reference data rows. In the head of the file you specify your log-in credentials and if this is talking to o365 OR on-prem (handles both really cool!).

JSON File: 

"ApplicationName": null,

"Server": "https://win-ebqb1hd3ns1/DansBikes",

"User": "Administrator",

"Password": "xxx",

"Domain": "win-ebqb1hd3ns1",

"Iso365": false

These are all pretty self explanatory. In my example I did not use an application name, feel free to. The next part is defining a table.

 {

     "Type": "List",

    "Name": "Customer",

        "Ignore": false, 

    "TitleName": "Email",

     "SharePointColumns":

[ 

        { 

          "Name": "First", 

          "Type": "Text", 

          "Parent": null, 

          "Data": null 

        }, 

        { 

          "Name": "Last", 

          "Type": "Text", 

          "Parent": null, 

          "Data": null 

        }, 

        { 

          "Name": "Phone", 

          "Type": "Text", 

          "Parent": null, 

          "Data": null 

        } 

      ]

This creates a “List” named “Customer” with the columns below: First, Last and Phone. In the head of this area, there is a switch to override the “Title” field. Here we rename it to “Email”. You can’t really get rid of the Title field, so use it well, it’s a primary key usually. For a customer table, Email is a great key. After the structure is created, you can add reference rows like this:

 "SharePointReferenceRows": [ 

        { 

          "SharePointReferenceColumns": [ 

            { 

              "Name": "First", 

              "Value": "Dan" 

            }, 

            { 

              "Name": "Title", 

              "Value": "Dan.Biscup@Microsoft.com" 

            }, 

            { 

              "Name": "Last", 

              "Value": "Biscup" 

            }, 

            { 

              "Name": "Phone", 

              "Value": "(813) 123-1234" 

            } 

          ] 

        } 

JSON is really fast, add as many rows as you need here. 

In the application, there really is nothing special going on, it uses this JSON file and builds the structures. It is not the best code in the world, and if you notice it creates the SP context a ton of times. Using o365 gave a few context issues, so this is the reason. Once again the importance here is the ability to create the infrastructure quickly and efficiently.

One thing to note is that sometimes you just want to do a partial build. In the head of the list creation you can set “Ignore” to true. This will skip the rebuild of the table. When this builds the structures, it deletes them first. Make note of that.

"Ignore": false

After the data app runs, it creates a .cs file with constants in them. This can be referenced on your consuming application. This will prevent column name change errors. If your infrastructure changes, the compiler will know. Hardcoding columns in your SharePoint item is so dangerous. As soon as the lists change you will get strange, hard to troubleshoot errors. Use constants!

In this example JSON file, an Entities.cs file was created. For the customer table it created this:

public class Entities_Customer

{ 

       public const string ListName = "Customer"; 

              public const string First = "First"; 

       public const string Last = "Last"; 

       public const string Phone = "Phone"; 

       public const string Email = "Title";

}

In my SharePoint add-in I add a link/reference to the Entities.cs file and add a new customer like this:

List lCustomerList                             = ctx.Web.Lists.GetByTitle(Entities.Entities_Customer.ListName);

ListItemCreationInformation liciCustomer       = new ListItemCreationInformation();

ListItem liCustomer                            = lCustomerList.AddItem(liciCustomer);

liCustomer[Entities.Entities_Customer.Email]   = Model.Email;

liCustomer[Entities.Entities_Customer.First]   = Model.FirstName;

liCustomer[Entities.Entities_Customer.Last]    = Model.LastName;

liCustomer[Entities.Entities_Customer.Phone]   = Model.Phone;

liCustomer.Update();

ctx.ExecuteQuery();

Everything is a constant. If the “Last” field in the “Customer” table changes to “LastName”, this code will break at compile time! This codebase is changing frequently. I plan on releasing it soon to GitHub to see what people add like views etc!    

NOTICE: I will be presenting at COSPUG 9/10/2015 on this topic: https://www.cospug.com/

DataApp.zip

Disclaimer:
Microsoft provides programming examples for illustration only, without warranty either expressed or implied, including, but not limited to, the implied warranties of merchantability and/or fitness for a particular purpose.

This sample assumes that you are familiar with the programming language being demonstrated and the tools used to create and debug procedures. Microsoft support professionals can help explain the functionality of a particular procedure, but they will not modify these examples to provide added functionality or construct procedures to meet your specific needs. if you have limited programming experience, you may want to contact a Microsoft Certified Partner or the Microsoft fee-based consulting line at (800) 936-5200.

Furthermore, there are many ways to do this. I personally found this to be a nice, easy way to do it.

OK,

The basic idea is, from the workflow email, the user clicks a link to a page inside the host web (SharePoint), then some JavaScript redirects them back to the CAM app with an ItemID in the querystring you can read in the app and load the work item accordingly. What is nice about this approach is redirecting them back to SharePoint first, establishes the authentication and authorization and gives you a chance to track or log activities or anything else before the app. Also you might want to redirect them to another version or some instructional page. Going to SharePoint first allows an easy way to manage this without having to edit the workflow each time. You are basically hardcoding the url to the redirect page in the workflow to a SharePoint page, then in the page redirecting them to the app.

To establish SharePoint context, the framework needs a few things: HostURL, AppURL, Language, ClientTag, ProductNumber and RemoteAppURL. An easy way to get these parameters is clicking on your app the first time. In the querystring you will see all this populated:

https://URL?SPHostUrl=URL&SPLanguage=en%2DUS&SPClientTag=0&SPProductNumber=15%2E0%2E4719%2E1000&SPAppWebUrl=APPWEBURL

The next part is adding the parameters you need, like ItemID and going to the page that loads your work item:

https://URLToCAMApp?ItemID=55&SPHostUrl=URL&SPLanguage=en%2DUS&SPClientTag=0&SPProductNumber=15%2E0%2E4719%2E1000&SPAppWebUrl=APPWEBURL

In your app you will need to read the ItemID and load data etc.

string strItemID = Request.QueryString[“ItemID”];

//Load work item etc.

After all that is setup, the next part is putting some JavaScript on a page in SharePoint that redirects them to your app. I personally like the XML editor over the content editor webpart. So add a webpart to a page named “Redirect.aspx” and add this code:

/*
Microsoft provides programming examples for illustration only, without warranty either expressed or implied, including, but not limited to, the implied warranties of merchantability and/or fitness for a particular purpose.
This sample assumes that you are familiar with the programming language being demonstrated and the tools used to create and debug procedures. Microsoft support professionals can help explain the functionality of a particular procedure, but they will not modify these examples to provide added functionality or construct procedures to meet your specific needs. if you have limited programming experience, you may want to contact a Microsoft Certified Partner or the Microsoft fee-based consulting line at (800) 936-5200.
*/
<script src="../SiteAssets/jquery-1.11.3.js"></script>

    <script>
        $(document).ready(function () {
            var nItemID = qs("ItemID");
                   
            if(nItemID != -1)
            {
                location.href = "https://AppURL?ItemId=" + nItemID + "ItemID=55&SPHostUrl=URL&SPLanguage=en%2DUS&SPClientTag=0&SPProductNumber=15%2E0%2E4719%2E1000&SPAppWebUrl=APPWEBURL";
            }
        });

        function qs(key) {
            key = key.replace(/[*+?^$.\[\]{}()|\\\/]/g, "\\$&"); // escape RegEx meta chars
            var match = location.search.match(new RegExp("[?&]" + key + "=([^&]+)(&|$)"));
            return match && decodeURIComponent(match[1].replace(/\+/g, " "));
        }
    </script>

After that is in place, calling Redirect?ItemID=55 from your workflow (or anywhere) will launch your CAM application with the correct context and pass the ItemID where you can load the work item.