Building multiplatform share point solutions
•Transferir como PPTX, PDF•
1 gostou•521 visualizações
My Presentation from SharePoint Saturday Calgary on May 31. Learn how to build SharePoint solutions that can support Web Parts, App Parts, SharePoint Online and any mobile platform.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Building multiplatform share point solutions
Semelhante a Building multiplatform share point solutions (20)
Último
Último (20)
Building multiplatform share point solutions
- 1. How to support on-prem, in the cloud and any mobile platform 31May2014
- 2. 2 | SharePoint Saturday Calgary – 31 MAY 2014 About Me
- 3. 3 | SharePoint Saturday Calgary – 31 MAY 2014 Session Agenda
- 4. Looking into my Crystal Ball
- 5. 5 | SharePoint Saturday Calgary – 31 MAY 2014 What is a Portal? Web page website
- 6. 6 | SharePoint Saturday Calgary – 31 MAY 2014 Rise of the Mobile Worker
- 7. 7 | SharePoint Saturday Calgary – 31 MAY 2014 Mobile is Too Big
- 8. 8 | SharePoint Saturday Calgary – 31 MAY 2014 What's wrong with Responsive Design? 89% 11% % OF TIME SPENT ON MOBILE DEVICES Apps Browser
- 9. How we build SharePoint Solutions today
- 10. Presentation Layer Application Code Database SharePoint Server Object Model
- 11. How we will build them tomorrow
- 12. 12 | SharePoint Saturday Calgary – 31 MAY 2014 Mobile Apps Presentation Layer SharePoint Server Object Model Database Application Code Service Interface SharePoint Client Object Model Other Data Sources, ex: External Databases, Web Services, etc.
- 14. 14 | SharePoint Saturday Calgary – 31 MAY 2014 Service Interface
- 15. 15 | SharePoint Saturday Calgary – 31 MAY 2014 What is SOA?
- 16. 16 | SharePoint Saturday Calgary – 31 MAY 2014 REST Web Services
- 17. 17 | SharePoint Saturday Calgary – 31 MAY 2014 Application Code
- 18. 18 | SharePoint Saturday Calgary – 31 MAY 2014 SharePoint Client Object Model
- 20. 20 | SharePoint Saturday Calgary – 31 MAY 2014 Physical Infrastructure – Current SharePoint Application Servers SharePoint Database SharePoint WFE SharePoint WFE Internal UserExternal User DMZ
- 21. 21 | SharePoint Saturday Calgary – 31 MAY 2014 Physical Infrastructure - New SharePoint Farm SharePoint Database Service Interface Server Internal User DMZ Mobile Apps
- 22. 22 | SharePoint Saturday Calgary – 31 MAY 2014 Transport Security
- 23. 23 | SharePoint Saturday Calgary – 31 MAY 2014 Device Security
- 24. 24 | SharePoint Saturday Calgary – 31 MAY 2014 Remember
- 25. Its not that hard
- 26. 26 | SharePoint Saturday Calgary – 31 MAY 2014 GetAllWellLocations (Service Interface) String Latitude (Optional) String Longitude (Optional) GetAllListItems (Application Code) String spWeb String spLibName String spQuery GetExternalData (Application Code) String datasource String query SP Content Database External Database Client Object Model SQL Query REST Call
- 28. 28 | SharePoint Saturday Calgary – 31 MAY 2014 Why?
- 29. 29 | SharePoint Saturday Calgary – 31 MAY 2014 Benefits
- 30. 30 | SharePoint Saturday Calgary – 31 MAY 2014 Resources http://searchsoa.techtarget.com/feature/Manes-on-SOA-in- 2012-People-get-the-architecture http://msdn.microsoft.com/en-us/library/aa480021.aspx http://www.ibm.com/developerworks/webservices/library/ws- restful/ http://msdn.microsoft.com/en- us/library/office/ee857094(v=office.14).aspx
- 32. 32 | SharePoint Saturday Calgary – 31 MAY 2014 Thanks to Our Sponsors
- 33. 33 | SharePoint Saturday Calgary – 31 MAY 2014 Special Thanks SPUG
- 34. 34 | SharePoint Saturday Calgary – 31 MAY 2014 Housekeeping
Notas do Editor
- In my role, part of my job is to look into my crystal ball and try to strategically plot a course that will keep us successful today, but also keep us successful tomorrow.
- Before looking at the future of portals, I like to remind myself what a portal actually is This quote from Wikipedia, I feel, is a nice short summary SharePoint Portal landing page: Announcement Web Part, Weather, Traffic, Stock Ticker web parts, Enterprise Social (Yammer) newsfeed, Rotating News Banner, etc. Many different data sources, present in a uniform way Whats changing?
- This is the reason why we are even talking today Huge trend that is changing the way we are consuming information But there is problem, besides the obvious ones, that we aren’t talking about much
- Can’t lump together all portable devices into a single category Need to consider each platform individually Easier to just say mobile as a catch all use Responsive design to handle everything
- Apps are king People overwhelming prefer spending time in Apps vs the Browser on their mobile device Not to mention screen size. If no one has over 20% market share that‘s a lot of screens to consider and a lot of use cases. If we need to build apps, how are we going to support all these different platforms without writing the same application a million times in slightly different ways…no one is going to pay for that
- Lets review how we currently build SharePoint Solutions
- Typically we’ve always built our SharePoint solutions following the multi-tier architecture of SharePoint. We load our code into the GAC and run it in the SharePoint context. The only way to access the data is through the SharePoint presentation layer. Very successful model for the last 10+ years How do you expose this to a mobile device without using responsive design?
- While the current way has been successful, it will not be very soon. That approach only works with on prem solutions, does not support Cloud That approach does not work with SharePoint Apps This approach has limited ability to support multiple platforms, responsive design being the best option
- Move all SharePoint Code off of the SharePoint Server Service API that allows any device to leverage your business logic Service API can consume more than just SharePoint data and orchestrate the response based on business needs Each consuming application can render data however they seem fit Benefits: Application (Business Logic) Code Base that can be leveraged by any platform Cloud Ready, can be used with either SP on prem or O365 Upgrade are easier as SharePoint is still OOTB SharePoint never has to be exposed to the outside world
- What do we need to build it?
- This layer needs to be robust to handle any OS on any platform, sounds like the whole goal of SOA The one thing that Web Parts, App Parts, Web Pages and any Mobile device (regardless of platform) have in common is the ability to send and receive HTTP messages. This is why we leverage Web Services to build the services layer…but what kind?
- You don’t have to build the same application over and over again, you can leverage SOA to build a single application that each platform can consume in their own way. Goal: Provide a set of services (API) that any platform can leverage regardless of technology
- Supports both JSON and XML Client only needs to be able to send and receive HTTP messages
- Application Code consists of two pieces: .NET and the Client Object Model The application code is hosting the business logic, it’s the brains of the operation Single application code layer could multiple service layers Not trying to integrate data source into SharePoint, simply pulling data and massaging before sending back to client. Data never needs to live within SharePoint
- A few options for this piece: SharePoint Client Object Model Managed Code (C#) SharePoint Client Object Model JavaScript SharePoint REST Web Services I prefer the Managed Code version for a couple reasons: Since the service layer is all running on a web server there is no benefit to offloading logic to the client through JavaScript Source Control is easier with C# Access to more SharePoint functionality compared to REST Web Services
- Here is where things get tricky Security teams look at Mobile Platforms as huge security holes TSX wouldn’t put in a wireless network because someone might sit outside, by the elevators and hack into their network on the wireless signal… Security teams are paid to be paranoid, your job is ensure what they are pushing back on are likely scenarios, remember nothing is 100% secure
- Current approach to SharePoint Solutions Back to back Perimeter network model (from MS) WFE server must be in DMZ (externally exposed) One way trust (at least) required between corporate network and DMZ network SharePoint is not a three tier architecture, it’s n-tier. This means the WFE talks directly to the DB means more holes in the corporate firewall How do you control downloaded documents and cached content on the end users device?
- SharePoint stays completely inside the corporate network No trust required between DMZ network and Corporate network No additional firewall ports need to be opened aside from the standard HTTP ports (80, 443) Native Apps give you more control over what is stored locally.
- Custom HTTP Headers, requires attacker to have inside knowledge IF code is written properly, there is no ability to modify data using only GET requests
- Responsive Design, you are unsure what they have downloaded or opened on their mobile device, not stored encrypted and could be opened by anymore that has access to the device No external access to anything? Employees are probably carrying around paper copies, how do you track that? Security is paid to be paranoid, you are paid to be realistic
- This SOA layer sounds like a lot of extra work and I’m not sure we have the buy in to build anything this robust Lets see what this look like in a real life example. Lets pretend you are in the oil and gas industry, rare for this city Lets pretend you have a portal that contains a web part that shows you all of your well locations On a standard web page viewed on a PC/Laptop this web part would just be a big map with a bunch of dots on it If it was really sophisticated it may pull the area you work in and target the map to that location by default But how would it work on a tablet? On a phone? Do you really want to pinch and zoom, change the location, etc, just to see the map? Wouldn’t it be cool if the map was targeted to your exact location when on a mobile device? Wouldn’t it be cool if could take your exact location and give you directions on who to get to the well you are interested in? Wouldn’t it be cool if it knew you were at a well location and automatically pulled up the well data for you?
- Not much different than how you would currently build today Easy to integrate external data sources, like your PI data Service Layer can be used to combine or massage data from multiple data sources Reusability, many services within the service layer can leverage the same Application code. In general most SharePoint custom pieces are querying a list or library to bring back some data. That can be abstracted into a single call in the application layer