SharePoint Workbench Nedir?

Son günlerde SPFx konusunda kendimce bilgi paylaşmaya çalıştığım yazılardan sonra sürekli test ekranlarını da gösterdiğim SharePoint Workbench’in ne olduğu hakkında biraz daha detay paylaşmak isterim.

SharePoint Workbench geliştiricilerin, geliştirdikleri webpartları SharePoint’e yaygınlaştırmalarına gerek kalmadan ön izlemelerine ve test etmelerine yardımcı olan bir geliştirici aracıdır.

SharePoint Workbench’in iki farklı formu bulunuyor;

  • Local Workbench: SharePoint Framework geliştirme araçları ile beraber yerel sunucu üzerine yüklenir.
  • SharePoint Online / On-Premise Workbench: SharePoint Online site koleksiyonu veya on-premise site koleksiyonu üzerinden erişilir. Bu durumda adres formatı https://your-sharepoint-site/_layouts/workbench.aspx şeklinde olacaktır.

Local Workbench hızlı ve herhangi bir yaygınlaştırma gerektirmeden hazırladığınız webpartları test etmenize imkan tanır. Bunu yaparken eksik kalacak tek tarafı haliyle SharePoint sitenizin context’inde çalışmadığınızdan buradaki verilere ulaşamayacak olmanızdır. Bu konuda SPFx SharePoint Verileriyle Çalışmak isimli kısa yazımda bir örnek yapmış ve bulunduğunuz ortama göre farklı veri doldurma metodları hazırlayarak Local Workbench ile de içinde veri olan (örnek veri) çalışmalar yapabilmenizin yolundan bahsetmiştim.

Güzel olan bir noktayı daha yeniden hatırlatmak istiyorum. Yerel bilgisayarınızda hazırladığınız SPFx webpartınızı herhangi bir yaygınlaştırmaya gerek duymadan, doğrudan SharePoint Online tenant Workbench adresinizi yazarak gerçek verilerle de test edebilirsiniz. Burada tamamen sizin yerel bilgisayarınızdaki kaynaklar kullanılacaktır.

SPFx SharePoint Verileriyle Çalışmak

Önceki kısa yazılarımda SPFx’in ne olduğu ve geliştirme ortamını oluşturarak SPFx ile ilk örnek uygulamanın hazırlanması konularından bahsetmeye çalışmıştım. Bu yazılara aşağıdaki bağlantılardan erişebilirsiniz.

Şimdi yine bir örnek ile devam edip SharePoint verisine erişmek noktasında neler yapabiliriz buna değinmek istiyorum. Yeni bir örnek webpart projesi oluşturacağım, sonrasında içerisindeki gereksiz bölümleri temizleyip SharePoint sitesi altındaki liste isimlerini ekrana getiren bir yapı oluşturmaya çalışalım.

Öncelikle npm aracılığı ile gulp yüklemesini yapıyorduk. Bunun için aşağıdaki komut işimizi görecektir.

 

Sonrasında SharePoint generator objelerinin yüklenmesini sağlayabiliriyoruz. Bunun için de aşağıdaki komutu çalıştırmanız yeterli olacaktır.

Ve son olarak webpart’ın yaratılmasını sağlamak için aşağıdaki komut ile ilerliyoruz.

Bu adımların sonrasında gulp serve komutunu çalıştırarak uygulamanın local workbench üzerinde çalışmasını sağlayabiliyoruz. Bu bölümde uygulamayı yaratma kısmını hızlıca geçmeye çalışıyorum, zira yukarıda bağlantısını verdiğim SPFx Merhaba Dünya yazısında bu konunun detaylarına ayrıca değinmiştik.

komutunu çalıştırarak Visual Studio Code içerisinde projemizin açılmasını sağlayabiliriz. Bir önceki örnekte “Merhaba Dünya” demenin yanı sıra ToolPane için yeni propertyler tanımlama, bunlara varsayılan değer girişi ve önyüzde kullanımını örneklemeye çalışmıştık. Şimdi ise projemize yeni class’lar eklemek, buna metodlar yazmak, test verisi oluşturmak ve hem local workbench hem de SharePoint Online üzerinden veriye ulaşmak noktasına bakmaya çalışacağız.

Burada önemli konulardan bir tanesi local Workbench. Çünkü local workbench aslında SharePoint ortamındaymışız gibi bir arayüzü bizim için oluşturan ama aslında SharePoint olmayan bir ortam. Dolayısıyla bir veri, liste, vb söz konusu değil. Peki local workbench ile çalışırken bu veriye nasıl ulaşabileceğiz?

Local Workbench İçin Test Verisi Oluşturmak

Ben bu ismi vereceğim, çünkü yaptığımız iş aslında local workbench’de olmayan bir veriyi kodumuzu test edebilmek adına oluşturmak. Bunu test metodları yazmaya benzetebilirsiniz. Tabi kodumuzun hem local workbench’de hem de SharePoint Online’daki gerçek verilerle çalışabilmesi için bir dizi düzenleme yapmak durumundayız.

Öncelikle bu test verilerini oluşturmak ve metodlara ulaşabilmek için projemize yeni bir class eklememiz gerekiyor. Bunun için webpart dosyanızı seçili hale getirin ve “New File” butonunu tıklayın.

