Nick and I are in the process of building separate mobile applications and we often spit-ball ideas about the architecture of our applications and how we handle certain scenarios as they come up with our applications.   to set the basis of what we have been discussing, Nick’s application started off as a web application (actually, it’s a Facebook app in which Nick  was honored as having one of the top Facebook apps on the planet!).  He is now in the process of making his app a native mobile application (Brownfield).  My application comes from the perspective of building a brand new Azure Mobile Services application (Greenfield). 

Both approaches have their own unique pros and cons.   So this lead us to wonder what might be the pros and cons of using Windows Azure Mobile Services vs. building a mobile application using the individual (A la Carte) services offered by Windows Azure.  Get the details of this Azure Post here.

http://karimkameka.com/2015/02/02/living-the-dream-as-a-web-developer/

I’ve just added my latest post on my new blog http://karimkameka.com.  This one discusses how to make a AngularJS Directive to get Google AdSense working on your AngularJS site. 

http://karimkameka.com/2015/01/27/integrate-google-adsense-with-an-angularjs-web-site/

Don’t forget to follow me on Twitter @livehands

I’m working with a customer who has 7000+ sites hosted in an On-Premise SharePoint 2010 farm.  The farm has about 78 custom WSPs deployed throughout the farm. We had very little source code from each of the WSPs as this customer was a perfect example of how not to do SharePoint Application development.  We had solutions raging from the deployment of custom CSS to others involving web services deployed to the ISAPI folder on the WFEs.  Needless to say many recommended practices were not followed. 

The following steps were used to evaluate the farm.  These are necessary in the Planning stages to determine what will/can be moved. 

1. Capture the Inventory of your sites and the Information Architecture. The inventory should capture the following:
1. List of Web applications
2. List of Site Collections
3. List of Sites
4. List of Features and their Associated Site Collections/Sites (Important for STEP 2)
5. Size of each site
6. Last Updated Date for the site items. (Will help identify dead sites)
2. Capture the inventory of your Solution Packages (WSPs) and download.
3. Use a tool like SPCAF http://www.spcaf.com/ to evaluate.  SPCAF will provide a report for migration to the cloud and thus the recommendation to use the tool.   (This tool was invaluable in getting the evaluation of the WSPs done in a timely manner.)  We classified each WSP into one of the following buckets, the timelines are based on our teams capacity to convert the items.
1. Low (2-4 weeks) - Converting simple SharePoint artifacts like web parts, Content Types/Branding to the new model.
2. Medium (4-6 Weeks) - Solutions with complex deployments/configurations.  This would include things like rewriting a Visual Studio Workflow and or converting Event receivers.  This could also include those solutions with numerous Web parts and other artifacts which need to be converted.
3. Medium-High (6-10 Weeks) - Solutions which will need some re-architecting and/or alternate configurations due to artifacts and/or services which are deployed directly to the SharePoint server.  An Example here would be a web service which was deployed to the ISAPI folder as this will not be allow in O365  we will need an alternate place for deploying this solution and the ability for the sites leveraging these solutions to access the new deployment location (preferably Azure).
4. High (10+ Weeks) - These should be full on rewrite which will require some requirements gathering and building of a project backlog.  They will require architecture design of the solution/app and would typically be a large solution/project with multiple components
4. Once the WSPs are classified we evaluated the Sites from Step 1 and matched those up with the sites which were using the custom features in the WSPs from Step 3.  This gives us a report on which sites contain customizations and which ones do not.  We now have an idea on which sites will be trouble
5. We now needed to determine which sites get migrated first.  We created a set of buckets for Site Classification:
1. Low – No Customizations Required.  These sites were migrated first. 
2. Medium – Small customizations which could be completed quickly such as the Low & Medium solutions from Step 3 above.
3. High – Any customizations which will take some time to migrate.
6. We them formulated the schedule for migration based on the above information.  We are using a migration tool to do the pushing of the data to O365 as part of our Testing and eventually our Execute stage.

SharePoint Artifact Migration Recommendations

Once we had our Inventory we classified each of the custom artifacts with a plan of attack for migrating these items to the Cloud.  Because Solution Packages (WSPs) are not allowed in O365.  These packages and their associated SharePoint Features will need to be broken down and converted to the SharePoint App Model where applicable.  Many of the guidelines for converting these solutions reside as part of the O365 Patterns and Practices recommendations.  Below are he guidelines we used for the various artifacts:

1. Provisioning/Web Templates/Site Templates – Any web templates and site templates as well as the process for provisioning new sites should leverage the guidelines from the O365 Patterns and Practices team.
2. Branding & Layout –Contains the deployment of CSS, JavaScript, master pages, page layouts and the associated content types.  The migration of these items should follow the guidance from the O365 Patterns and Practices team.  (http://www.microsoft.com/en-us/download/details.aspx?id=42030)
3. Workflows  -  Custom workflows created in Visual Studio which use code behind to complete tasks. Workflows which were built with Visual Studio will need to be converted to the SharePoint 2013 declarative workflow model.  These workflows will need to be rebuilt from scratch.
4. Content Types – These were custom content types which were deployed as a part of a WSP Solution. Content Types should be evaluated to determine if they can reside in a Content Type Hub.  This will provide the content types to all Site Collections subscribing to that hub and provide a safe location for management of the enterprise content types which were previously deployed as WSP solutions. Secondly, Content Types can be deployed using CSOM and the App Model APIs available for use in the O365.
5. List Templates – custom list templates and in some cases their associated implementations which are deployed as part of a WSP Solution.  List Templates can be deployed via the CSOM APIs and by leveraging the Application model APIs.
6. Web parts -  Custom web parts which are deployed as WSPs. All Web parts will need to be recreated as SharePoint 2013 App Parts.  This will bring these solutions into the App Model configuration and allow for the deployment of these Web Parts into the Cloud.
7. InfoPath Forms – InfoPath forms which contained code behind and or required full trust in order to work.  Administrator/Full Trust Info Path forms will should be rewritten as SharePoint Hosted Applications.  This will allow the required flexibility needed for the forms while allowing the use of the form on multiple sites as needed through the SharePoint 2013 App Model.
8. WCF/Web Services – WCF Services which were deployed to the Web Front End servers which contained calls to the SharePoint APIs.  These services need to be redesigned/built as SharePoint Provider Hosted Apps. 
9. Web.Config Modifications – Changes to the Web.config on the Web Front Ends which were needed to enable functionality by custom code. These modifications will need to be identified and the associated solutions which required them will need to be refactored into a supported model.  Most likely these solutions will become Provider Hosted Applications for which the required customizations can be made without deploying anything to the SharePoint servers.

I was looking to integrate the Instagram Real Time API from my application, however when I sent my request to Instagram to register my subscription I kept getting a response with the error below. After investigating this issue it turns out that Instagram is expecting the data for this request to be sent as form data (i.e. Content-Type = x-www-form-urlencoded).  This was not obvious as the other Instagram APIs I used just accepted the required parameters via the URI in parameters or via the route specified. 

When sending my request to https://api.instagram.com/v1/subscriptions  I sent my request as a POST in JavaScript I was getting the following payload returned with the error description from Instagram:

"{\"meta\":{\"error_type\":\"APISubscriptionError\",\"code\":400,\"error_message\":\"Invalid format for \\\"callback_url\\\". URL must start with \\\"http:\\/\\/\\\" or \\\"https:\\/\\/\\\"\"}}",

The issue was I was sending my requests using the ‘data’ member in my JSON like this:

WRONG

request({
            uri: url,
            method: "POST",
            data:  {
                        aspect: "media",
                        callback_url: [MY CALLBACK URL],
                        object: “tag”,
                        object_id: “Frendli”
                       }

        });

However because Instagram is looking for the data to be sent a form in the POST I had to amend the request to use the ‘form’ field in the request instead.  Once I did this all was well. See the corrected request below, for a more detailed description of how to automate this with node.js in Azure Mobile Services check out my article about how to create a Instagram subscription with Azure Mobile Services.

CORRECTED

request({
            uri: url,
            method: "POST",
            form:  {
                        aspect: "media",
                        callback_url: [MY CALLBACK URL],
                        object: “tag”,
                        object_id: “Frendli”
                       }

        });

For more developer goodness follow me on Twitter @livehands

My application required the need to have images from Instagram show up in a user’s feed as it was available.  At first I thought about just polling the Instagram feed’s using a Scheduled job (which is a part of the mobile service) however this solution did not scale well due to the limited number of SQL Azure connections in the service.  This lead me to the real-time API to have Instagram tell me when to update my application.  As a part of this I also wanted the user’s to have the ability to specify the tag for which they would like to follow, as well as the username (in many cases their own) they would like to follow as well.  Given these requirements I needed a generic enough API which would allow my application to subscribe to these objects in Instagram and then have them populate in my application by storing in a table. 

So enough background let’s get to the code. 

Step 1. Create an InstagramSubscriptions table.

There are a few tables and services I needed in my solution.  We want to create these here first, this way when we get to our API Controllers we are ready to go.

The first Item is a table to keep track of the subscriptions.  This table is needed as when a new item is added to Instagram the Instagram publishing service will call your API method with the subscription payload.  The payload does not contain any media information, a second call from your API will need to be made to actually get the items.  Secondly, I needed a way to tie this subscription back to a user. This table also provides a quick way for me to delete a subscription from the Instagram service without having to first call Instagram’s subscription API. 

1. Create a Table named “InstagramSubscriptions”
2. Add the following Columns all of type String:
   1. SubscriptionId
   2. UserId
   3. ObjectType
   4. ObjectId

Step 3.  Create the Item Push API

The Push API as I call it will be the callback method for which Instagram will use when there is a new item for the subscriptions in your application.  This callback will receive a payload with the subscription details for which new items have been added.  Once this payload is received you will have the ability to call the other Instagram API methods to get the actual data (images/video) you can then pull into your app.  In the Mobile App Service create a new API, I called mine “Instagram_push”.  You will need a GET method and a POST method which is accessible to “Everyone” as Instagram will not be able to authenticate and/or use your Application key.  To keep the process secure Instagram sends a Verify_Token, which is setup when you create your subscription (we will see this in the next step).  You should always validate the Verify_Token when new subscription requests are sent as this is the only way to ensure this is a valid call from Instagram.

Here are the two methods I created to be used as my callback method when Instagram needs to send me an update for new items, I’ve left the spot when you implement your logic blank in this sample, but in my case I update some tables and perform other logic which retrieves the items in this spot when Instagram sends me an update:

exports.post = function(request, response) {

    var bodyObject = JSON.Parse(request.body); // Parse the response into a JSON object for use in my Script
    console.log("Instagram Push: " + new Date());
    console.log(request.body);

// ADD YOUR LOGIC HERE!

//TYPICALLY CALL INSTAGRAM API TO GET THE NEW ITEMs

};

exports.get = function(request, response) {
    var hubchallenge = request.query["hub.challenge"];
    //console.log ("Hub Challenge: "  + hubchallenge)
    response.send(statusCodes.OK, hubchallenge);
};

Step 2.  Create the Subscription Service API

The second half of what I needed was to have a method for my application to automate the creation of subscriptions with Instagram.  I also wanted to create a way to remove these subscriptions if the user choses to do so.  To accomplish this I create a second API interface which handles the subscription service.  This service will take in some parameters in the body:

• igObjectType – This is the type of subscription.  should be “tag”, “user”, “geo”
• igName – The string for the tag or the username for which we are creating this subscription.
• userId – the user Id I use to tie this subscription in my application.

I also set some environment variables such as the Push API Url which will be used as our call back.  You should replace this URL with your Mobile Service URL.

SECURITY HINT: unlike the Item Push API above this API should be secured using the Mobile service methods.  I chose to lock this service down by only allowing authenticated users.  You should use what is best for your application.

exports.post = function(request, response) {
    // Use "request.service" to access features of your mobile service, e.g.:
    //   var tables = request.service.tables;
    //   var push = request.service.push;
    var sql = request.service.mssql;
    var instagramPushUrl = "https://[YOUR MOBILE SERVICE URL]/api/instagrampush/";
    var igName = request.body.igName;
    var igObjectType = request.body.type;
    var streamId = request.body.streamId;
    var createSubscriptionQuery = "INSERT INTO InstagramSubscriptions (userId, subscriptionId, objectType, objectId) VALUES (?, ?, ?, ?)";

//Ensure a valid user Id for my applications.     

if (!userId) {
        request.respond(403, { message: 'Bad request! No User Id for this subscription' });
    }

    if (!igObjectType) {
        igObjectType = "tag"; //Set Default if not passed
    }

    var httpRequest = require('request');
    if (igName) {
        var url = 'https://api.instagram.com/v1/subscriptions?client_id=[YOUR CLIENT ID]&client_secret=[YOUR CLIENT SECRET]&verify_token=[YOUR VERIFY TOKEN]';
        var msgBody = {
            aspect: "media",
            callback_url: instagramPushUrl,
            object: igObjectType,
            object_id: igName
        };

        httpRequest({
            uri: url,
            method: "POST",
            form: msgBody,

        }, function(err, response, body) {
                //console.log("IG Response: " + body);
                if (err) {
                    console.error("IG Subscribe Error: " + err);
                    request.respond(500, { message: 'IG NOT Subscribed for 1 ' + igObjectType + ' with name ' + igName + '!' });
                }
                else if (response.statusCode !== 200) {
                    console.error("IG Subscribe Error: " + err);
                    request.respond(500, { message: 'IG NOT Subscribed for 2 ' + igObjectType + ' with name ' + igName + '!', err: body, url: url + msgBody });
                }
                else {
                    var bodyObject = JSON.parse(body);                   
                    //console.log ("Result from Subscription: " + bodyObject);                   
                    //console.log("Subscription Id: " + subscription.id);
                   
                    var subscription = bodyObject.data; 
                   
//Update my DB

sql.query(createSubscriptionQuery, [userId, subscription.id, igObjectType, igName], {
                        success: function(result) {
                            request.respond(statusCodes.OK, { message: 'IG Subscribed for user ' + igObjectType + ' ' + igName + '!', result: body });
                        },
                        error: function(error) {
                            console.error(error);
                            console.log('IG Subscription Created but not logged for ' + igObjectType + ' with name ' + igName + '!' + ' and SubscriptionId ' + subscription.id);
                            request.respond(statusCodes.OK, { message: 'IG Subscription Created but not logged for ' + igObjectType + ' with name ' + igName + '!', result: body });
                        }
                    });
                }
            });
    }
    else {
        request.respond(404, { message: 'User ' + igName + ' not found!' });
    }
};

//DELETE METHOD

exports.delete = function(request, response) {
    var sql = request.service.mssql;
    var subscriptionId = request.query.subscriptionId;
    var deleteQuery = "DELETE FROM InstagramSubscriptions WHERE subscriptionId = ?";

    if (!subscriptionId) {
        request.respond(403, { message: 'Bad request! SubscriptionId is required' });
    }

    var httpRequest = require('request');

    var url = 'https://api.instagram.com/v1/subscriptions?client_id=[YOUR CLIENT ID]&client_secret=[YOUR CLIENT SECRET]&id=' + subscriptionId;

    httpRequest({
        uri: url,
        method: "DELETE",
    }, function(err, response, body) {
            //console.log("IG Response: " + body);
            if (err) {
                console.error("IG Subscribe Error: " + err);
                request.respond(500, { message: 'IG NOT delete Subscribed for subscription with id ' + subscriptionId });
            }
            else if (response.statusCode !== 200) {
                console.error("IG Subscribe Error: " + err);
                request.respond(500, { message: 'IG NOT delete Subscribed for subscription with id ' + subscriptionId });
            }
            else {
                sql.query(deleteQuery, [subscriptionId], {
                    success: function(result) {
                        request.respond(200, { meta: { code: 200 }, data: [] });
                    },
                    error: function(error) {
                        console.error(error);                       
                        console.log("Failed to update database after deleting subscription with id: " + subscriptionId);
                        request.respond(200, { meta: { code: 400 }, data: { subscriptionId: subscriptionId } });
                    }
                });
            }
        });
};

The next step was to get the SQL Query for which I could apply my newly found calculation.  After speaking with a very good friend of mine who is a SQL genius he helped me put the following query together:

SELECT * FROM myTable WHERE (POWER ((POWER( (69.1 * ( Longitude - @longitude ) * cos(@latitude/57.3)) , 2 ) + POWER( (69.1 * ( Latitude - @latitude )) , 2 )), .5)) < ( @radiusInMiles )

@longitude, @latitude, @radiusInMiles are all parameters you can pass to the stored procedure to keep the query dynamic. 

Happy locating!

Built using leading technologies: Windows Azure, SharePoint Online, HTML5 and jQuery SPMedia delivers a scalable cross browser+device solution.

Check out more details at: http://spmedia.io

Download the app here: http://office.microsoft.com/en-us/store/sp-media-WA104364733.aspx