emagazine E-reader version

Size: px
Start display at page:

Download "emagazine E-reader version"


1 emagazine E-reader version

2 Contents DIWUG SharePoint emagazine Colofon Nr. 12, February 2014 Publisher: Stichting Dutch Information Worker User Group (DIWUG) Editors: Marianne van Wanrooij Mirjam van Olst Special thanks to: All authors and sponsors! Design and layout: Barth Sluyters All rights reserved. No part of this magazine may be reproduced in any way without prior written permission of DIWUG or the author. All trademarks mentioned in this magazine are the property of their respective owners.

3 Creating a magazine remains something special, even at the 12th edition. A lot of labor and love goes into each edition of the DIWUG SharePoint emagazine, both from the authors, the editors and from our designer. When the deadlines are approaching it feels like mostly hard work, but holding the first printed copy of a new edition is always something a bit special. Thanks to our authors, readers and sponsors we continue to expand our territory. Up until this edition the magazine was downloaded and read by SharePoint enthusiasts from all over the world, while the people that visit our DIWUG user group events, the SharePoint Connections Conference or the SharePoint Evolution Conference have also been able to get free printed copies. We are very proud that thanks to our sponsor Avanade the DIWUG SharePoint emagazine is now going to cross half the world to end up in Las Vegas, at the Microsoft SharePoint Conference. If you are going to be at the conference make sure to pick up a free copy of the magazine from the Avanade booth in the Exhibitor Hall. If you aren t going to be in Las Vegas we hope that you will enjoy the digital copy of this magazine just as much as you would a printed one. If you aren t going to the Microsoft SharePoint Conference, or if you would like to get inspired even more please consider coming to the European Office 365 Connect event in Haarlem in the Netherlands on April 1 and Use the DIWUG code (RC836) for a 25% discount when registering for the Office 365 Connect event. We are always looking for authors who like to write an article for our next magazine, so if you feel inspired don t hesitate to contact Marianne or Mirjam. If you want to sponsor the magazine that has a world-wide audience with around downloads and 800 printed copies, please contact us as well. Mirjam van Olst Editor DIWUG SharePoint emagazine


5 Migrating Developers to the SharePoint 2013 App Model by Scot Hillier Traditionally, SharePoint developers have thought about SharePoint solutions as an extension to the product. An end user might request, for example, the ability to print items from a list. The SharePoint developer would respond by extending the product to have a new button in the ribbon that displays the list on a chrome-free master page and invokes the print dialog. This new capability is subsequently deployed as a feature, which can be activated on sites as needed. Although it s still possible to create these capabilities in SharePoint 2013, our relationship with SharePoint has actually changed dramatically. Instead of extending the SharePoint product, we are really creating separate enterprise apps that utilize services from SharePoint as needed. Instead of creating that printing feature, we are much more likely to create a contact-management app that has a print capability and consumes lists from SharePoint. Scot Hillier will be migrating developer skills to SharePoint 2013 during a one-day pre-conference seminar, March 2 at SharePoint Conference 2014 in Las Vegas. This change in approach means that most apps are in fact enterprise applications, which must be properly architected within the context of SharePoint While most development teams are currently concerned with migrating code from server-side to client-side, they should really be concerned with the underlying technologies and patterns necessary to create these enterprise apps. Then they will be well positioned to migrate the actual code to the client-side object model (CSOM) or REST APIs. In order to be successful writing SharePoint apps, development teams must initially make decisions regarding their standard approaches for: Enterprise JavaScript Enterprise App Patterns Enterprise Services Architecture Enterprise JavaScript For SharePoint 2013 developers, JavaScript has suddenly become a core skill. While many developers have written some JavaScript, most SharePoint developers have not written enterprise applications that consist entirely of JavaScript. As a result, we currently risk littering the SharePoint landscape with unmaintainable JavaScript code. The answer is to decide on a pattern for creating maintainable, enterprise JavaScript code. While there are advanced tools (e.g., CoffeScript and TypeScript) that can help, one of the simplest ways is to encapsulate your JavaScript code in modules. Modules provide a clean pattern for encapsulating JavaScript and reusing it across projects. Listing 1 shows a simple module that retrieves properties from the current user s SharePoint profile.

6 Listing 1: A Simple JavaScript Module The module shown in Listing 1 demonstrates several key concepts for managing enterprise JavaScript. First, the module is defined within the Wingtip object, which functions like a namespace to prevent code collisions. Second the module uses strict JavaScript, which disallows several otherwise legal JavaScript operations that typically cause problems. Third, the module returns an object that reveals the underlying function named me(), which allows for the concept of both public and private code. Fourth, the me() function returns a promise, which allows multiple asynchronous operations to be orchestrated as require by the calling client code. All of this means that client code can invoke the functionality with Listing 2. Listing 2: Calling a JavaScript Module The above code makes an asynchronous call to the me() function and runs the success or error handler when the call completes. Notice how even in this simple example, our JavaScript is nicely encapsulated and called using a syntax that feels familiar to C# programmers who have traditionally utilized the.net Framework. If you expand this pattern to all of the layers in your enterprise app, it is possible to create robust apps that consist entirely of JavaScript. Enterprise App Patterns Traditionally, SharePoint developers have not had to concern themselves much with enterprise development patterns. Because SharePoint development historically consisted of project types that were unique to SharePoint, we often developed our own patterns for creating things like visual web parts or new forms for lists. In the new model, however, we must utilize an enterprise pattern in order to be successful. Enterprise patterns give us a way to structure code, organize the projects and implement separation-of-concerns. Enterprise patterns can be extremely difficult to implement without proper tooling. Therefore, you will want to select a pattern that is supported by Visual Studio and other third-party tools/libraries so that you can teach your development team repeatable techniques. In reality, this means choosing between the Model-View- ViewModel (MVVM) pattern and the Model-View-Controller (MVC) pattern. These patterns are theoretically similar, but their practical tooling implementation in Visual Studio is quite different. Figure 1 and 2 show simple block diagrams of both patterns.