Oluşturacağımız dosyanın adını SampleHttpClient.ts şeklinde verebiliriz. Burada daha sonra oluşturacağımız ve webpart dosyamızın içinde belirteceğimiz ISPList ve ISPLists isimli interfaceler için tanımlamalar ve metodlar hazırlayacağız. Örnek olarak dosya içeriğimiz şu şekilde olacak.

Şimdi webpartımızın içerisinde hem oluşturduğumuz bu yeni class’ı, hem bununla bağlantılı interfacelerimizi, hem de kullanacağımız SPHttpClient nesnesi için gerekli tanımlamaları gerçekleştirelim. Bu bölümde “import” tagını kullanacağız ve kullanmak istediğimiz kütüphaneleri de webpartımızın içerisinde tanımlamış olacağız.

Şimdi iki tane metoda ihtiyacımız var. Bunlardan bir tanesi local workbench üzerinde çalışırken bize örnek verilerle yardımcı olacak olan metod, diğeri ise SharePoint Online’da çalıştığımız senaryoda bize ilgili site altındaki gerçek liste bilgilerini getirecek olan metod.

Gerçek datayı alırken verileri çekmek için web api’yi kullanıyoruz ve sonuç bize json olarak geri dönecek. Bu işlemi yaparken siz farklı filtreler kullanabilirsiniz. Ben sadece hidden listelerin veri olarak gelmesini istemediğimden bu bölümde buna ilişkin bir filtre kullandım.

Tabi kodumuz çalıştığında bizim hangi ortamda olduğumuzu anlamalı ve buna göre yukarıdaki metodlardan hangisini çalıştıracağını algılamalı. Bunun için aslında üst bölümde ilk import ve tanımlamaları yaparken yararlanabileceğimiz bir sp-core-library importu da yapmıştık. Aşağıdaki şekilde;

Buradan alacağımız Environment değerini kontrol eden bir metod ile local workbench’demiyiz yoksa SharePoint ortamında mı anlayabiliriz. Kontrol kodumuz şöyle olacak.

Bu bölümde EnvironmentType.Local enum’u local workbench’i temsil ediyor ve buna göre getSampleListData() metodunu çağırıyor, yani bizim örnek data dediğimiz bölümü. Koşulun ikinci bölümünde ise EnvironmentType.SharePoint ve EnvironmentType.ClassicSharePoint yer alıyor. Bu iki seçenek sizlerinde anlayacağı üzere modern arayüz ve klasik arayüzü temsil ediyor. Ve bu durumda ise web api aracılığı ile getirdiğimiz gerçek ortam SharePoint verileri geliyor karşımıza.

Bu bölümde kullandığımız ama henüz implemente etmediğimiz bir _renderList() metodumuz var. Bu ise artık oluşan çıktıyı html olarak ekrana döndürme bölümümüz ve şu şekilde olacak.

Ve tabi #spListContainer içeriğini body’nin render edildiği zaman ekrana yerleştirmek. Bunun için bir div kullanabiliriz.

Uygulamayı bu şekliyle local workbench’de çalıştırdığımızda aşağıdaki gibi bir çıktı ile karşılaşacağız.

 

Bu işlemi SharePoint Online workbench’de denediğimizde ise kod içinde web api için belirttiğimiz URL’deki sitenin altında yer alan listeleri ekrana getirecektir.

Uygulamaya ilişkin projenin tamamına GitHub üzerinden erişebilirsiniz.

SPFx Merhaba Dünya

Bir önceki kısa bilgilendirme yazısıyla kısaca SPFx Nedir? sorusuna yanıt vermeye çalışmıştım. Yazıya buradan erişebilirsiniz. Şimdiyse ortam kurulumumuzu yapıp bir webpart geliştirerek devam etmek istiyorum. Yazının sonunda aslında aynı örneğin yapılmış olduğu MSDN Tutorial’ına ait videoyuda bulabilirsiniz.

SharePoint FrameWork ile çalışmak için ihtiyacımız olan bileşenler;

  • Yeoman
  • Gulp
  • Node.js
  • Visual Studio Code

Öncelikle Node.js’i indirerek başlayabiliriz. Node.js’i kendi sitesinden stabil versiyonunu indirerek temin edebilir ve herhangi bir özel ayar yapmaksızın kurulum dosyasını çalıştırabilirsiniz. Node.js sitesine buradan erişebilirsiniz.

Bundan sonraki bölümde biraz command prompt üzerinde olacak çalışmalarımız. Atlamamanız gereken nokta command promptu “Run as Administrator” modunda açmak olmalı. İlk etapta Gulp aracını kurarak başlıyoruz. Gulp paketleme ve bundle etme olarak tabir edebileceğimiz işlemleri gerçekleştiriyor olacak. Sadece SharePoint Framework’e (SPFx) özel bir araç veya kavram değil elbette. Yanlış hatırlamıyorsam Visual Studio’ya ilk olarak .Net Core proje yapısıyla beraber doğrudan entegre edilmişti. Bu işlem internet bağlantınıza bağlı olarak yaklaşık 1-2 dakika kadar sürecektir.

Sonra SharePoint Framework için gerekli dosyaların kurulumunu yapmamız gerekiyor. Bu işlem bir müddet daha uzun sürüyor diğerlerine göre zira bir hayli dosyanın download edilmesi gerekiyor. Ben geliştirme ortamı olarak Azure üzerinde bulunan bir sanal makineyi kullanıyorum. Bu nedenle internet bağlantısında maalesef ülke olarak lokalde sahip olduğumuz bağlantı hızına göre bir miktar daha avantajlı olabiliyorum indirme sürelerinde. Lokal bağlantıda yaptığım denemelerde yaklaşık 20-25 dk sürmüştü bu işlem, Azure üzerinde 4-5 dakikada tamamlandı.

Bu bölümde önemli bir parametre olarak -g parametresine dikkatinizi çekmek istiyorum. Bu parametre ile aslında sonraki işlemlerimiz için de bir altyapı hazırlamış oluyor, global olarak gerçekleştirmiş oluyoruz işlemi.

Bundan sonraki aşamamız sadece geliştirme aracımızın kurulumunu yapmak. Ben Visual Studio Code’u tercih edeceğim ama kurulu durumda Visual Studio’nuz veya bir önceki yazıda bahsettiğim araçlarınız varsa onlar ile de ilerleyebilirsiniz, neticede ihtiyacımız bir kod editörü. Visual Studio Code’u buradan temin edebilirsiniz.

Şimdi artık webpartımızı oluşturabiliriz. Bunun için de bir komuttan yararlanacağız, bu bize aslında temel amacımız olan merhaba dünya webpartının bir örneğini oluşturacak. Amacımız bunun üzerinde değişiklikler yaparak yayına alabilmek.

Bu bölümde komut satırı ilk oluşturacağınız webparta ilişkin bazı sorular ile sizi yönlendiriyor olacak. Webpartınızın adı ne olsun, hangi javascript frameworkünü kullanacaksınız, solution folderı nerede olsun, webpartınızın açıklamasında ne yazsın, vb. Bu bilgileri verdikten sonra gerekli bileşenler internetten indirilecek ve webpartınız hazır hale gelecek.

Ekranda da yazdığı gibi aslında “gulp serve” komutunu çalıştırarak webpartınızın local Workbench üzerinde çalışmasını sağlayabilirsiniz ancak burada araya girerek yine bir önceki kısa yazımda bahsettiğim known-issue’ya dönmek istiyorum. Özellikle geliştirme tarayıcısı olarak Chrome kullanıyorsanız sertifika nedeniyle sorun yaşamanız mümkün. Bu nedenle aşağıdaki komutuda ekleyip sonra gulp serve demeyi önereceğim.

Şimdi komutumuzu çalıştırarak paketleme işlemini ve ardından çalıştırmayı gerçekleştirebiliriz.

Ekrandaki ardışık otomatik komut setlerinden de göreceğiniz üzere öncelikle paketleme işlemi gerçekleştiriliyor. Bu esnada aslında full trust solutionlarda elde ettiğimiz wsp benzeri bir paketleme gerçekleşiyor. gulp serve debug veya release modda paketleme gerçekleştirebiliyor. Tamamlandığında komut satırınız debug modda ve kodunuza doğrudan bağlı olarak değişiklikleri takip eder modda açıkken bir taraftanda lokal workbench üzerinde uygulamanızı test edebilme imkanına sahip oluyorsunuz.

Workbench adresine dikkatinizi çekmek istiyorum bu aşamada. Malum SharePoint ile full trust geliştirmelerde SharePoint’in yüklü durumda olduğu bir geliştirme ortamını tercih etmek durumundayız. Çünkü pek çok bileşen SharePoint ile beraber yükleniyor geliştirme ortamımıza. Ancak SPFx ile çalışmada buna gerek yok. Doğrudan localhost üzerinde bir workbench ile SharePoint ortamındaymış gibi testlerinizi gerçekleştirebilirsiniz. Yukarıdaki ekranda gördüğünüz “HelloWorld” isimli  webpartı sayfaya eklememiz yeterli çıktıyı görmek adına.

Webpartın sol bölümünde yer alan edit butonu aracılığı ile webpart toolpane’inize ulaşmak mümkünken silme komutuylada webpartı sayfanızdan silebilirsiniz. Düzenleme moduna aldığımızda toolpane parametrelerini görüntüleyebilir ve düzenleyebiliriz. Bu hazır webpart şablonunda description alanı toolpane içinde yer alıyor. Denerken dikkatinizi çekmek istediğim nokta toolpane’de yaptığınız değişiklikler sayfayı kaydetmenizi gerek kalmadan runtimeda webpartınızın üzerine uygulanmaya başlıyor.

Bir önceki yazımda SPFx’in özelliklerinden bahsederken kontrollerin responsive olduğundan bahsetmiştim. Workbench bunu da test etmenize imkan veriyor. Tarayıcının sağ üst köşesinde göreceğiniz tablet, desktop ve telefon seçeneklerine tıklayarak sayfanızın nasıl tepki verdiğini gözlemlemeniz mümkün.