7 Figure 1: MVVM Figure 2: MVC At a high level, the MVVM and MVC pattern function similarly. In the MVVM pattern, the ViewModel is responsible for performing CRUD operations on the data, filling a Model with the data, and transferring that Model to the View for rendering. In the MVC pattern, the Controller fills essentially the same role. The real difference between the two lies in the tooling support and code structure. The MVVM Pattern The MVVM pattern in SharePoint 2013 app development is best implemented using only JavaScript within SharePoint-hosted apps. This is because Visual Studio does not have direct support for this pattern, so we must utilize a third-party JavaScript library named Knockout. Knockout implements the MVVM pattern by utilizing two key concepts: Dependency Tracking and Declarative Binding. Dependency Tracking allows you to create a ViewModel using standard JavaScript (encapsulated in a module, of course), which Knockout observes for changes using its special ko.observable and ko.observablearray objects. Listing 3 shows the basic structure that creates a ViewModel as an array of objects. var Wingtip = window.wingtip {}; Wingtip.ContactViewModel = function () { use strict ; var contacts = ko.observablearray(), get _ contacts = function () { return contacts; }, var load = function () { $.ajax( { url: / _ api/web/lists/getbytitle( Contacts )/items, method: GET, headers: { accept : application/json;odata=verbose, }, success: function(){ //fill observable array } }); }; }(); return { load: load, get _ contacts: get _ contacts }; Listing 3: A simple ViewModel

8 Once the ViewModel is created, it can be bound to a HTML page using the ko.applybindings method of the Knockout library. This method processes the target element looking for the special binding attributes data-bind. Listing 4 shows an example. Listing 4: Declarative Binding The MVC Pattern When implementing the MVC pattern in SharePoint apps, you can choose to use it with either SharePoint-hosted or Provider-Hosted apps. This is because tooling is available to you in the form of both a third-party JavaScript library and a project type in Visual Studio. For SharePoint-hosted apps, the MVC pattern can be implemented using the Angular library. Angular allows you to create Controllers in JavaScript (once again, properly encapsulated in a module). These controllers function within the scope of an Angular app defined using code similar to the following: The scope is then injected into a controller, which performs CRUD operations and passes Models to the view. Listing 5 shows an Angular controller that welcomes the current user by retrieving their profile information. Compare this code to that of Listing 3.

9 Listing 5: A Simple Angular Controller Once the controller is created, it is bound to the HTML page using declarative attributes in a way similar to Knockout. The Angular attributes all begin with ng and specify the controller to use when rendering the HTML chunk as well as how to bind the model using a syntax based on double curly braces {{ }}. Listing 6 shows an example. Compare this to Listing 4. Listing 6: Angular Binding While Angular provides a JavaScript-based way to implement the MVC pattern for SharePoint-hosted apps, ASP.NET MVC5 provides a sophisticated framework for implementing the MVC pattern in Provider-hosted apps. Beginning with Visual Studio 2013, the options for creating Provider-hosted apps now includes MVC5, which is a huge win for developers. MVC5 is based on the creation of controllers, just like Angular. However, the controllers in MVC5 utilize C# code instead of JavaScript. Furthermore, you can use the managed client object model with these controllers to create SharePoint apps with no JavaScript at all. This architecture may be very appealing to teams that have good.net skills, but weaker JavaScript skills.

10 Listing 7: A Simple MVC5 Controller An MVC5 controller is created as a class with methods. Each method is mapped to a URL using the concept of routes. This approach stands in contrast to ASP.NET Web Forms which map a single page to a URL. Initially, this may take some getting used to, but the approach is much more powerful and straightforward than the Web Forms model. As an example, the Listing 7 shows a controller that welcomes the current user. Compare this code to listing 5. In Listing 7, the data from the controller is passed to the view using the ViewBag object. The ViewBag object is a loosely-type container for whatever data you want. While this is simple, the best practice is to use a strongly typed view, which is possible by creating a separate class to contain the data you want. Each method in the controller is mapped to a partial view, which is rendered using a combination of HTML and specialized markup as shown in Listing 8. Compare this to Listing 6. Listing 8: A Simple MVC5 View Enterprise Services Architecture The SharePoint 2013 app model is only possible because of the outstanding API provided through the CSOM and REST endpoints. Additionally, SharePoint developers can take advantage of many Internet-based services found at places like the Azure Data Marketplace to make their apps powerful and useful. Consequently, many online samples focus on the consumption of RESTful services in SharePoint apps. However, development teams must also decide how they will create and expose their own data to enterprise apps. One of the best solutions to this problem is to create a serviceoriented architecture (SOA) utilizing WebAPI2. WebAPI2 uses the same basic MVC framework as MVC5 Provider-hosted apps. Instead of returning HTML, however, they return JavaScript Object Notation (JSON) objects. This means that WebAPI2 services fit into your enterprise architecture in exactly the same way as other RESTful services. Furthermore, it s incredibly easy to create these services once you have learned to create controllers in MVC5. Listing 9 shows an example service that returns simple customer information.

11 Listing 9: A Simple WebAPI Controller The above code creates a simple collection of customer objects and exposes them as a RESTful endpoint. The Get() method allows for the retrieval of multiple items while the Customer method returns specific items. You can then create ViewModels using code similar to Listing 10. Listing 10: Calling the WebAPI Conclusion As you can see from the discussion, creating enterprise SharePoint 2013 apps has less to do with traditional SharePoint workloads (like Search, Business Connectivity Services, and Metadata Services) than it does with properly architecting the app. This is an odd situation for SharePoint developers, who have come to expect SharePoint development to be unique and require many secret techniques, keywords, and artifacts. To be sure, your SharePoint apps will still take advantage of many SharePoint services, but the focus of development teams should be on upgrading team development skills and specifying standard architectures. In other words, focus more on migrating the developers than migrating the code.

12 Host-named site collections by Jasper Siegmund With SharePoint 2013, Microsoft claims we need to rethink our architecture. Host-named site collections are a promoted way to go, preferably all within the same web application. But what are host-named site collections and what do we need to take into account when setting this up? Host header web apps in SharePoint 2010 For the readers not already familiar with host headers, we ll start with a bit of history. Previous versions of SharePoint have been constantly redesigned, as we all know so well. Building towards Office 365 / SharePoint Online, Microsoft had to overcome some challenges serving multiple customers from the same farm. To be able to share a farm across multiple customers, Microsoft introduced the notion of site subscriptions in SharePoint This was an evolution of something called scalable hosting mode which was in the product since SharePoint A site subscription is a 1-n relation between a subscription and site collections. Together with subscription aware service applications, this allows us to provide seemingly separate environments to multiple tenants within a single farm. Separate, since they still share things on a technical level. SharePoint URL s But what about the site collection URL s? Traditionally, a path-based SharePoint URL pointing to a site collection consists of the following parts (figure 1): Figure 1: a SharePoint path-based URL lay-out 1 The protocol, usually http or https. 2 The URL which is bound to the web application. 3 A managed path. 4 The site collection relative URL. This imposes a problem, since Microsoft wanted to give tenants the option to configure their own URL s, instead of having to use a predetermined one. So for that purpose, they introduced the host header web application. Within the host header web application, we can create site collections which have their own URL bound to them. This is done via PowerShell by specifying the HostHeaderWebApplication parameter for New-SPSite:

13 Listing 1: Creating a host-named site collection in SharePoint 2010 So now we can run multiple sites within the same web application, all having different URL s. Cool! SharePoint 2013: host-named With SharePoint 2013, things change a bit. As already stated, Microsoft now wants us to use host-named site collections by default. What s in a name? Unfortunately the naming of the concept and the parameter are be a bit confusing, but if you have been working with SharePoint for a while chances are you are used to this. The important things to know are: When you want to configure multiple web applications supporting host-named site collections, you need to use the HostHeader parameter to configure the URL of the web application. Within IIS we also need to configure that same URL, within the web applications host name bindings. And when you re then going to configure managed paths, it s back to host headers again. Hmm But fine; whether you call it a host header or host name, the goal is to provide site collections with their own URL s, instead of using the web applications URL. Setting it up There is a pretty elaborate article on how to set up host-named site collections on TechNet, so I ll won t go into details in this article. The basic steps are: 1 Make sure the Default Web Site in IIS is stopped on all of your front-end servers. This makes use of the :80 binding, which catches all incoming requests on port 80. Because SharePoint is going to register that binding, we need to make sure no other active web site is using it or we ll get an error telling us The IIS Web Site you have selected is in use by SharePoint. 2 Create a new SharePoint web application. Instead of creating one with a predefined URL, we will only be using a port number. As always, the preferred way of doing this is using PowerShell: Listing 2: Creating a web application to host our host-named site collections This will create a web application which behaves like IIS Default Web Site; it catches all incoming requests on port 80 which are not handled by one of the other websites with a specified URL (binding). Because of that, you can only create one of these per IP address / port combination, since IIS wouldn t know which one serves a particular site. When you want to create multiple web applications like this, add IP addresses to your server or use different ports (which is usually not a good practice except for 443 SSL).

14 3 Create a root site collection for the web application. Although you might not use it yourself, this step is still mandatory because every web application in SharePoint is required to have a root site collection. The main reason is because applications like search send requests to the URL of the web application and expect something to be there. Without a root site collection, SharePoint returns a 404 Not Found leaving search with nothing to index. Listing 3: Creating a root site collection 4 Create site collections using the New-SPSite PowerShell commandlet, passing in the HostHeaderWebApplication parameter specifying our newly created web application: Listing 4: Creating host-named site collections Managed paths Alongside the above mentioned per-site collection URL s, we can also use managed paths when creating host-named site collections. This too can only be done via PowerShell, with the New-SPManagedPath cmdlet specifying the HostHeader parameter. Suppose you want to create portal.contoso.com/departments/marketing, you would configure: 1 A managed path for /departments (wildcard). 2 A host-named site collection at this needs to exist before we can create a site collection which uses the managed path. 3 A host-named site collection at marketing. Recommendations As said in the introduction, Microsoft is promoting the use of host-named site collections in a single web application. The most important reason behind this is quite simple: they use the same approach themselves in Office 365. That automatically means it s one of the best tested options and Microsoft will invest more time into making it work brilliantly opposed to the traditional method of creating site collections (which is not used within Office 365). A second advantage is that a host-named site collection is very portable. Since the URL is now bound to the site collection, you can move the entire thing without changing the URL of the content. So users can view their pages, lists and documents regardless of the web application or farm the site collection is in. That also implies you can move sites towards the cloud and back without users even noticing the difference. That is, of course, based on the assumption you ve got things like authentication and DNS set up properly. And moving stuff to the cloud; that s what Microsoft likes! But is it all truly amazing, or are there considerations to be made? Migration To start with; there s migration. Companies coming from SharePoint 2010 will probably not have an architecture with host-named site collections (hosting providers with multi-tenancy environments might have). So moving towards this architecture means you ll have to rethink your URL s and some of them will most likely change, breaking content links.

15 Also, your IT decision makers might wonder: what s the real benefit here? Apart from the testing and commitment already mentioned, your sites are just as fine without their own host-name. So one might wonder: why go through all the trouble? One web application, bye bye governance? There s also the matter of governance. A web application comes with settings. For instance; there s a link between a web application and the service application proxy group it s using. So when your requirements are dictating different sites need different service application instances; one web application isn t feasible. You can easily check out the settings per web application in Central Administration to make a list of governance issues when it comes to using a single web application. Also, your company might have processes in place which automate the site creation workload. When there is a self-service system facilitating the creation of site collections, take into account that this will need to be changed as well. SSL Another issue arises when you want to make use of SSL certificates. Because each site has a different URL, that requires a different SSL certificate per site (since verifying that particular URL is one of the things the certificate does). To handle multiple sites, we would need a wildcard certificate (which works on *.contoso.com) or configure SNI (Server Name Indication). A wildcard certificate works for *.contoso.com. SNI allows us to configure multiple certificates on the same IP address / port, something which was not possible before. Note that in order for SNI to work, you will need to have a recent browser and web server in place. In most cases, using a wildcard certificate will be the preferred option. As an example, think of *.sharepoint.com where your SharePoint online site (https://tenant.sharepoint. com) is being hosted. Alternate Access Mappings For sites which use alternate access mappings, the message is very clear: those don t work with host-named site collections. There s no way to configure alternate access URL s for different zones. Should you want to use multiple URLs to access the same site collection in a host-named scenario, there is the possibility to configure a URL per zone. You can use the Set-SPSiteUrl cmdlet as follows: Listing 5: Adding zone URLs to a (host-named) site collection This allows for up to 5 URLs per site collection (default, intranet, internet, custom, extranet). Use Get-SPSiteUrl to retrieve which URLs are configured: Figure 2: multiple URLs configured for a host-named site collection Conclusion: it depends As so often with SharePoint, it s a matter of: it depends. It depends whether you want to spend the time setting this up. It depends whether you want to use the 2013 bits which require this architecture. It depends if you need the governance of settings which you cannot get with this architecture. If depends how quickly you want to adjust to Microsoft testing this and telling us it s the future. Etcetera.

16 There s a lot of speculation about the future of SharePoint. And although Microsoft is pushing the cloud, many believe that on-premises will be getting its share of loving at the upcoming SPC in So maybe the traditional web application model will still be there for the foreseeable future. But for newly built SharePoint 2013 installations, it might be worthwhile at least considering the option of host-named site collections. Recommended reads For everyone who considers implementing host-named site collections, I recommend the following articles: Host-named site collection architecture and deployment (SharePoint 2013) - What every SharePoint Admin Needs to Know About Host Named Site Collections by Kirk Evans - what-every-sharepoint-admin-needs-to-know-about-host-named-sitecollections.aspx Host Named Site Collections (HNSC) for SharePoint 2010 Architects - blogs.msdn.com/b/markarend/archive/2012/05/30/host-named-site-collectionshnsc-for-sharepoint-2010-architects.aspx

17 SharePoint development 2.0 From the individual production to the industrialization Lana Khoury / Sebastian Gerling Constantly increasing cost pressures, a growing need for qualified SharePoint developers, as well as the demand of customers for timely implementation of defined projects and applications are leading to the need for an industrialization in SharePoint development in its consequence. Component manufacturing and parallel processes are allowing to deliver customer specific projects more efficiently. Industrialization in software development Deadline pressures, quality problems and unsatisfied customers are a given experience for most SharePoint service providers. The SharePoint market is booming and this leads to the situation, that the number of qualified employees is very often not sufficient to implement all project requests. The situation is exacerbated by the fact that in many SharePoint projects, applications are still manually produced. Hardly any component will be used again, processes remain individual per employee. In addition, there are often only inadequate test methods in use. The task currently facing SharePoint development, is not new in its abstract form. As far back as in ancient times, people were faced with the need to tackle rising markets through parallelization and standardization. During the Industrial Revolution, new approaches and processes were strictly implemented. The best-known examples are the weaving mills in the England of the 18th century or the conveyor belts for the Tin Lizzy by Ford from the twenties of the last century. Although these developments were primary due to technical progress, general rethinking was also a factor, in regard to the totality of all processes as well as views on the consistency of the work steps that brought about efficient production. Figure 1: SharePoint Factory Framework

18 These exact approaches are able to address the current situation in the development of SharePoint applications to ensure consistency, end to end. Through the standardization and parallelization of all process stages from the analysis phase through to the roll out of SharePoint applications projects can escape the shackles of production. Within this SharePoint factory, concepts such as blended delivery, component manufacturing and centralization of core tasks can be implemented very well. The industrialized approach is suited due to its good scalability for large migration projects to SharePoint - for example, from SharePoint 2003/2007, Lotus Notes, or eroom - which involves the transfer of a wide variety of applications or databases. Complexity analysis and price clusters The starting point of each factory project is the analysis of the development or migration requirements of the applications in terms of its size and complexity. Particularly important to the valuation is how to implement all customer requirements in the target architecture of SharePoint. This factory is supported by proven and globally consistent processes, which escaped the shackles of production on both quantitative and qualitative factors right up to the roll-out of SharePoint applications. Within this SharePoint factory (fig. 1) concepts such as blended delivery and core functions can be compartmentalized and centralized particularly well in preparation for implementation. All standalone processes can be optimized so far within a factory, that they improve the quality of the results, reduce the lead time in the development phase and for customers, keep the costs as low as possible and transparent. The industrialized approach is suitable due to its good scalability, in particular for large migration projects to SharePoint. Following the analysis, the investigated applications can be classified into so-called complexity clusters: All applications that are reproduced within a given cluster, are reported at a uniform price to the customer for implementation. This pricing model applies equally to all other blocks of the factory approach. These include, for example, governance consulting, UI Development or roll-out support. Thus customers, especially in large SharePoint projects have a high level of planning security in relation to the total cost. Here are some examples of criteria that will be examined in the context of complexity analysis: Figure 2: TFS Structure

19 Quantitative: Qualitative: The volume data to be migrated The number of workflow steps The number of individual forms Necessary safety requirements The involvement of management The question of how critical an application is Structured Analysis Based on the complexity analysis, and based on templates, the technical concepts and functional specifications can be created. Special caution even in this planning phase makes it possible to ensure maximum reuse. For example the templates used include SharePoint Shapes, Workflow steps, and List and View templates. Figure 3: Bug Status The resulting consistency of deliverables facilitates quality assurance on one hand, and on the other, expert consultants sharing their project experience. One reason for this: the similarity of information lowers the coordination required between Requirements Analyst and the Developer significantly. The Factory concept requires the direct involvement of the Subject Matter Expert at this early stage of the project, to ensure that the least amount of coordination will be required during the development phase. This should also minimise project overrun. The use of templates and defined structures within the documents allows a virtually unlimited parallelization of the conception phase, allowing the lead time to be substantially reduced. Tooling is key Even in the classic industrialization the biggest leaps in productivity have been achieved through technological progress. In the SharePoint Factory in particular the Team Foundation Server 2010 or 2013 (TFS, Figure 2), quality assurance tools, such as Resharper or Microsoft s Test Manager suite are the drivers for productivity. They allow for efficient and time-critical application development. The centralization of all data and tasks reduces the possibility of information loss. This way, project managers have at all times a clear picture of the current status of the project. Due to the individual adaptation of TFS to the factory, it is possible to map the entire course of the project from the requirements specification for developers and their individual tasks to SharePoint specific test cases.

20 Despite the fact that most developers have their own individual favourite tools, at this point a unification of core development tools is necessary. Only when all developers use the same tools it is possible to implement development processes globally and thus allowing comparability along the Quality Gates. As part of SharePoint development, the topics Testing and Deployment prove to be particularly important. Both affect the duration of the implementation and success of the project. For this, the Factory cloud test environments are constructed within the framework, which replicate the customer environments exactly. Long before the first deployment within the customers environment, the testing of as many critical application functions and implementation processes as possible is carried out. Centralized execution of core tasks One of the advantages of industrialized SharePoint development is the option to outsource key tasks by similar processes. A central deployment competence center carries out customer independent deployment for all applications within the SharePoint factory framework. It ensures that the applications are consistently developed in the highest quality across different customer systems and can be implemented for all customers. At the heart of this approach is a structured, weekly deployment. With its help, problems can be identified and rectified early on. The outsourcing of tasks to a central team makes it easy to deliver applications and to install packages through the internal IT team efficiently while continuously providing improvements to a wide variety of customers. Testing as a core task One of the most neglected areas of SharePoint development is testing. As part of the SharePoint Factory however, it is two core aspects of the deployment competence center: through the principle of development-related testing, and also by integrating SharePoint standard test cases. The industrialized approach requires that the applications are deployed for a ramp-up phase in regular cycles, ideally weekly, in the corresponding (cloud) test environments to be tested there. It is important that during the development of test cases a logic operation is done with the requirements, so that the releases can be Requirement-based tested. However, the approach implies the implementation of all applicable test cases including regression testing. The second core aspect is an application-independent standard SharePoint test. It ensures that the standard functionality of SharePoint continues to function, but also that the tests aren t contrary to the overall purpose of the application. Testing as part of the SharePoint Factory is performed one hundred percent by the Test Manager suite of TFS. These very simple real-world test cases of customers can be integrated in all test runs at all.

21 Blended Delivery or Offshore Scaling For the implementation of large SharePoint projects such as the transformation of entire application landscapes, the SharePoint Factory offers the opportunity to work with distributed teams. Especially with high standardization, and defined Quality Gates as the interfaces between the individual process steps, and the templatebased delivery approach to help developers. This opens up the opportunity to integrate an offshore development team for various process steps. In particular, for development and testing. However, there are always some basic rules that are important to remember to ensure a successful integration of distributed teams (for more information see Sebastian Gerling and Stefanie Husslein: SharePoint ohne Grenzen, in SharePoint Magazin ): The establishment of a team onsite is mandatory Errors must be addressed openly this can range from bugs, process flaws, general issues, and personal mistakes The project setup phase should be implemented this ensures all team members understand their roles, objectives and client requirements Without project management, successful delivery is not achievable Communication is the essential to the success of the project Teamwork leads to success All are equal team members onshore and offshore A high level of detail in the specification is required Without an onshore SharePoint architect delivery is not achievable Not all components can be implemented offshore Some components will be handed over to the onshore team to develop Customer involvement throughout the entire course of the project In contrast to the classical industrialization, the customer is integrated as part of the SharePoint Factory stringently over the entire course of the project. The customer has to sign off on the creation of the concepts and use cases, they have to be involved when the first components are tested in the cloud test environments and of course in the final testing of all components to ensure that the applications that are developed by the factory meet the expectations of customer. Close coordination in the early stages of development to reduce the implementation time and effort at the end of the project is also key. This increases the chance that business users will accept the new application and the changes that come with it for them. Transparency through KPIs Using Team Foundation Server throughout the entire development cycle allows the team to automatically provide key performance indicators as readiness test cases or iteration completion to the customer. The Team Foundation Server reports and KPIs as well as the fact that the customer is involved in early testing of the components means that the customer always has an accurate overview of the current state of the project (Fig. 3). Conclusion With the SharePoint factory business applications build on top of the Microsoft SharePoint platform can be implemented in a scalable and efficient way, while potentially using the entire range of available functions and features. Customers can achieve cost savings and efficiency throughout the entire application life cycle by using the standardized processes and economies of scale that the SharePoint factory offers.

22 In particular, smaller business departments can implement their divisional needs alongside the Factory Framework easily and with less resources. For central IT departments, it is possible to provide SharePoint development as a standard service in the company, perhaps after a short warm-up period to ensure that the factory is running smoothly. Due to the focus on standardization and parallelization offshore resources can be used for the development of components in large SharePoint projects, which effectively reduces the required development time and costs while high quality in every development step can be ensured. If you would like to learn more please feel free to contact Lana or Sebastian.

23 Four shades of SharePoint 2013 web content publishing by Waldek Mastykarz SharePoint 2013 provides us with new web content publishing capabilities. Learn what those capabilities are and, what s more important, when each one of them offers you the most benefits. Hierarchical publishing With the release of Microsoft Office SharePoint Server 2007 Microsoft introduced web content management as a part of the SharePoint platform. Back then SharePoint would offer us a page-driven hierarchical content publishing model. Each content item would be created as a Publishing Page and its location in the site hierarchy would determine its location in the site s navigation and URL. In the hierarchical content publishing model pages are tightly coupled to the site s structure. As a result the site must be structured the way it should be displayed to the visitors. Because SharePoint doesn t support URL rewriting it s hard to reuse content within a site using the hierarchical publishing model. Another drawback of this model is the Site Collection-boundary: when aggregating content, only content stored within the current Site Collection can be included in the aggregation. Additionally, if a content manager wanted to publish a new press release, she would need to navigate to the exact location in the site where press releases are stored and create a new page there. In some situations such workflow led to a confusing content management process that made no sense from the organization perspective and which was enforced by the website s navigation hierarchy. Hierarchical publishing in SharePoint 2013 Since the introduction of web content management in SharePoint 2007 nothing has changed and the hierarchical publishing model is still available in SharePoint It still has the same benefits and drawbacks as in the previous versions of SharePoint. In fact, there are even more drawbacks to using it in SharePoint 2013 than there were in the past. SharePoint 2013 contains many new and improved capabilities for web content management and some of them, such as Friendly URLs, don t work when using hierarchical publishing. When does it make sense? In SharePoint 2013 it makes the most sense to use hierarchical publishing for configuring a separate authoring site for cross-site publishing. Content catalogs can be configured as separate sites and hierarchical navigation can be used to allow content managers to navigate between them. Because the authoring site is separated from where the content is published, hierarchical publishing can be perfectly leveraged to provide content managers with an authoring site structured in a way that makes sense to them. Search-driven publishing with in-site content One of the new content publishing models that SharePoint 2013 offers us is searchdriven publishing. When using search-driven publishing with in-site content, content is crawled by SharePoint 2013 Search and the information about crawled content is used for building dynamic content aggregations. Content pages themselves are rendered using the same publishing controls as in the traditional hierarchical publishing model. In the search-driven publishing model with in-site content, even though search is used to crawl and publish content, all content is stored within one Site Collection. The physical location of the content in the website doesn t matter as much as in the hierarchical publishing model. Search-driven publishing is often combined with Managed Navigation to model the navigation structure of the website for the visitors.

24 Benefits of using search-driven publishing with in-site content The first, and probably the most important, benefit of using search-driven publishing is, that almost all of the new web content management capabilities introduced with SharePoint 2013 are optimized, or even require, search-driven publishing. The contents of the XML sitemap for instance are gathered using a search query and, when working with Friendly URLs, content aggregations must be done using the new Content Search Web Part as the Content Query Web Part is capable of rendering physical URLs only. By using Managed Navigation in combination with search-driven publishing you can decouple the physical structure of your website from how the website will be presented to your visitors. As a result you will be able to model the structure of your navigation in a way which makes sense for your visitors and at the same time provide your content management team with a structure and workflow that allows them to work in the way they are already used to. Another important benefit, particularly for somewhat larger websites, is the scalability that the search-driven publishing model offers. SharePoint 2013 Search is built using the enterprise-class search technology, previously known as FAST, which can easily scale to handle the biggest loads and peaks you could imagine for your website. And even then it will still allow you to deliver the most relevant content to your visitors. This is great news if you need to publish a large website or need to deal with seasonal peaks for example. Using search-driven publishing truly offers you a myriad of new content publishing possibilities. By leveraging SharePoint 2013 Search you can for example analyze click behavior of your visitors and build rules around it to show them the most relevant content. This allows you to tailor the content of your website to the needs of your specific audience and increase the conversion rate on your website. Considerations for using search-driven publishing with in-site content Although search-driven publishing offers clear benefits, using it is not without consequences. Following are a few things that you should take into consideration before implementing search-driven publishing in your website. For content to be published through the search-driven publishing model it has to be crawled and indexed by SharePoint 2013 Search. Although you can configure the crawl process to occur as often as every minute, the publishing process will still not be instantaneous. There will always be a slight delay for your content to be published. And while a minute might not seem like much, there are some valid scenarios when you might require content to be published immediately and with search-driven publishing this simply cannot be guaranteed. When building content aggregations for content published using search you must use the new Content Search Web Part. By default this Web Part uses client-side rendering using JavaScript. Raw data, retrieved from SharePoint 2013 Search, is rendered in the page s source code from where it is processed and rendered in the browser. Because Internet search engines have limited capabilities for parsing JavaScript, Content Search Web Part automatically detects when an Internet search engine is crawling your website and uses XSL-based server-side rendering to render content aggregations. Unfortunately, by default, this results in different HTML markup to be rendered and additional effort is needed to ensure that Internet search engines will get the same semantic HTML delivered just as the HTML that your visitors will see. Figure 1 shows how the same page is rendered differently for visitors and Internet search engines.

25 Figure 1: SharePoint 2013 renders the same page differently for regular visitors and Internet search engines The search-driven content publishing model is built upon the enterprise-class SharePoint 2013 Search engine. If you have worked with previous versions of SharePoint you might have noticed the increased hardware requirements for SharePoint 2013 machines. SharePoint 2013 Search offers you great possibilities but for it to work correctly it needs properly sized hardware. When using search-driven publishing model, search is no longer the thing that people use when they look for something. On the contrary: some of the most prominent content on your website might be driven by search and you will want to ensure that it will not cause your website to be slow. In the past, when using the hierarchical content publishing model, all of the content was located in the content database of your website. In case of disaster recovery or testing all you needed to do was to back it up and restore it and your website was fully operational. When using search-driven publishing things become a little more complex as the settings and some of the content rendered on your website are stored in the Search Service Application. Only backing up the content database of your website is no longer sufficient to restore your website to its original state should things go wrong. When does it make sense? Microsoft suggests to consider the search-driven publishing model as the default model for building new websites in SharePoint After all search-driven publishing allows you to benefit of all the new web content management capabilities that SharePoint 2013 has to offer at a reasonable cost of additional impact to your farm s hardware. Given the flexibility of SharePoint 2013 Search you can use the search-driven content publishing model whether your website consists of only a few or a few thousand pages. It is a good starting point to consider search-driven publishing model for your website but you should keep in mind the additional hardware requirements and disaster recovery planning to ensure for a proper experience and continuity of your website. Search-driven publishing with in-site content makes the most sense for small to medium websites where all of the content is specific to that particular website and is not likely to be reused in other publishing channels. Cross-site publishing When using search-driven publishing you are no longer limited to having your content stored within one Site Collection only. In fact SharePoint 2013 allows you to easily publish content from one or more sources. Publishing content from other Site Collections in SharePoint 2013 is referred to as cross-site publishing, XSP for short. When using the cross-site publishing model all of the content is stored in one or more SharePoint Lists which are published as Catalogs. After the content from your Catalogs has been indexed it can be published on one or more websites by configuring a Catalog Connection. When connecting to a Catalog you can specify whether you want to rewrite the URL to make the Catalog content an integral part of your website or if you would prefer to point to its original location instead. The latter is useful

26 when you want to reuse content already published on another public-facing website and drive traffic to that website. Because SharePoint Lists are flat, to denote the hierarchy of the items, you need to use a single-choice Managed Metadata column. The value of that column will specify where in the hierarchy the specific item is located and will eventually determine where in the structure of the website this particular item will be rendered. When using cross-site publishing, content is stored outside of your Site Collection. Your Site Collection contains only Page Layouts and Template Pages used to display content from connected Catalogs and Search Results which specify how the external content should be retrieved. Figure 2 schematically illustrates how cross-site published content is rendered in a website. Figure 2: Rendering content publishing using cross-site publishing When publishing Catalogs SharePoint 2013 allows you to choose whether the contents should be available to anonymous users or not. This is an invaluable option if you want to for example publish content from your intranet to your public-facing website. Benefits of using cross-site publishing Cross-site publishing is a specific configuration of the search-driven publishing model. With that it offers you the same benefits as when using the search-driven publishing model with in-site content, such as scalability, behavioral targeting and leveraging the new web content management capabilities that SharePoint 2013 offers. Cross-site publishing has been designed for supporting content reuse. It allows you to republish the same content on multiple websites or even apps. Regardless of where the content is or will be published, as a content author all you need to take care of is the content itself and that it s tagged with the right hierarchy. Cross-site publishing offers content authors the benefits of item-centric content management which is often asked for in organizations where content authors and webmasters are separated and both are experts in their respective fields. With the cross-site content publishing model content authors focus on managing content items and webmasters control how that content is presented on the web. When managing multiple websites it can be cumbersome to manage content spread across the different websites. With cross-site publishing you could redesign the architecture of your publishing landscape and choose for a centralized authoring environment where content managers could maintain the content of the different websites. An example of such scenario is maintaining a multilingual website where Variations are used to manage multilingual content and the content itself is published on separate language-specific Site Collections using country-code top level domains.

27 Things to take into consideration When using cross-site publishing, content is stored in Catalogs in a Site Collection other than where it s published. When Catalogs are indexed only the content itself is included in the search index. Binaries, such as documents and images, that the content is referencing, are not, and when publishing content you have to ensure that those assets are located in a place accessible to whomever might access the published content. This is extremely important in scenarios where you choose to publish content from the intranet, which isn t available to anonymous users, on your public-facing website. Another consequence of the fact that the content is published from the search index, is that Web Parts placed in the Rich Text Editor will not be rendered. Web Parts are associated with the physical content item stored in another site, and are not a part of the search index, and will therefore not be rendered when the particular content item is published. This is important when working with content items that might require rendering forms or multimedia. A common pitfall, particularly when starting with cross-site publishing, is defining the information architecture of catalog content in a way that it resembles the navigation of the website where it will be published. As a result you will get reusable content which is tightly coupled to one specific website and cannot be reused on other publishing channels that might be using a different navigation structure. Defining a proper and future-proof information architecture for content catalogs is probably one of the biggest challenges for organizations that have previously worked with page-oriented content management systems. Cross-site publishing with content catalogs is an item-centric content publishing model. Content managers responsible for catalog content ideally would need to focus on producing and maintaining content that can be reused across the variety of publishing channels an organization uses and might be using in the future. With the diversity of publishing possibilities this introduces, it is challenging for content authors to verify if their content will be published correctly on all publishing channels. Providing them with proper tools, that allow them to preview their content on the different publishing channels prior to publishing it, as well as guidelines, to ensure that the rich content is styled consistently across all channels, is essential for this content publishing model to be used effectively. When does it make sense? The key element of cross-site publishing are content catalogs: SharePoint Lists with a particular type of content such as products, press releases or blog posts. Whenever you are publishing a significant amount of content that could be reused across other channels, you should consider leveraging content catalogs. Even though you might not be needing them today, you might be needing them tomorrow and investing in the ability to leverage them in the future allows you to rapidly respond to market by for example launching microsites and campaigns. Cross-site publishing makes the most sense for websites that focus on publishing content from catalogs with no website-specific content. Topic-sites, microsites or campaign sites are just a few examples of sites that can benefit of this content publishing model. Having all of the content stored in a central location you can quickly launch a new website publishing its contents from one or more catalogs. Hybrid search-driven publishing When building real-life public-facing websites you will regularly see that neither search-driven publishing with in-site content nor cross-site publishing fully fulfills your requirements. Often, what you need is a combination of both approaches where generic content, such as press releases or blog posts, is published using cross-site publishing and is mixed with content specific to the website which is stored within that particular website.

28 Benefits of using hybrid search-driven publishing By combining cross-site publishing and search-driven publishing with in-site content you get the benefits of both approaches. On one hand the combination allows you to centrally manage generic content and reuse it across the variety of publishing channels that your organization might be leveraging. At the same time content managers of each publishing channel can control how the generic content is published within their channel and enrich it with additional content relevant to that particular channel. Things to take into consideration The biggest challenge when combining in-site content with content published from catalogs using cross-site publishing is integrating the external content into the navigation hierarchy of the website to provide visitors with a seamless browsing experience. When connecting to content catalogs SharePoint 2013 allows you to choose where in the navigation of the current website the external content should be placed. This location determines the placement in the menus and URL structure of the connected content and should therefore be chosen wisely. Another important thing that you should keep in mind when planning for publishing content from catalogs, is that one website can have only one connection to the same catalog and the content from that catalog can be placed in only one location in the website. This might be limiting when you need to display the content from catalogs in multiple places in your site, for example when connecting to a catalog of medical professionals and displaying them in the context of the department they work in rather than publishing a complete list of professionals that can be filtered by department. When using the hybrid search-driven publishing model some of the content of your website is managed within that particular website and some of it is managed in external content catalogs located somewhere within your publishing landscape. If content managers responsible for the content of the website are also responsible for the content of one or more catalogs, it might be confusing for them to deal with the two roles that they have and the multiple locations they need to go to in order to manage the particular type of content. In such cases you should provide those users with proper training and tools to allow them to do their work efficiently. Another consequence of mixing in-site and external content within one website is the additional complexity in tracing the origin of the published content should it need to be changed. Without proper governance it might be challenging to trace the particular piece of content back to its source and who should be contacted to apply the necessary changes. When does it make sense? The hybrid search-driven publishing approach offers the most flexibility and is therefore the content publishing model you are most likely to use when building medium to large real-life public-facing websites with SharePoint Summary SharePoint 2013 provides us with new content publishing models, each of them having its own benefits and things to take into consideration. Which one you can best use depends a lot on your particular scenario. Despite which model or combination of models you will use, it is essential that you understand the consequences of your choice and the impact it might have on how your organization publishes and managed its web content.

29 SharePoint Applification by Albert-Jan Schot Over the course of the last few years the term App became somewhat hyped and overused, since every self-respecting mobile platform introduced them around The apps as we know them are distributed through a central platform and until around a year ago these were mainly focused on mobile devices. Yet with Windows 8 and SharePoint 2013 apps are introduced into these fields as well. Now with SharePoint 2013 Microsoft introduces the App Model as mini applications that extend what you can do with the new version of Office and SharePoint When the App model got introduced it introduced some challenges, and as with all new techniques the question should be what the strengths and weaknesses of the App model are and when it should be used and when another approach might be more suitable. As there are plenty of articles out there debating on whether and when you should use the app model (or not), we should focus on another point of view. Let s assume we are running Office 365 and thus cannot run full trust solutions, and our only options are sandboxed solutions or apps. A common misconception is that people think that sandboxed solutions are deprecated completely, however only the use of user code, or code behind in sandboxed solutions is deprecated. Sandboxed solutions that contains only declarative stuff are still is fully supported and will be for the foreseeable future. In a number of scenarios this approach is even preferable over doing everything in an app. If you are running an intranet solution on Office 365, there are two common things that you will have to do: Create a structure that fits your organization Create functionality that s just not there out of the box Creating a structure that fits your organization can be something that is done as a onetime setup, yet in most cases you will have somewhat of a moving target; in a healthy organization new projects are launched, new clients are won and even sometimes lost. So you might want to create a structure that is flexible enough to accommodate some sort of change. Webs, Sites and your sandbox To make sure you can both make sure that you have a flexible environment and have some structure, you should use web templates. Web templates can be used to create either new site collections or sub sites, so whether you are creating a new project, client or whatever unit you are using to create your structure on web templates should be at the top of the list. Luckily web templates can be created declarative in sandboxed solutions. Yet the downside is that not everything you might want to do in your web template is supported the declarative way. The most common things that you will likely encounter that cannot be done the declarative way are: Configuration of permissions and permission masks Removal of default Content Type Bindings Setting a Portal Site Connection in case you are working with multiple site collections In order to fix these gaps that you are left with creating a declarative sandboxed solution you can take a look into the app model. As the app model allows you to manage settings and configurations in sites and site collections in your live environment.

30 So let s break things down, in order to create a new site collection (or sub site) based on a template you will need the following: A declarative version of your web template CSOM version of the code to do the things you cannot do declarative An app that creates your site collection or sub site and applies your template to it, and then executes the code that does the configuration that you need on the site The app you are creating will need to have full tenant permissions, and thus cannot be deployed to the Office Store. If you created the app with the proper permissions you can consider whether you will need to create site collections or not. If you do not need site collections you can just upload your sandboxed solution to the proper location and you can create sub sites based on that template. If you are creating a new site collection you will need to upload that sandboxed solution before you can apply the template itself. The app itself would be a full immersive app or a client app. A full immersive app allows you to run everything from the browser, something that would be preferable over a client app that you would need to install, so I would stick with a full immersive app. Also if you are planning to create site collections through the app model you should have a look at a blog by Richard DiZergas on using the Self-Service Site Provisioning: Note that this approach only works if you are in a multi-tenant environment like Office 365. If you are creating a new site collection you can use Tenant.CreateSite method as pointed out on MSDN, the thing is you will have to make a slight change by not passing the sitetemplate and thus having to pick one later, so to create a site your method should look something like the example in Listing 1. Listing 1: Create a site collection in a tenant without selecting a site template

31 After you created the site collection you can now upload the desired sandboxed solution(s) to this site using the snippet in Listing 2. One of the solutions should contain your web template since we cannot apply the template before we uploaded and activated it. Listing 2: Upload and activate sandboxed solutions on a site collection Activating sandboxed solutions is a bit tricky since there is no way you can do that through the object model. The only way you can do so is through faking a web request and providing the proper details to that web request to activate the sandboxed solution. As that might be something that will not be quite future proof you might opt for creating a window in your app where you just show the solution gallery and ask the user that creates the new site collection to upload and activate the solution manually. As Waldek Mastykarz pointed out in his blog you will have to disable the Access App Site Feature in order to activate a sandboxed solution. If the sandboxed solution is activated you can either let the user also choose the template, or just use some code to actually apply the template: Listing 3: Applying a web template to an existing site Then after the site collection (or your sub site) is created the easy part starts, doing the stuff you can t do declaratively. There is just one downside and that is that setting the portal site connection is not something you can do using the CSOM, the other things are fairly easy. The app is probably running not on the web you just created, so make sure you either redirect there and retrieve the renewed context, or just create a new context yourself. Once you have the correct context you can just use the CSOM model to create, delete and configure the things you couldn t do the declarative way. Listing 4: Granting All Authenticated Users read permission on the web

32 Listing 5: Breaking permission inheritance on a list Listing 6: Deleting the default document Content Type from a list As you can see these steps are fairly easy and allow for great and flexible templates that can be used to create the sites and sub sites the way they are required, and achieve almost everything that you would like to do in a template, declarative or not. Keep in mind though that these things should always be done after applying your template to make sure the lists, libraries and other settings that your code requires are available. App Parts vs Web Parts Most of the Web Parts that you will create in a typical intranet solution will contain custom code. Since user code is no longer supported in sandboxed solutions you should not use this approach to create Web Parts anymore. If you are creating declarative Web Parts using out of the out of the box Web Parts you are fine, but once you need to write custom code you will have to resort to App Parts. App Parts will work slightly different from a normal Web Part since they will render an iframe that will contain the page running your app instead of rendering it directly on the page. If you are working with these App Parts you will quickly figure out that they are not that different from Web Parts, except for a few things: You will probably write them in JavaScript The web the app is running is a different web than the web that contains the page that you are requesting You can end up with lots of Working on it messages on your page Writing Apps can be done using CSOM but most of the times you will write SharePoint hosted apps for the quick-wins that you might encounter on your intranet. Creating SharePoint hosted apps means that you will create declarative solutions, or that your will write your code in JavaScript. You can still write your apps in CSOM but that means you will have to either create provider hosted apps or auto-hosted apps. Once you have taken that hurdle of picking the best app type for your solution, you can move on and think about the relation between your page and the iframe you are running your app in. As pointed out the app will run in a different web and there will be an iframe to show your app on the desired page. If you have more than one app running on your page you will see multiple Working on it messages, making the page look slow. Luckily there is a way to communicate with the parent from within the iframe, by using the window.parent.postmessage. This method allows you to pass data from your App Part to the parent, allowing us to notify our parent web once the iframe is loaded. That way we can hide the iframe and its contents until everything is present, keeping the user from seeing the loading screen. You can even extend

33 your parent to then pass the data to another app so that you can link different apps together. To hide the App Part while it is loading to avoid the clutter of working on it message you can just set the width and height of the App Part to zero so that it will be invisible. Once the App Part is loaded you can post a message telling your parent to show / resize the App Part from inside the App itself. All you need to resize the app is the senderid, something that is passed through to your app by default, if you pass the default parameters, or can be configured manually. If you would make it configurable you can link different apps together and send messages between different apps making them look connected. If you retrieve it from your URL you will use the ID of the app itself as shown in listing 7. Listing 7: Resizing the App Part Other than that creating App Parts is easy, also compared to creating Web Parts. While some options will work a bit different in JavaScript than you might have been used to most of things are still possible, although it might require a bit of time and patience to figure out the details. You can still use the context of the web your app is running in to retrieve data, or use the context of the web to store and process data. Conclusion SharePoint Apps are happening, and will shape the future of the product as we know it. There are different ways to implement apps in your environment and there is still a valid case for implementing declarative sandboxed solutions into your environment. You can leverage apps to achieve more (especially if you are running Office 365) and once you are using them you will find out that the basic concept hasn t changed that much. You are still able to retrieve data either with the users credentials or with a form of permission elevation. There has been a shift towards writing JavaScript over server side code, and you will have to get used to that, but you can also still use the CSOM. The CSOM will look very familiar if you are used to writing C# to create your SharePoint solutions, but even the JavaScript object model is relatively similar. Whenever you are creating an Intranet solution you should look into building a full immersive app that allows you to setup your structure using web templates for everything that can be done declarative and use your app to enrich and configure your site or sub sites with everything else you need. An app can also come in handy to display or manipulate information or settings by using App Parts. App Parts serve mostly the same purpose as the good old Web Parts. If you are using Office 365 building App Parts should be your solution of choice as that is the more sustainable solution now that using custom code in sandboxed solutions is deprecated.


35 SharePoint and Windows Phone: Get social with apps by Eelco Vink News. We want to be updated on the latest changes every day. Perhaps every minute. We check our Facebook, Twitter, LinkedIn to dive into the latest news on friends, colleagues, companies, what is happening in the world etc. The information stream in SharePoint 2013 has changed significantly compared to SharePoint The changes to the discussion board, the added and improved functionality of the Newsfeed, and the fact that Microsoft bought Yammer. Social is the word. But if you say social these days, you are also saying mobility. People want to let each other know what they are doing, whether it is checking in on Foursquare, posting a picture of a concert you are currently attending, or posting an update about a project you are currently working on. It is all about receiving and sending information. What options do we currently have for Social mobility? How can we keep in touch on the go with the latest news and information? In DIWUG emagazines 8 and 10 of 2013 the articles Social in SharePoint Online 2013 and SharePoint, Yammer and the social landscape provided information about the current Social possibilities and Yammer. This article will focus on mobile phone capabilities of SharePoint Social and Yammer. Windows Phone is becoming more and more popular every day. Because of that I focused on the free social apps available for that phone. Since social and mobility are often used together and both very popular, I was curious about the Windows Phone apps for SharePoint Social features. I came across 2 free apps: SharePoint Newsfeed Yammer The apps described in this article are all Windows Phone 8 apps. The look and feel of these apps on ios and Android devices will likely be different. Both Apps require cellular data if you are not connected to Wi-Fi. SharePoint Newsfeed App The SharePoint Newsfeed App is one of the apps you can use on your mobile device to keep updated on people, documents and tags. In this chapter I ll show some of the details of the SharePoint Newsfeed App. The SharePoint Newsfeed App is available on the following devices: Windows Phone - 4fef-8b2a-290e86c3e8c7 iphone, ipad, ipod (minimal ios 6.0) - https://itunes.apple.com/nl/app/yammer/ id ?mt=8 Windows 8 -

36 To be able to use the SharePoint Newsfeed App, you must have a personal site set up in SharePoint Server 2013 or SharePoint Online. Now you see me on the phone Let s get started with the SharePoint Newsfeed App. Once you are logged in, you will start at the following screen that is shown in Figure 1. On this screen you will see an overview your news and knowledge updates. The screen will show all newsfeed items from people, sites, documents and hashtags that you are following. Other options that you can access through this screen are: The ability to start or stop following hashtags The ability to start or stop following people The ability to like or unlike a message The ability to reply to a message The ability to create a new message Figure 1: Start screen: Following

37 One thing that is noticeable on following screen is that it only shows the notifications of the last 5 days. For example if a notification is created on December 19 it will no longer be visible on December 23. The same thing applies to the everyone page. On the mentions page however it seems that notifications will be displayed for a longer period of time. Just compare figures 1 and 2 to see the difference. Figure 2: Start screen: History Changing views When you open the app you will start out on the All newsfeeds view of the following page. Pressing the All newsfeeds text in the upper left section of the screen will show you views of sites that you are currently following. This is shown in figure 3. Selecting a view brings you back to the following screen and will display the feeds from the site that you selected. From this screen you can create a new post like in figure 4, which will be posted to the selected site. Anyone following the site s promoted links will receive an update on their newsfeed and can like the post and comment on it from their mobile device or browser respectively.

38 Figure 3: Views: Followed sites Figure 4: Views: Creating a post

39 It s about you.. Or, technically, it s about me in this case. Although not my me, but your me (yes that does sound confusing). If you go to the me section of the app, shown in figure 5, you will see some basic information about yourself, the people you are currently following, the documents you are following/are connected via SkyDrive Pro and the tags you recently used and are following. Figure 5: Me: It is about you

40 ... and everyone else In the Everyone section, shown in figure 6, you can find information that is shared with everyone. This means that if someone publishes a post and targets it at everyone that you will see this post on the everyone page, even if you do not follow this person. Creating a post in this section will automatically post the message to Everyone. Of course you can change who you want to share your update with by simply pressing [Everyone] in the Share with section. This will give you the option to select a site you are following to post your message to. Figure 6: Everyone else: It matters Yammer: The app So far we ve focused on the SharePoint social features, but this discussion is not complete without Yammer. Yammer is not a 100% integrated SharePoint feature, however the integration is getting better and tighter. The integration is only about visualization though, the Yammer data is still all stored in the cloud on the Yammer servers. This won t change in the foreseeable future. The integration options are getting more extensive though and Yammer will more and more start to look like part of SharePoint, especially on SharePoint Online. With the Yammer app, you can view your organization s enterprise Yammer network as well as external Yammer networks. For more on Yammer please visit this website: https://about.yammer.com/.

41 The Yammer app is available on most frequently used devices: Windows Phone - iphone, ipad, ipod (minimal ios 6.0) - https://itunes.apple.com/us/app/ sharepoint-newsfeed/id ?mt=8 Windows 8 - Android Devices - https://play.google.com/store/apps/details?id=com.yammer. v1&hl=en My feed When opening your Yammer App, you end up in the network you have last visited. The screen will automatically start in the my feed section. This section is shown in figure 7. The My feed section starts out in the All Company group, which is the default group. Figure 7: My feed: Point of entry

42 Let s have a look at what other options we have in this screen? We have: The ability to view a post s full content (by clicking on it); The ability to create a new post; The ability to refresh the content that is shown on the screen. Figure 8: My feed: Creating a post

43 To create a new post from this section you can simply click the + icon. Figure 8 shows the page that is used to create the post. The post will be targeted at the All Company group. You can even attach pictures by clicking the camera icon. If you want to mention people, you simply press and you will get a list of all the people in the network to choose from. The downside of this behavior is that you cannot post an -address, because you will be automatically redirected to the network s people list. One thing that is very different from the SharePoint Newsfeed app is that you can see as many items as you want from your timeline. If you scroll down you will see a load more button. If you click this it will load more messages. This is great if you want to view previous messages on your phone. It means that you don t have to go back to your desktop, open your browser and Yammer network and look for archived messages you can just load them on your phone. This section can be improved and made easier to navigate by adding a search option. Inbox The inbox is your personal Yammer inbox, which in many ways is a bit like your inbox as you can see in figure 9. You can send Yammer messages from here to either an individual or to multiple people. In the unread section you can see messages that have been directed at you (direct messages or replies) that you haven t read yet. The read section displays messages you already read. From both sections you can create a new personal message. Figure 9: Inbox: Much like sending an

44 The notification section displays notifications like: Notifications Who a new follower is; Who liked your post; It is good to know who is following you so you can follow him or her in return or you can see who has liked your posts. Very straightforward really. What Groups are you in? Groups are not to be confused with networks. A network for example is, Your Company Network, SharePoint Business User Group, SPYam etc. To see which network you are in, check the upper left corner next to the Yammer logo. Groups are sections in your network. For example the User Adoption group in the SharePoint Business User Group network. These groups or sections are aimed at knowledge and information sharing about a specific subject. This is great if you want to follow some, but not all groups of a network. When you click on groups you will get an overview of the groups that are available to you in the network that you are in. Figure 10 shows the Groups screen. If you click a group, you will see posts that where targeted at that group. Figure 10: Groups: Which are you in?

45 People This is what builds a (social) community, the people. The other people in the community might provide you with the information you are looking for, or they might have the knowledge that you require to get a job done. The people in a community together generate the never ending stream of information. You can compare this to your personal Facebook or Twitter network. If you are planning on buying something for instance you might ask the people in your network for recommendations to gain specific knowledge, but even if you don t ask any questions there is a constant information flow. The people section displays everyone who is part of the network you are currently visiting. Meaning if you are in the SharePoint Business User Group network, you will see everyone that is a member of this network. Figure 11: People: Newspaper icon Figure 12: People: The foundation of a good social network

46 When you click a person you can view some information. The information that is being displayed here depends on what you filled in on your profile. See it as a short summary about you a really short one. You can see how many followers someone has and how many people he or she is following. When you click the newspaper icon that is shown in figure 11 you are directed to an overview of posts that he or she has either commented on or liked. Figure 11 also shows the + button again. You can use this button to create a personal message that is directed directly at the person whose profile you are currently viewing. Conclusion The SharePoint Newsfeed app and Yammer app for Windows Phone are both great apps. I hope this article has inspired you to try these apps out if you hadn t already. As Yammer is not fully integrated with SharePoint yet (especially with on premises environments), having the SharePoint Newsfeed app is great to keep in touch with everything that is happening with regards to documents and social in your SharePoint environment. Depending on your device, the SharePoint Newsfeed is a great app to have in your collection. While the Yammer app does lack some features like the ability to see and click on tags that where added in a post (from the browser) or for example the ability to search for specific posts, it does win in the social aspect. Yammer can go beyond your company network and lets you keep in touch with people both inside and outside of your organization. Looking for an enterprise social app in the cloud? Then this might be the right app for you. DIWUG Event Inter Access - Hilversum 2014 Jan. 20 History Bas Lijten - Achmea Interpolis on Building SharePoint 2013 apps with Visual Studio 2013

47 SharePoint 2013: The key to successful migration by Fabrice Di Giulio Microsoft SharePoint 2013 introduces a number of innovative new features which could lead you to rethink your Intranet and the integration of the social and collaborative functionality inherent in the platform. Enhanced features include improved management of collaborative work functions, the native integration of real enterprise social network functions (of which Yammer will soon be available), the possibility of Marketplace implementation and potential internal development chargebacks, as well as a significant improvement of search-related functions. However, migrating to SharePoint 2013 (either on-premises or SharePoint Online) requires an in-depth study of the current environment in order to identify all the critical points to take into consideration. Figure 1: Migrating for a variety of source systems to SharePoint 2013 There are many collaborative environments, EDM, and Intranet solutions, all of which possess their own specific functions. Technical constraints can also complicate the migration process. The first question that you should ask yourself is this: Is it even possible to migrate to SharePoint 2013? A migration is often considered to be a normal project, or even a simple maintenance operation, especially if the migration is an upgrade from one version of a product to the next version. Migrations are not simple or easy though, every migration is different and there are always surprises. To minimize the surprises it is important that you undertake a comprehensive audit of your current environment in order to identify the pitfalls which, if forgotten, could drag out the project planning. In this article, I shall therefore focus on the questions that in my opinion and based on the concrete cases that I ve dealt with, should be answered pre-migration. What is the state of your current collaboration platform deployment? It s always difficult to gain a complete understanding of the current situation of an environment before a migration. In most cases, when reviewing an existing environment it is easy to jump right into reviewing the content. While the content is an important element that needs to be reviewed before the migration, it s not the only one. Before you start migrating you should make sure that you have a good overview

48 of the corpus of documents, but also of the entire environment, including network and hardware infrastructure, user mapping, security directory and implementation, and interactions with other systems (e.g. CRM, ERP, EDM). It can be very challenging to get a complete overview of the environment. Involving people that work on the existing environment in different roles can help to get a good overview, as well as identify which people should be involved in the different stages of the migration project. The following are all areas that you should focus on as part of the initial assessment of the environment: Comparing the existing infrastructure hardware, network, software and the infrastructure that is required to run SharePoint 2013, as well as the size of the environment, and its geographical scope, can help drive decisions on whether the existing infrastructure will be reused, or whether a new platform will have to be created. The migration can also be an opportunity to increase the security level of the environment by changing the type of authentication that is used. SharePoint 2013 uses claims authentication as the default, if the existing environment uses Windows authentication this should be changed to claims either before or after the upgrade. Gaining an accurate account of the active users can be help drive decisions as well: I have often been faced with environments (SharePoint or LiveLink) on which several thousand users were enabled or registered, but only a small percentage actively used the environment. Knowing how many active users there are on the environment will help size the target architecture. The information about the ratio between the registered users and active users can also help guide the choice for the type of target environment: choosing Office 365 and being billed per user, or an on-premises environment where the license allowing each user to access SharePoint will need to be purchased. Information about active users will also help to define whether users should have the same permission level they had before the migration or not. Does structuring the company directory help to meet technical/business needs? I encountered this specific case on a global Intranet project, for which the directory structure did not allow identification of the geographical location of a user as a result of a decentralized architecture. If that information is relevant to the solution it can be important to restructure the directory in order to be able to take full advantage of SharePoint Still on the subject of the directory, identifying the deactivated and deleted user accounts before migration would help you to avoid performance problems when searching for user mappings during the migration or even preventing migration of parts of the content completely.

49 How much content needs to be migrated? Answering this question means accounting for all existing content residing in your current environment, bearing in mind that this concerns not only documents but also images, pages, and the number of versions for each of these objects. The content hosted on external file servers that will be migrated into the SharePoint environment must also be taken into consideration. Once you clearly understand the total amount of content you re hosting, it will help you not only to properly size your destination environment, but also to define an appropriate migration strategy that will answer the following questions: Should all the information and content be migrated? Do we need to purge part of the content before migrating? Should an archive strategy be implemented? Should an offloading content strategy via RBS be implemented? There are other factors involved in the decision on how much content should be migrated, such as: the duration of the migration, the allowed platform downtime, and the risks of failure. What is the level of customization in your source environment? This question is particularly relevant for a migration from a previous SharePoint version to SharePoint 2013 or SharePoint Online. Migrations from uncustomized SharePoint environments to SharePoint 2013 or SharePoint Online can be done using standard features or third party tooling. However if an environment is heavily customized the migration will be a customized one as well. First of all, we need to identify the different types of customizations. For example, graphic customizations (HTML, CSS) are difficult to migrate because the page structure in SharePoint 2013 is completely different; these types of customizations should be investigated separately, preferably together with someone who created them, or who at least knows what the business case(s) behind the customizations was(were). If the customizations still represent business value they can probably be created for SharePoint 2013, a migration tool or technical support can help to migrate and convert or recreate them. Next, we need to establish whether the customizations are still relevant after migrating to SharePoint Does the customization still solve a business need and does solving the business need still require a customization, or can it maybe be solved using new out of the box SharePoint 2013 functionality. If there is no business need to keep the customization, or if there is no business need for the customization anymore we might be able to discard the customization, either before or after the upgrade, depending on the type of customization. For example: Are workflows used in the source environment? This is an important type of customization to review as it might block or at least complicate the migration. If the source environment is SharePoint 2010 and SharePoint 2010 workflows are used in the environment, the workflows can be migrated to SharePoint SharePoint 2013 provides a compatibility mode for SharePoint 2010 workflows. However, Microsoft Office SharePoint Server 2007 workflows are incompatible with SharePoint Another thing that you need to examine is whether workflows provided by thirdparty editors are used and whether any non-sharepoint workflow environments are already in place? If other workflow tooling is used you will have to find out if a SharePoint 2013 version of that tool is already available and what the steps are to upgrade existing workflows to their SharePoint 2013 equivalent.

50 What is the level of technical requirements necessary for migration? In general, the technical requirements are not an issue once the auditing of the current environment has been carried out. However, the level of functional requirements will often impact the duration of the pre-migration study phase (especially if several business players are involved). One of the business requirements that I have encountered the most during migration projects is the requirement to restructure the data during the migration. Based on my experience it is difficult to reach a consensus within the business and IT about what the new structure should be exactly. Seeing as third-party tools can help to restructure the data after the migration it might be interesting to raise this point and manage it as an annex project. Another requirement is the level of fidelity of the migrated data. What is the fidelity of data? First of all, we should address the content-specific items such as language, the characters used in the file name, the different metadata managed by a source system, and the security settings on a document. Then, we should address these items as they are applied to entire directories, sites, and libraries. The need for full fidelity of this data may not be an issue when migrating from a previous version of SharePoint or a Microsoft file system to SharePoint However, it may be a complicating factor in a migration from any other system to SharePoint For example, if you are migrating from Lotus Notes the Author and Reader fields, if they are filled in, determine which permissions the users mentioned in there will have on the content. There are no exact functional or technical equivalents of these fields in SharePoint. However the functionality that these fields provide can be reproduced using different solutions, either out of the box or using a customization. When looking at the possible solutions you should consider whether a creating a solution is really necessary and cost effective, or whether content metadata, and/or security should be left out of scope for the migration. What is the expected type of migration? There are several ways to go about a migration: Full migration from the old system to the new system In this scenario, everything is switched over in one go. The old system will be shut down once the new one is online. This implies that sufficient tests have been completed for validating all the points of the migration project, before the full changeover is performed with minimal impact on the users. User groups sharing the same content will be migrated successively In this scenario, a full migration is applied to different sections of the source environment. For example: site collections, sites, or possibly libraries that are being migrated successively can minimize the migration time by isolating scopes. Incremental migration In this scenario, the first full migration will be carried out for resetting and validating the target environment. However, the users continue to work on the source environment. An incremental migration takes place regularly to synchronize the content on the target environment. Once this is validated and the users are trained, a final incremental migration enables the permanent changeover. There is no right or wrong migration approach as every project is different and the type of migration must be chosen according to the different requirements and environment specifics (e.g. data volume, complexity of migration, level of training for users).

51 How much platform downtime is acceptable? This may seem like a simple question, but it will heavily impact the migration strategy: How much downtime is acceptable for the source and target platforms? Beyond the downtime, it is also necessary to take possible performance degradation of the environments and locks on the databases into account. What are the human resources and hardware requirements? In general, during the migration project, sufficient time and energy is spend on properly sizing the target SharePoint farm and its infrastructure. However the staffing of the project often gets overlooked. Do the teams that will be responsible for the migration project have enough resources, time and the proper skills and equipment? Should a dedicated team set up for the migration project? Should we set up special training sessions for the project team members? The time spent on the validation the results of a migration can be considerable, particularly if errors or deficiencies are found. One particular case that I encountered when migrating from SharePoint 2003 to SharePoint 2010 was that while moving several hundred thousand documents to the destination environment, the contents of two critical metadata columns had come across. Both columns were empty after the migration. Because if was extremely difficult to script filling these columns with the proper values three people were assigned to complete this task manually. How should I migrate? There are many ways of migrating to SharePoint, so please keep in mind there is no single right approach as every migration is difficult with its own challenges and opportunities. Manual migration The simplest but, in my experience, least user-friendly migration method is to configure the target environment manually and then download the content to the target environment via native SharePoint features. One of the advantages of this process is that there are no additional costs for creating a script or buying a third party tool. It requires one or more trained people who are familiar with SharePoint administration functionality to setup the target environment and copy the data across. It can also be the only viable option in certain specific cases (for example, intranet site accessible in HTML format without content management). However, it is still very cumbersome and constraining, especially for the migration of multiple files including their specific metadata and security settings. Scripted Migration Scripting the migration, ideally with Windows PowerShell, provides full access to SharePoint features. This method also permits you to use resource or configuration files to carry out batch import, initialize metadata, and run SharePoint configuration operations. This option has very few technical limitations and can support large migrations. However, in my opinion, it has some disadvantages now that the market for thirdparty tools is mature; the main issue being the skill level required to develop the scripts is significant. It is difficult to find a person who has high expertise in both SharePoint and PowerShell, and even more difficult to keep them. The next issue is that the development and maintenance costs of the scripts are high. Finally, like in any development process, developing your own scripts means that you will have to go through specification, test, build and deployment phases and that you have to document them all of which can be time consuming and resource intensive.

52 Use of a Third-Party Migration Tool Disregarding the option of using third-party tools is high amongst the top 10 errors made in a migration SharePoint project. The development of a specific migration tool is time consuming, time that the third party vendors have already spent on creating generic solutions. Because of the generic dimension of these solutions, they go through rigorous testing and validation which provides a higher reliability than creating a custom solution. Finally, developing a migration solution usually means you are creating a solution that will only be used once. In most cases this might not be the best use of company time and money. Tools that cover most of the requirements that were identified during the pre-migration study should be tested. You might need features like content externalization, archiving, automatic classification, security management, content reorganization, and the actual migration. Depending on your needs, using one or more products can be very helpful and make the migration quicker and more reliable. Preferably you would only use one tool of course, as all tools will come at a cost. Conclusion In order to successfully complete a migration project, there are many options, approaches and settings to consider. Unfortunately there are still many migration projects that are started without proper preparation and resources. This can lead to key issues being overlooked completely or only being identified after the migration has started. Migrating to SharePoint 2013 is not trivial and should not be considered as just a maintenance operation (even if you are migrating from a previous SharePoint version). In this article, I have tried to give you some key questions that can help you start the fact finding necessary before carrying out migration projects successfully. This list is, of course, not a complete one and it should be adapted to each specific project. Even if a migration appears to be simple (for example when migrating from SharePoint 2010 to SharePoint 2013). Finally, third-party tools can prove to be very valuable in allowing you to automate all or a part of the migration: content movement/reorganization, data, user or permission mapping, data externalization, external file server connection, and more. It s well worth to investate the use of third party tooling for your migration. Thanks to Laura Dudney for review and translation

53 Building data driven applications using LightSwitch by Rainier van Slingerlandt SharePoint is a great and very successful product. This success comes for a big part from offering an extensible platform. Even though it is extensible, most projects start out with the statement of no-custom coding. The reason for this is that custom code could introduce errors, custom coding can take a long time and until recently, custom code had the potential to break the SharePoint farm. All valid arguments to keep away from custom coding and still, we are the most creative being in this world and we want to make things. Having the drive to create and improve is a part of the human evolution, it s in our blood. More than that, it s the number one reason we got this far in the first place. LightSwitch helps to bring a little peace between our nature and our reasonable thinking. It does so by generating code, we just tell it what to generate and it will generate error free code for us. Better yet, it only takes a couple of minutes and the result won t bring down your farm. What is LightSwitch LightSwitch is a code generator and has the sole purpose of increasing the productivity of the developer. The nature of code generators is that they are only effective if they target a small and very specific domain. In this case the domain is Web based, data-driven applications. LightSwitch will generate Web interfaces and data access code for the most common of tasks. It will generate code for getting list items, creating new list items, updating existing ones and removing the ones that are no longer necessary. We are talking SharePoint list items so all actions will take place on SharePoint lists. This is important to remember and different from what Access Services does. Where Access Services creates a new database that runs outside of SharePoint. LightSwitch will store everything in SharePoint, in a SharePoint content database. Thus with that all SharePoint goodness comes along. The data is indexed by default, without taking additional actions, the data can be found using SharePoint search. All SharePoint list events will trigger as well, so you can connect workflows to the lists and send s when records change. The bad thing here is that all SharePoint goodness comes at a price. Even though SharePoint has a supported limit of 30 million items per list and a threshold of 8 joins per query. It is not as optimized as a database that is specifically build to handle the data structure the application uses. Executing a bulk operation on the data which is a very common practice with data driven applications, is a very bad thing when the data is stored within SharePoint lists. A LightSwitch based SharePoint App In this section we are going to take a look at a simple application build with LightSwitch. We ve created three lists within SharePoint. A Contact list that will be used to store the names and addresses of people we get into contact with. An Organization list that will be used to store the organizations the contacts are working for. A Communication list that will be used to store information about the interactions we have had with our contacts. Within Visual Studio 2013 there is a new project template that can be used to create a LightSwitch HTML Application. This application type is fully capable of connecting to SharePoint and running as a SharePoint App.

54 The first screen encountered after creating the new project is a screen with a link named Attach to external Data source this will start a wizard leading thought the steps needed to connect to an existing SharePoint site. During development it is convenient to enter a username and a password of someone that has full control over the lists involved. The supported LightSwitch Screens There are three types of screens for handling SharePoint data: 1 The Browse Data Screen, this screen is used to display lists. 2 The View Detail Screen, this screen is used to show a more detailed view of a single list item. 3 The Add/Edit Screen, this screen can be used to both add new list items and edit existing ones. With these three screens all basic actions for viewing, adding and editing can be executed. Adding screens for these common actions is simple, just right click the screens tab in the solution explorer. A little wizard will show up to help with the selection of the screen type and the list on which the screen should operate. Figure 1: Add new screen wizard After adding the screens needed, all that needs to be done is link the screens together using action buttons and navigational items. Adding an action button to a screen can be done by double clicking the screen s light switch markup language (lsml) file. This will bring up the graphical editor for the lsml file. Buttons can be added either on the command bar or on the list. When placing buttons on the command bar they will be show on the bottom of the screen. Adding buttons to the List will place the buttons on the left side of the screen.

55 Figure 2: Adding action buttons Changing the default behavior LightSwitch creates a provider hosted app, in doing so it gives the developer two options to change the application. The first one is client side, this part is HTML, CSS and JavaScript. Its focus is on the user interface, it is for showing fields or hiding them, adding custom controls or changing default control behavior. The second options for altering a LightSwitch app is using C#. This option is more for handling data modifications, for instance validation of data against an external source. Taking a look at how to change the user interface. By default all the fields that are on the SharePoint list are also in the detail screen. Showing everything with a default set of controls is probably not the result customers are looking for. Fortunately, screens can be modified using JavaScript. This JavaScript can be used to replace the default controls with custom controls, it can also be used to write event handlers. Within Visual Studio there is a dynamic drop down box it will magically adapt to the item selected within the main screen. It will show different options depending on which item is selected. Figure 3: Write Code Client Side In Figure 3 the Full Name field is selected and the write code button shows the option to add three event handlers. However if the Command Bar was selected instead of the Full Name field the beforeapplychanges handler would not be shown. Were we to select one of the options, then we d be able to add JavaScript to change the default behavior.

The Definitive IP PBX Guide

The Definitive IP PBX Guide The Definitive IP PBX Guide Understand what an IP PBX or Hosted VoIP solution can do for your organization and discover the issues that warrant consideration during your decision making process. This comprehensive

More information

Data protection. Protecting personal data in online services: learning from the mistakes of others

Data protection. Protecting personal data in online services: learning from the mistakes of others Data protection Protecting personal data in online services: learning from the mistakes of others May 2014 Contents Introduction... 2 What the DPA says... 4 Software security updates... 5 Software security

More information

USE-CASE 2.0. The Guide to Succeeding with Use Cases. Ivar Jacobson Ian Spence Kurt Bittner. December 2011. USE-CASE 2.0 The Definitive Guide

USE-CASE 2.0. The Guide to Succeeding with Use Cases. Ivar Jacobson Ian Spence Kurt Bittner. December 2011. USE-CASE 2.0 The Definitive Guide USE-CASE 2.0 The Guide to Succeeding with Use Cases Ivar Jacobson Ian Spence Kurt Bittner December 2011 USE-CASE 2.0 The Definitive Guide About this Guide 3 How to read this Guide 3 What is Use-Case 2.0?

More information



More information

Development of support web applications in.net

Development of support web applications in.net Development of support web applications in.net For Visit Technology Group Master of Science Thesis in Software Engineering and Technology ANDERS CLAESSON CHRISTOPHE DUBRAY Department of Computer Science

More information

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited. DevOps IBM Limited Edition DevOps IBM Limited Edition by Sanjeev Sharma DevOps For Dummies, IBM Limited Edition Published by John Wiley & Sons, Inc. 111 River St. Hoboken, NJ 07030-5774 www.wiley.com

More information

Introduction When Lifecycle People Products Management Development Tailoring Other. 2002-2008 DSDM Consortium. DSDM Public Version 4.

Introduction When Lifecycle People Products Management Development Tailoring Other. 2002-2008 DSDM Consortium. DSDM Public Version 4. DSDM Public Version 4.2 Manual Introduction When Lifecycle People Products Management Development Tailoring Other 2002-2008 DSDM Consortium http://www.dsdm.org/version4/2/public/default.asp [12-1-2008

More information

Making Smart IT Choices

Making Smart IT Choices Making Smart IT Choices Understanding Value and Risk in Government IT Investments Sharon S. Dawes Theresa A. Pardo Stephanie Simon Anthony M. Cresswell Mark F. LaVigne David F. Andersen Peter A. Bloniarz

More information

Why Microsoft? For Virtualizing & Managing SharePoint. Microsoft System Center 2012 R2. July 2014 v1.0

Why Microsoft? For Virtualizing & Managing SharePoint. Microsoft System Center 2012 R2. July 2014 v1.0 Microsoft System Center 2012 R2 Why Microsoft? For Virtualizing & Managing SharePoint July 2014 v1.0 2014 Microsoft Corporation. All rights reserved. This document is provided as-is. Information and views

More information


HOW SAAS CHANGES AN ISV S BUSINESS HOW SAAS CHANGES AN ISV S BUSINESS A GUIDE FOR ISV LEADERS Sponsored by Microsoft Corporation Copyright 2012 Chappell & Associates Contents Understanding the Move to SaaS... 3 Assessing SaaS...3 Benefits

More information

Convergence of Social, Mobile and Cloud: 7 Steps to Ensure Success

Convergence of Social, Mobile and Cloud: 7 Steps to Ensure Success Convergence of Social, Mobile and Cloud: 7 Steps to Ensure Success June, 2013 Contents Executive Overview...4 Business Innovation & Transformation...5 Roadmap for Social, Mobile and Cloud Solutions...7

More information

THE TRUTH ABOUT TRIPLESTORES The Top 8 Things You Need to Know When Considering a Triplestore

THE TRUTH ABOUT TRIPLESTORES The Top 8 Things You Need to Know When Considering a Triplestore TABLE OF CONTENTS Introduction... 3 The Importance of Triplestores... 4 Why Triplestores... 5 The Top 8 Things You Should Know When Considering a Triplestore... 9 Inferencing... 9 Integration with Text

More information

Analytic Business Processes: The Third Generation

Analytic Business Processes: The Third Generation A Monash Information Services White Paper by Curt A. Monash, Ph.D. November, 2004 Sponsored by: Table of Contents Introduction The Analytic Process Challenge......1 Analytic Business Processes: An Overview...2

More information

EMC ONE: A Journey in Social Media Abstract

EMC ONE: A Journey in Social Media Abstract EMC ONE: A Journey in Social Media Abstract This white paper examines the process of establishing and executing a social media proficiency strategy at EMC Corporation. December 2008 Copyright 2008 EMC

More information

Privacy and Electronic Communications Regulations. Guidance on the rules on use of cookies and similar technologies

Privacy and Electronic Communications Regulations. Guidance on the rules on use of cookies and similar technologies Privacy and Electronic Communications Regulations Guidance on the rules on use of cookies and similar technologies Contents 1. Introduction 2. Background 3. Consumer awareness of cookies 4. Terminology

More information



More information

Data security in multi-tenant environments in the cloud

Data security in multi-tenant environments in the cloud Institute of Parallel and Distributed Systems University of Stuttgart Universitätsstraße 38 D 70569 Stuttgart Diplomarbeit Nr. 3242 Data security in multi-tenant environments in the cloud Tim Waizenegger

More information

Rich Data, Poor Data Designing Dashboards to Inform

Rich Data, Poor Data Designing Dashboards to Inform Rich Data, Poor Data Designing Dashboards to Inform by Stephen Few A note about the author Stephen Few has worked for 24 years as an IT innovator, consultant, and educator. Today, as Principal of the consultancy

More information

Problem Management. Contents. Introduction

Problem Management. Contents. Introduction Problem Management Contents Introduction Overview Goal of Problem Management Components of Problem Management Challenges to Effective Problem Management Difference between Problem and Incident Management

More information

Business Activity Monitoring (BAM) The New Face of BPM

Business Activity Monitoring (BAM) The New Face of BPM Business Activity Monitoring (BAM) The New Face of BPM June 2006 TABLE OF CONTENTS 1.0 EXECUTIVE SUMMARY... 3 2.0 BAM BASICS... 4 VOLUMES... 4 VELOCITIES... 5 ERRORS... 6 SPECIAL CONDITIONS... 6 BASIC

More information

Creating Mobile Learning. 7 key steps to designing and developing effective mobile learning

Creating Mobile Learning. 7 key steps to designing and developing effective mobile learning Creating Mobile Learning 7 key steps to designing and developing effective mobile learning kineo Creating Mobile Learning Scoping and scheduling your mobile Step 1: 03 learning project Producing the overall

More information

The Essential Guide to Mobile App Testing

The Essential Guide to Mobile App Testing The Essential Guide to Mobile App Testing Tips, techniques & trends for developing, testing and launching mobile applications that delight your users A Free Book from utest The Essential Guide to Mobile

More information

On Designing and Deploying Internet-Scale Services

On Designing and Deploying Internet-Scale Services On Designing and Deploying Internet-Scale Services James Hamilton Windows Live Services Platform ABSTRACT The system-to-administrator ratio is commonly used as a rough metric to understand administrative

More information

JCR or RDBMS why, when, how?

JCR or RDBMS why, when, how? JCR or RDBMS why, when, how? Bertil Chapuis 12/31/2008 Creative Commons Attribution 2.5 Switzerland License This paper compares java content repositories (JCR) and relational database management systems

More information

Handbook of. The Secure Agile Software Development Life Cycle

Handbook of. The Secure Agile Software Development Life Cycle Handbook of The Secure Agile Software Development Life Cycle 1 This work was supported by TEKES as part of the Cloud Software Program of DIGILE (Finnish Strategic Centre for Science, Technology and Innovation

More information

SAP Business One, The Answer to the Challenges of SMB Business Management Software Selection

SAP Business One, The Answer to the Challenges of SMB Business Management Software Selection SAP Business One Whitepaper Page 1 SAP Business One, The Answer to the Challenges of SMB Business Management Software Selection Contact: Daniel A. Carr dan@cdi-usa.com Phone: 248-347-4600 Date: June 14,

More information

GEF Web Style Guide. Final Report. Contract No. 0903/02 Southeast Asia START Regional Center. 16 September 2009

GEF Web Style Guide. Final Report. Contract No. 0903/02 Southeast Asia START Regional Center. 16 September 2009 GEF Web Style Guide Final Report Contract No. 0903/02 Southeast Asia START Regional Center 16 September 2009 Prepared by David W. Moody & Jeanne C. Moody Beaver Wood Associates Alstead, New Hampshire,

More information

Quick Start for Vendors Handbook

Quick Start for Vendors Handbook Quick Start for Vendors Handbook A Guide for EtherNet/IP Developers www.odva.org Copyright Notice EtherNet/IP Quick Start for Vendors Handbook Publication Number: PUB00213R0 Copyright 2008 Open DeviceNet

More information

Securing Enterprise Applications

Securing Enterprise Applications Securing Enterprise Applications Version 1.1 Updated: November 20, 2014 Securosis, L.L.C. 515 E. Carefree Highway Suite #766 Phoenix, AZ 85085 T 602-412-3051 info@securosis.com www.securosis.com Author

More information



More information