Kısa bir süreliğine komut satırına geri dönelim. Burada bazı kısa yollar ile kodunuza path olarak veya Visual Studio Code ile erişebilirsiniz. Mesela aşağıdaki komut ile kodlarınızın bulunduğu path’i otomatik olarak açmasını sağlayabilirsiniz.

Veya kodunuzu düzenleme modunda açmak için aşağıdaki kodu kullanabilirsiniz. Bu sayede projeniz Visual Studio Code içerisinde açılacaktır.

Visual Studio Code içerisinde sol bölümde gerekli konfigürasyon dosyalarının yanısıra “src” isimli bir klasör yapısı göreceksiniz. Bu bölüm webpart kodlarınızın yer aldığı bölümü işaret ediyor. Ben kodu açarak tutorial içerisindeki örnekte yer alan düzenlemeleri yapıp webpartımı yeniden çalıştırmak istiyorum. Burada dört tane daha toolpane parametresi eklemeye ve bundalardan bir tanesini de önyüzde göstermeye çalışacağım. ToolPane parametrelerinin tamamı IHelloWorldWebPartProps.ts dosyası içerisinde yer alıyor. Bu alana ikisi string, ikisi boolean tipte dört tane daha property ekliyorum aşağıdaki kod bloğu ile.

Bu şekilde sadece property tanımlamalarını yapmış olduk elbette. Bu propertylerin webpartımız ile ilişki içerisinde olabilmesi ve varsayılan değerlerini alabilmesi için HelloWorldWePart.ts dosyasını açıyor ve getPropertyPaneConfiguration() metodunu bularak içeriğini aşağıdaki şekilde değiştiriyorum.

Bu şekilde bir tane Multi-Line textbox, bir tane CheckBox, bir DropDown ve bir de Toogle eklemiş oluyorum değişkenlerime bağlı olarak. Kullanmadan önce son bir işim daha kaldı. Bu toolpane parametrelerinin paket ile beraber gönderilmesini sağlayabilmek amacıyla HelloWorldWebPart.manifest.json dosyasını açıp içerisinde yer alan “preconfiguredEntries” bölümüne tanımlamış olduğum her bir ToolPane değişkeni için varsayılan değerleri atıyorum. Bu bölüm ayrıca webpartınızın adını, açıklamasını, vb de değiştirebileceğiniz, aslında on-premise geliştirmede de karşımızda olan manifest dosyası.

Önyüzde görüntülenmesini de test etmek amacıyla HelloWorldWebPart.ts dosyamı yeniden açıp render() metodu içerisindeki html bölümde istediğim alana aşağıdaki şekilde ekleme yaparak kullanmam mümkün.

Hemen güzel bir noktadan bahsedelim. Eğer bir önceki gulp serve komutunuzdan sonra Ctrl + C komutunu gönderirseniz projeniz debug moddan çıkar ve workbench kapanır. Ancak diyelim ki yukarıda bahsettiğim kod değişikliklerini projeniz çalışır durumdayken yaptıysanız yeniden çalıştırmanıza gerek olmadan sadece kaydetmeniz yeterlidir. Zaten bu esnada komut satırını izleyecek olursanız, yaptığınız değişikliklerin çalışan projeye uygulanmaya başladığını gözlemleyebilir ve projenizi yeniden çalıştırmadan test etmeye devam edebilirsiniz. Eğer projenizi debug moddan çıkartmak istiyorsanız Ctrl + C komutunu yazarak ve karşınıza gelen onay ekranını “y” komutuyla geçerek projenizin çalışmasını durdurabilirsiniz.

Bizim yaptığımız değişikliklerden sonra kaydettiğimizde elde edeceğimiz görüntü aşağıdaki şekilde olacaktır.

Ve son bir noktadan bahsetmek istiyorum. Lokal ortamda çalışırken uygulamanızı local workbench ile çalıştırdınız. Peki ama SharePoint Online’da bu uygulama nasıl görünecekti. Bunun için geliştirme aşamasında herhangi bir deployment yapmadan silerseniz sadece aşağıdaki formatta SharePoint Online Workbench’inizi açabilir ve uygulamanızı bu ortamda da test edebilirsiniz.

https://[tenantName].sharepoint.com/sites/[siteName]/_layouts/15/workbench.aspx

Bu durumda da çıktınız değişmeyecektir. Aşağıdaki ekranda url satırına özel olarak dikkatinizi çekmek isterim SharePoint Online adresine gittiğinden emin olmak adına.

Örnek projenin kodlarına GitHub üzerinden ulaşabilirsiniz. Ve tutorial’ın video halinden devam etmek isteyenler için aşağıda bulabilirsiniz.

SPFx Nedir

SPFx Nedir

Son günlerde yayınlanan SharePoint Feature Pack 2 ile beraber adını sıkça duymaya başladığımız, aslında geçtiğimiz yıl preview olarak duyurulmuş olan SharePoint Framework (SPFx) ile ilgili kısa birkaç bilgi paylaşarak başlamak istiyorum. Bundan sonra gelecek kısa yazılarımda da bu konuda farklı örneklere yer vermeye çalışacağım ancak öncelikle nedir bu SharePoint Framework (SPFx), bize ne gibi avantajlar sunacak veya ne gibi eksikleri var onlara bakmakta yarar görüyorum. Ardından geliştirme ortamımızı oluşturacak ve bir klasiği bozmadan, “Merhaba Dünya” diyerek devam edeceğiz elbette. Sonrasında ise biraz daha gerçek hayat örnekleri ve sorunları çözme yollarıyla devam edebiliriz.

SPFx client-side SharePoint geliştirme yapmanıza imkan veren bir sayfa ve webpart modeli olarak kısaca özetlenebilir. SharePoint verileri ile hızlıca entegre olabilen, open source araç/kaynak kullanma konusunda destek veren bir yapısı var. Klasik server-side SharePoint geliştirmede kısmen mahkum kaldığımız yeni nesil web teknolojilerini rahatlıkla kullanmamıza imkan veriyor. SharePoint Online için zaten kullanım imkanı varken, Feature Pack 2 ile beraber artık on-premise ortamda da kullanım desteğimiz sunulmuş durumda. On-premise ortamda kullanabilmek için September 2017 güncellemesi olarak da geçen Feature Pack 2 kurulumunu yapmış olmanız gerekiyor.

 

SharePoint Framework için ana özellikleri listeleyecek olursak.

  • Bağlantı sağlamış olan kullanıcı ve connection contextini kullanabiliyoruz. Burada herhangi bir iframe veya benzeri yapı söz konusu değil, javascript doğrudan sayfa içerisine ekleniyor.
  • Sayfada kullandığınız kontroller ayrı bir yapı üzerinde değil, doğrudan DOM içerisinde render ediliyor.
  • Kullanılan kontroller responsive özellikte.
  • Sayfanın yaşam döngüsüne bir geliştirici olarak müdehale edebiliyorsunuz. Mesela render, load, serialize, deserialize, vb.
  • Herhangi bir javascript framework ile çalışabilirsiniz. Mesela React, Knockout, Angular, Handlebars, vb.
  • Open source geliştirme araçlarını kullanabilirsiniz. Mesela npm, TypeScript, Yeoman, webpack, gulp, vb.
  • Son kullanıcılar tarafından da kullanılabilecek bir geliştirme yöntemi tabi ki tenant admin tarafından onaylanması durumunda.
  • Hazırlayacağınız webpartlar hem classic hem de modern sayfalarda kullanılabilir.

 

 

SharePoint Framework öncesinde de client-side geliştirme yapabiliyorduk elbette. Bu yöntemleri ve avantaj/dezavantaj incelemesini yapmaya çalışalım kısaca.

 

JavaScript Injection

SharePoint Online üzerinde, özellikle SandBox geliştirme yapısında kod kullanımımız giderek bloklandıktan sonra en yoğun kullanılan webpart Script Editor’dü sanırım. Kullanım şekli oldukça pratikti. Hazırladığınız JavaScript’i Script Editor webpart içerisine kopyalamanız yeterliydi. Sayfa çalıştırıldığında “page render” işlemi esnasında eklediğiniz script çalıştırılıyordu. İlk avantajı sanırım kolay olması. Kullanımı kolay, test etmesi kolay, tarayıcı üzerindeki araçlar aracılığı ile debug etmesi kolay. Diğer avantajlı kısmı ise aynı DOM ve aynı browser context’ini kullanıyor olması. Böylece sayfa içerisindeki diğer kontrollere ulaşmak ve dolayısıyla basit entegrasyon ve interaktiviteler sağlamak mümkün. Bu yazacağınız kod ile doğrudan bağlantılı olsa da genel itibariyle performanslı yada UX açısından tüm sayfanın gelmesini beklememe konforu sunması açısından performanslı görünen bir yapıda olduğunu söylemek mümkün.

Dezavantajlı kısımlarına bakacak olursak yine kolay olması burada da ilk maddeye gelecektir sanırım. Bizim için kolay olduğu kadar son kullanıcının sayfayı düzenleme moduna aldığında scripte yapacağı ufak müdehaleler ile fonksiyonaliteyi bozması da çok kolay 🙂 İkinci sorunumuz ise “NoScript” olarak ifade edebileceğimiz feature’ın aktif olduğu senaryolar. Bu feature aktif durumdayken “Add/Customize Pages (ACP)” yetkileriniz alındığından Script Editor ilgili site koleksiyonlarında bloklu duruma gelecektir.

 

SharePoint Add-in Model

Özellikle NoScript özelliğinin aktif olduğu sitelerde kullanmayı düşündüğümüz geliştirme modellerinden bir tanesi. Bu yöntemi kullandığınızda aslında hazırladığınız geliştirme paketleri bir iFrame yardımıyla sayfaya ekleniyor. iFrame’in responsivite katili olmasını bir tarafa bırakacak olursak özellikle admin rolündeki arkadaşların bu yönteme yönlendirmelerinin altında yatan bir diğer sebep de iFrame olması sebebiyle sayfamız ile aynı DOM’u ve context’i kullanmıyor olduğundan güvenli bulunuyor olması. Tabi aynı DOM ve context’i kullanamıyor olmanın verdiği dezavantaj ayrıca değerlendirilmeli.

Dezavantajlarına bakacak olursak öncelikle Script Editor’a göre çok daha yavaş çalışan bir mekanizması olduğunu söylemek mümkün. Bunun nedeni iFrame olarak çalışıyor olması ve aynı DOM’u kullanmıyor olması nedeniyle iFrame’deki sayfayı açmak için ayrı bir request daha göndermek durumunda. Yukarıda da belirttiğim gibi günümüzde artık çok da küçümseyemeyeceğimiz bir diğer dezavantaj ise responsivite noktasında iFrame kaynaklı olarak sorun yaşıyor olmamız.

 

SharePoint Framework

Son dönemde özellikle bulut kullanımının da yoğunlaşmaya başlaması, Microsoft’un önem verdiği mecralardan birinin on-premise yerine SharePoint Online olması gibi sebeplerle eski geliştirme metodumuz olan full trust C# assembly kullanarak geliştirme tarih olmaya doğru gidiyor. Çok sert oldu, tarih olmayacak elbette ama daha çok on-premise ve hybrid olmayan daha kısıtlı bir domainde hayatını sürdürmeye devam edecek. Yeni nesil geliştirmelerde yerini artık JavaScript tabanlı, arka planda REST çağrıları ile veriye ulaşan veya düzenleyen yapılarda ilerliyoruz. İşte SharePoint Framework (SPFx) bu noktada karşımıza çıkan yeni nesil SharePoint geliştirme modeli diyebiliriz.

SharePoint Framework’ün halen geliştirilmeye devam ettiğini söylemeden geçmek istemiyorum. Hatta şu anda aktif olan bazı bölümler için ileride değişimler de sözkonusu olabilir. Ancak Microsoft bu kısım için geriye dönük destek olacağı sözünü veriyor. Dolayısıyla “beklemeyin, geliştirin” diyor bize.

Microsoft tarafından ürün için paylaşılmış eski tarihli bir road map var ancak yenisi Ekim ayı içerisinde yayınlanacak, bunun ile ilgili road map’in yayınlanması sonrası bir şeyler yazmayı daha doğru buluyorum.

Bitirmeden önce bizi doğrudan ilgilendirecek bir known-issue’dan da haberdar etmek isterim. Eğer geliştirme esnasında tarayıcı olarak Chrome kullanıyorsanız Workbench’in kullanımında geliştirici sertifikası konusunda sorun yaşayabilirsiniz. Bu durumda “Your connection is not private” hata mesajı sonrasında çalışmanızı devam ettirebilirsiniz. Tüm bilinen hataların güncellendiği adrese buradan erişebilirsiniz.

 

Geliştirme Araçlar

SharePoint Framework ile clien-side geliştirmede aşağıdaki kod editörlerini kullanabilirsiniz.

  • Visual Studio Code
  • Atom
  • Webstorm

 

Profil Resim Adresini Değiştirme

SharePoint kurulum işlemlerinin ardından genellikle servis konfigürasyonlarını test etmek ve bazı düzenlemeleri gerçekleştirmek için bir tane boş web uygulaması ve bir tane de mysite için “My Site Host” türünde site koleksiyonu barındıran mysite web uygulamasını yaratırız. Bu esnada genellikle henüz dns tanımları yapılmamış hatta daha nasıl bir url kullanılacağı belirlenmemiş bile olabilir. Bu nedenle sunucu üzerinde host dosyasına seçtiğimiz örnek url bilgisini girerek tamamlarız bu konfigürasyonu.

Bu esnada yapılan konfigürasyonlardan bir tanesi de User Profile Service Application’ın oluşturulması ve profil importunun gerçekleştirilmesidir. Importun tamamlanıp profil imajları için gereken düzenlemeyi de yapmanızın ardından artık tüm çalışan profiline adreslediğiniz alan değerleri ile sahip olduğunuz bir altyapınız hazır durumdadır.

Ancak konu ciddileşmeye, adresler belirlenmeye ve dns tanımları yapılmaya başlandıktan sonra my site üzerinde host edilmekte olan profil resimlerinin adreslerinin ilk girdiğimiz adres olarak kalmış olduğunu gözlemleriz. Aslında Alternate Access Mapping, IIS Binding gibi tüm işlemleri tamamlamışsınızdır.

Bu adresin değişiminin sağlanması için aşağıdaki gibi bir PowerShell komutu işinizi görecektir. İşlem sonrasında yapacağınız kontrolde profil resimlerinin adres bilgisinin artık güncellenmiş olduğunu göreceksiniz.

 

Azure VM Internet Bağlantı Hatası

Microsoft Azure üzerinde oluşturmuş olduğunuz sanal sunucu (virtual machine) üzerindeki tarayıcı aracılığı ile internete erişmekte problem yaşayabilirsiniz. Aslında bu senaryonun ağırlıklı olarak karşılaşıldığı senaryo sunucu üzerinde domain controller rolünün aktif bulunduğu zamanlar olacaktır. Sunucu üzerinde domain controller tanımı yaparken ayrı bir dns sunucu belirtmediyseniz, yani sunucunun kendisini dns server olarak tanımladıysanız, public bir dns server bulunamayacak ve internete çıkış işlemlerinde problem yaşanabilecektir.

Sorunun çözümü için, virtual machine tarafından kullanılmakta olan sanal ağ bağlantısına (virtual network) ulaşarak Microsoft’un hazır public DNS adreslerini tanımlamanız gerekiyor. İşlem sonrasında sunucuyu restart etmenizi öneriyorum. Microsoft’un public DNS sunucu bilgileri aşağıdaki şekilde;

  • 168.63.129.16
  • 168.62.167.9

Eğer oluşturduğunuz sanal sunucuyu spesifik bir sanal ağ bağlantısına bağlı olarak oluşturmadıysanız bu durumda sunucunun içindeki ağ bağlantıları bölümünden IPv4 ayarlarına giderek doğrudan dns server adresi olarak bu IP’leri belirtebilirsiniz. Veya sunucunuzun bir imaj yedeğini alarak şablonlardan sanal sunucu oluştur seçeneği ile yeni bir sanal sunucu oluşturabilir ve bu esnada yukarıdaki düzenlemeyi yaptığınız bir sanal ağ bağlantısı belirleyebilirsiniz.

Central Administration Port Değişikliği

SharePoint kurulumlarınız esnasında Central Administration arayüzünün port bilgisi otomatik olarak atanır ve Configuration Wizard’ı ilk çalıştırdığınızda bu portu değiştirmenize imkan verilir. Ancak çeşitli nedenlerle port bilgisini daha sonra değiştirmek zorunda kalabilirsiniz;

  • Kurulum esnasında bu adımı gözden kaçırmış ve bahsettiğim random port atamasına maruz kalmış olabilirsiniz.
  • Şirketiniz bilgi sistemleri politikalarıyla uyumlu olmayan bir port numarası belirlemiş olabilirsiniz.
  • Farklı bir uygulama ile çakışan bir port belirlemiş veya geçen zaman içinde çakışacak bir uygulamayı yüklemek zorunda kalmış olabilirsiniz.

Bu işlemi basit yolla halletmek için SharePoint 2010, SharePoint 2013 ve SharePoint 2016’da bir PowerShell komutu işinizi görecektir.

Bu işlem ile 1023 ile 32767 arasında SSL için kullanılmakta olan 443 haricindeki portlardan bir tanesini belirleyebilirsiniz. Eğer izin verilmeyen kriterde bir port numarası belirleyecek olursanız “Invalid Port” uyarı mesajını alacaksınız.

Eğer halen SharePoint 2007 ile çalışıyorsanız bu işlemi gerçekleştirmek için stsadm komutunu kullanmalısınız.

İşlemi tamamladığınızda IIS Binding ve diğer adreslemelerin tamamı yeni port numarasına göre düzenlenecek ve artık yeni port numarası ile uygulamanıza erişebileceksiniz. Eğer Central Administration’a hiç ulaşamıyor, port bilgisini de bulamıyorsanız bu durumda aşağıdaki komut kullanılmakta olan port bilgisini göstermek için yeterli olacaktır.

 

Yeni Farm Admin Hesabının Eklenmesi

Test ve canlı ortamlar için olmasa da özellikle geliştirme ortamlarında yeni katılan geliştiriciler için uygulama geliştirmeyi mümkün kılmak adına bazı yetkilendirmeler yapmanız gerekir. Kısaca sıralayacak olursak;

  • Kullanıcının Central Administration > Security tabı altında yer alan menü aracılığı ile “Farm Administrators” SharePoint grubuna eklenmesi.
  • Central Administration içerik veritabanında kullanıcıya yetki verilmesi.
  • Uygulama içerik veritabanında kullanıcıya yetki verilmesi.

Bu işlemleri tek bir kullanıcı için yapmak sorun olmasa da ekip için yapmak veya sürekli eklenen yeni geliştiriciler için tekrar tekrar yapmak sıkıcı olabilir. Bu noktada aşağıdaki gibi bir PowerShell fonksiyonu ile bu işi otomatik hale getirebilirsiniz.

Fonksiyonu kullanmak için ise;

 

Feature Pack vs Service Pack

SharePoint ile uzun zamandır çalışanların farkında oldukları bir konu her geçen gün ürüne ilişkin güncelleme paketlerinin çıkışındaki sürenin kısalması olacaktır.

SharePoint 2003 ve 2007 döneminde belli aralıklarla çıkan (2003 için belirsiz, 2007 için genellikle 2 ayda bir) -düzenli- güncelleme paketlerine ek olarak aşağı yukarı yılda veya bir buçuk yılda bir çıkan Service Pack’ler vardı.

SharePoint 2013 için 2014 yılının sonuna kadar düzenli olmayan aralıklarla devam eden güncelleme paketleri Ocak 2015 itibariyle Microsoft’un da duyurusu ile artık aylık olarak düzenli yayınlanmaya başlandı. Şüphesiz bundaki en büyük nedenlerden bir tanesi özellikle hybrid çalışma prensibinde ilerlemeyi hedefleyen kullanıcı kitlesinin SharePoint Online ile on-premise olarak adlandırdığımız yerel SharePoint kurulumları arasında özellik ve fix bakımından oluşan farklılığın azaltılabilmesine imkan tanınmasıydı.

SharePoint 2016’da da Microsoft SharePoint 2013 için 2015 yılı başında başlattığı düzende, her ay bir güncelleme paketi çıkartarak ilerlemeye devam etti. Hybrid çalışma prensibinde ilerlemeyen kullanıcılar için SharePoint güncelleme sıklığı genellikle yeni kurulan bir ortamın en güncel versiyon ile kurulması ve bir problem ile karşılaşıldığında veya üzerinde çalışılan sistem için sistem birimlerinin belirlediği güncelleme periyodlarında güncel paketlerin geçilmesi şeklindeydi. Her ay çıkan güncellemelerin düzenli yüklenememesi konusunu çok yadırgamıyorum açıkçası. Neticede ortalama 5 sunucudan oluşan orta seviyede bir farm için önce test, sonra canlı ortam periyodunda ilerlendiğini düşünecek olursak ciddi bir zaman ve fonksiyonalite kaybına neden oluyor güncelleme paketleri. Bu nedenle her güncelleme paketi muhakkak değerlendirilip takip edilmesi ve içeriğinde barındırdığı düzeltilen özellikler yakından değerlendirilmeli ve buna göre planlama yapılmalı düşüncesindeyim.

Buradan yola çıkarak geçtiğimiz günlerde yayınlanan Feature Pack 2 sonrası aldığım sorulara istinaden Feature Pack ve Service Pack arasındaki farklılıklara değinmek istiyorum. İlk Feature Pack olan ve Kasım 2016’da çıkan Feature Pack 1 sanırım henüz pek fazla kişinin SharePoint 2016 geçişi yapmadığı döneme denk geldiğinden atlanmıştı. Feature Pack 2 sonrası Feature Pack 1 aramalarının artmış olabileceğini elimde bir istatistik olmasa da tahmin edebiliyorum.

Peki nedir Service Pack, nedir Feature Pack?

Service Pack: Hotfix, security update, critical update ve genel anlamdaki güncellemelerin paketlendiği, test edildiği ve aylık olarak yaygınlaştırıldığı paketlerdir. Service Pack’lerde üreticinin esas odaklandığı konu ürünün stabil kalması, performans ve güvenlik gibi başlıklarda yaşanan sorunların çözümlenmesidir.

Feature Pack: Ağırlıklı olarak ürüne yeni özellikler kazandırmanın ön planda olduğu, müşterilerden alınan geri bildirimler ve ürünün yol haritasında belirlenmiş olan başlıklardaki yeni özelliklerin ürüne kazandırılmasını hedefler.

Feature Pack 1 ile hayatımıza aşağıdaki başlıklar eklenmişti, daha detaylı bilgi için KB makalesinin bağlantısına buradan ulaşabilirsiniz.

  • Administrative Actions Logging
  • MinRole enhancements
  • SharePoint Custom Tiles
  • Hybrid Auditing (preview)
  • Hybrid Taxonomy (preview)
  • OneDrive API for SharePoint on-premises
  • OneDrive for Business modern experience (available to Software Assurance customers)

Feature Pack 2’nin ise (12 Eylül 2017’de yayınlandı) eklediği ana özellikler aşağıdaki şekilde. Daha detaylı bilgi için KB makalesinin bağlantısına buradan ulaşabilirsiniz.

  • SharePoint Framework (SPFx)

SPFx’den daha detaylıca ayrı birkaç yazıda bahsetmek daha doğru olacaktır. 🙂

Yeni Farm (PowerShell)

SharePoint kurulumlarında aslında sihirbaz size son derece yardımcıdır. Aşağıdaki 3 adım ile herhangi bir kod bloğu çalıştırmadan da farm oluşturmak mümkün.

  • Install Farm Pre-Requisites
  • Install SharePoint
  • Run SharePoint Configuration Wizard

Bunun dışında, tercihi herşeyi scriptler ile oluşturmak olanlar için AutoSPInstaller gibi araç setleri de yaratılmış ve kullanıma sunulmuştur. Ancak bu gibi araçların da bazı konfigürasyonlar isteyeceği net. Bu nedenle tam da ortada bir yerde olabilirsiniz. Yani kurulum ile ilgili temel adımları size sunulan görsel arayüzlü kurulum araçlarıyla yapmak, ama sonraki konfigürasyonlar ve servis uygulaması işlemlerinde PowerShell’den yardım almak.

Bu sürecin size bir diğer katkısı da sistem veritabanları da dahil isimlendirmelerine müdehale edebilmek olacaktır. Çünkü varsayılan sihirbazların kullanıldığı ilk yöntemde her ne kadar SharePoint_Config database ismine müdehale edebilseniz de Central Administration yönetim konsolu uygulamasının veritabanı ismine müdehale edemezsiniz. Yukarıda bahsettiğim AutoSPInstaller bu sorunu çözmek ve hatta daha fazlasını yapmak ile beraber bazı kullanıcılar için konfigürasyonu zaman alıcı olarak yorumlanabiliyor.

Aşağıda örnek olarak paylaştığım script ile yukarıdaki ilk iki adımı SharePoint kurulum medyası üzerinden görsel arayüzde yaptıktan sonra farmın oluşturulması işlemini yapabilirsiniz.