Hakan UZUNER » Cozumpark.Com

Makalemin bu bölümünde kendi oluşturduğumuz Sharepoint web sitemiz üzerinde nasıl işlemler yapılabileceği konusunda ayrıntılı olarak durulacaktır.

Bu makalenin amacı, Sharepoint Server üzerindeki yönetim işlemlerinin anlatılmasıdır.

Öncelikle Sharepoint serverın kullanım amaçlarına değinmek gerekirse;

*Colloboration projeleri için çok uygun bir ortam sunar.

*Data paylaşımı için son derece uygundur.

*E-mail ile haberleşme olanağı sağlamaktadır.

*Kurumsal şirketler açısından data kaybının önlenmesine yardımcı olur.

*Hazırlanmış olan dökümanların versiyonlanmasına ve kontrolüne imkan verir.

*Süresi geçimş ve kullanılmayan datanın silinmesini sağlamaktadır.

*Döküman ve Data entegrasyonunu sağlar.

*Döküman ve yazılımları oluşturan insan gücünün verimli kullanılmasını sağlayarak işgücü kaybının önüne geçer.

*Data paylaşımını güvenli hale getirip zararlı kişilere karşı önlem almanıza olanak verir.

*İş akışlarının düzenli bir şekilde oluşturulmasını sağlar.

 

Sharepointin en önemli özelliklerinden olan Döküman Depolama ve Yönetilmesi özelliği bulunur.Bu özelliğin getirdiği yenilikler kısaca şöyle özetlenebilir:

-Döküman Kütüphanesi

-Döküman Versiyonlama

-Geri Dönüşüm kutusu

-Resim Kütüphanesi

-Task atama olayları

-Problem Listeleri

 

Sharepoint serverın en önemli özelliği web sayfası dizayn edebilme seçeneğidir.Firma çalışanlarına birtakım web paylaşımları sunar.Bunları özetlemek gerekirse:

*Online Sunum:Firma çalışanları arasında real time haberleşmeyi sağlar.Exchange ve Active Directory entegrasyonu sayesinde kişilerin free,busy,offline olup olmadıklarını gözlemlemeye olanak verir.

*Web Parts:Web partlar sayesinde custom web siteleri yapılabilmektedir.

*Tartışma Panoları:Kişilere tartışma forumları açabiliriz.

*Contact Lists:Kontak listeleriyle kişilerin telefon,adres bilgisi vb. bilgilerini yayınlayabiliriz.

*Shared Calendars:Bu özellikle kişiler birbirlerinin Calendar durumlarını görebilir ve önemli toplantılarını buna göre organize edebilirler.

*Döküman Alanı:Bu kısımda kişiler birbirleriyle döküman paylaşımı yapabilirler.

 

 

Bilgi Yönetim Özellikleri

*Alerts:Kullanıcıların dökümanlar yaratıldığında ,silindiğinde veya değiştirildiğinde e-mail ile uyarılması için alertler kullanılmalıdır.

*RSS Desteği:RSS desteği ile diğer web sitelerinde oluşan update bilgileri direkt olarak kullanıcıya yansıtılır.

*Search Desteği:Bu sayede dizayn edilmiş olan site içerisinde arama işlemleri yapılabilmektedir.

 

İletişim Özellikleri

*Duyurular:Web sitesinde oluşan değişikliklerin kullanıcılara anons edileceği kısımdır.

*Linkler:Kullanıcıların sıklıkla kullandıkları web sayfalarının linklerini buraya koyarak yayınlatabiliriz.

*Tartışma Panoları:Şirket çalışanları için çeşitli konularda tartışma yapılabilecek kısımdır.

Sharepoint Server 2007 Kurulum Aşamaları

Sharepoint kurulumu için server üzerinde bulunması gereken temel özellikler şöyledir;

-Min. W2003 standart server+sp1

-.net 2.0 ve .net 3.0

-IIS 6.0

-SQL 2005 Sp2

-Min. 1 GB ram

 

Sharepoint server kurulumunda öncelikle yapılan işlemler şöyledir;

Office server.exe ile setup işlemine başlanır.

Lisans key girilir.

Kurulum seçeneklerinden Gelişmiş seçeneği seçilir.

Tüm bileşenleri yükle seçeneği seçilir.

Sharepoint server 2007 yüklenmeye başlanır.

Ve sharepoint kurulumu bitirilir.

Şimdi Sharepoint serverın database bağlantısı ve diğer özelliklerini configüre edeceğimiz sihirbaz kısmına başlıyoruz;

Yes seçilerek ilerlenir.Yeni bir sunucu grubu kurmak istediğimizden hayır seçeneği seçilerek ilerlenir.

Veritabanı sunucusu ve database ismi belirtilir.

Sharepointe bağlanacağımız port numarası ve authentication seçenekleri doldurulur.

 

İleri seçilerek Sharepoint yapılandırması başlatılır.

Son  seçilerek kurulum bitirilir.

Sharepoint serverı kurduktan sonra Sp1 kurulumuna geçilir.Önce WSS service pack i kurulur.

Son seçilerek kurulum bitirilir.

Kurulumdan sonra windows servisi olarak gelen Office Sahrepoint servera ait 4 adet servis aşağıdaki gibidir.

Sharepoint serverın console unun yapılandırması için sırasıyla şu adımlar yapılmalıdır.İlk olarak Yönetim Merkezi konsolu açılır.Burada Sharepointin tüm servisleri default olarak kapalı olarak geldiğinden servisler enable edilmelidir.

Bu kısımda “İşlemler” menüsü seçilir.

“Sunucudaki Hizmetler” seçeneği seçilerek servislerin olduğu kısma geçilir.

Burda görülen servisler tek tek manuel olarak başlatılır.

Servisleri başlattıktan sonra Sharepoint serverın özellikle mail haberleşmesinde kullanacağı gelen ve giden mail hesapları oluşturulmalıdır.Önce giden posta hesabı oluşturulur.

Tamam seçilir ve ardından Gelen posta ayarlarına geçilir.

Yönetim merkezi konsolundan Sharepoint uygulamalarına temel teşkil edecek ilk web sayfası ve SSP uygulaması oluşturulmalıdır.Bunun için Uygulama Yönetimi kısmı seçilir.”Web Uygulaması oluştur veya genişlet” seçeneği seçilerek default bir web site oluşturulur.

Bu kısımda “Yeni web uygulaması oluştur” seçilir.

Default web sitesinin ayarları bu bölümde yapılmaktadır.

Tamam seçilir.

Default web site oluşturulduktan sonra bu site ın kullanacağı içeriği belirleyecek olan site kolleksiyonu oluşturulmalıdır.Bunun için “Site kolleksiyonu oluştur” seçeneği seçilir.

Bu kısımda sitenin kullanacağı port,hangi kullanıcı ile sitenin servisinin çalışacağı,kullanacağı database gibi bilgiler girilir.

 

Sharepoint serverın çalışabilmesi için önemli bir ayarda SSP(Shared Service Provider) uygulaması yaratılmasıdır.Bu sharepoint serverın servisinin web tarafından ayarlanması ile mümkündür.Web konsolundan “Paylaşılan Hizmetler Yönetimi ” kısmına tıklanır.

Yeni SSP seçeneği seçilir.

Tamam seçilerek SSP yaratılmış olur.

Bir sonraki makalemde görüşmek üzere.

Cenk BALCI

WSS Ürünün kurulumu ve genel özellikleri hakkında bilgileri daha önceki makalelerimde sizlerle paylaşmıştım. Bu makalemde ise artık kurulumunu yaptığımız WSS ürününün şirket içerisinde kullanıma hazır bir hale nasıl getireceğimize değineceğim.

 

Sisteminize WSS kurmanız halinde IIS üzerinde aşağıdaki gibi yeni iki adet site karşımıza çıkmaktadır.

 

 

Yine kurulum sonrası aşağıdaki dizinde ise bu iki web sitesine ait dosyalar yer almaktadır

 

 

 

IIS Üzerinde görüldüğü üzere var olan sitenin dışında biri yönetim amaçlı olmak üzere iki yeni web sitemizin olduğunu görüyoruz.

 

Bunlardan ilki olan “Central Administration” ; yeni sharepoint siteleri tanımlamak , var olan siteler için yeni içerikler oluşturmak , servis ve sunucu ayarları gibi temel görevleri yerine getirmek amacı ile kullanacağımız yönetim sayfasıdır. Diğer web sitemiz ise kurulum ile beraber gelen örnek bir sharepoint sitesidir.

 

 

Yönetim Sayfası

 

 

Örnek Sharepoint Sitesi ;

 

Burada dikkatimizi çeken bir noktada kurulum sonrası varsayılan ve IIS kurulumu ile gelen web sitemizin artık çalışmıyor olması . Bunun sebebi gerek varsayılan sitemiz gerekse sharepoint kurulumu ile beraber gelen örnek sitenin aynı portu kullanarak yayın yapıyor olması ( http – 80 nolu port ) . Bir port üzerinden host header olmadan birden çok site yayınlayamadığımız için varsayılan sitemiz durmuş bulunuyor. WSS kurulumunun hemen ardından böyle bir sorun yaşıyor iseniz bu iki siteden birine aşağıdaki şekilde görüldüğü gibi bir host header eklemeniz yeterli olacaktır ( bu adresi dns üzerinde de tanımlamanız gerekiyor ki şirket çalışanları bu adres üzerinden siteye erişebilsinler ) .

 

 

Bu işlemin ardından DNS üzerinde ilgili zone’u tanımlamak ve gerekli A kaydını açmak işlemin tamamlanması için yeterli olacaktır.

 

 

Bu işlemin ardından WSS kurulumu ile servis vermeyi durduran varsayılan web sitemizde servis vermeye devam etmektedir.

 

Şimdi ise WSS kurulumu ile gelen ilk Sharepoint Web sitemizi açalım ; ( kullanıcı adı ve şifre bilgisi için yerel makinede veya domain ortamı var ise domain de yetkili bir kullanıcı ile giriş yapabilirsiniz. Çünkü bu site için Administrator kullanıcısı dışında bir kullanıcı ne ziyaretçi olarak nede sitenin bir üyesi olarak tanımlı değildir ) .

 

Bu site kurulum ile gelmiş olup istersek gerekli değişiklikleri üzerinde yapabiliriz ancak biz kendi sitemizi oluşturup onun üzerinde çalışmalar yapacağız.

 

Evet artık kendi sitemizi oluşturmaya başlayalım ;

 

İlk olarak Central Administration sayfasından Application Management sekmesinin hemen altında yer alan “Create or Extend Web Application” bölümüne tıklayalım.

 

Hemen ardından aşağıdaki gibi bir pencere ile karşılaşıyoruz ;

 

Buradan “Create a new Web application” linkine tıklayıp bir sonraki sayfaya geçiyoruz ;

 

 

Bu bölümde ilk olarak IIS üzerinde var olan ancak içerisinde Sharepoint bileşenleri yüklü olmayan sitelerin herhangi birini seçmemizi sağlayan açılır bir menü görüyoruz. Yani özetle size ; oluşturacağınız bu yeni Sharepoint sitesi IIS üzerinde zaten var olan bir site üzerine mi yüklensin yoksa tamamen yeni bir web sitesi mi oluşturulsun. Bu açılır menüde şu anda var olan 3 web sitesinden yanlızca “Default Web Site” seçilebilir ; çünkü onun dışındaki diğer iki site zaten WSS tarafından kuruldu ve içerisinde Sharepoint bileşenlerini barındırıyor.

 

Ben burada seçim olarak tamamen yeni bir web sitesi oluşturmak istediğimi belirtiyorum ve sitenin IIS üzerindeki açıklaması için ( sadece tanımlayıcı bir isimdir ) “cozumpark.com” yazıyorum ve hemen ardından yayın yapacağı port olan “80” nolu portu tanımlıyorum. Tabiki bu port üzerinden yayın yapan iki web sitesi daha hali hazırda IIS üzerinde tanımlı olduğu için ben siteme hemen bir host header tanımlıyorum ve bu adres benim için kullanıcıların benim web siteme erişmek için kullanacağı adres olacaktır ; “www.cozumpark.com” . Bu tanımlamadan sonra ise bu web sitesi için dosyaların nerede saklanacağını tanımlıyorum. Alt bölümde ise ;

 

 

Siteye giriş esnasında gerçekleştirilecek olan kimlik doğrulama için hangi kimlik doğrulama yönteminin kullanılacağını ve bu sitenin anonim erişime açık olup olmayacağına karar veriyorum. Ayrıca eğer bu site için SSL kullanmayı düşünüyorsanız buradan veya kurulum tamamlandıktan sonra buradaki hemen hemen bütün ayarlarda olduğu gibi IIS üzerinden bu ayarıda değiştirebilirsiniz.

 

 

Bu bölümde ise yeni web siteniz için ortam havuzu ayarlayabilirsiniz. Yani bu web sitesi için donanım kaynaklarını diğer sitelerden bağımsız olarak yönetmek istiyorsanız bunu tercih edebilirsiniz. Veya varolan ortam havuzlarından birini seçerek devam edebilirsiniz.

 

 

 

Son bölümde ise bu web sitesi için veri tabanı bilgileri , varsa sql ile bağlantı bilgileri ve arama servisinin hangi makine üzerindeki servis olacağını seçebilirsiniz. Bu işlelerin sorununda sitenizi oluşturmuş oluyorsunuz.

 

 

Site oluşturma işleminin ardından yukarıdaki gibi bir uyarı ile karşılaşıyoruz. Burada bahsedilen konu ; site oluşturmuş olsanız dahi içeriği boş olduğu için sitenin içini doldurmak adına mutlaka bir “collection” oluşturmak zorundayız. Bunun için ilgili linke tıklamak ve aşağıdaki yönergeleri takip etmeniz gerekmektedir ;

 

 

Sitemize açıklayıcı bir isim ve tanımlama bilgisini giriyoruz.

 

 

WSS yüklemesi ile beraber gelen ( Collaboration – Meetings ) veya bizlerin daha sonra yüklediğimiz bir çok ( application templates ) şablon site içerisinden bizr uygun olanı seçiyoruz. Buradaki menüler dil ayarlarına görede değişiklik göstermektedir. Yani eğer siz WSS kurulumunun hemen ardından birde Türkçe yama paketini yüklerseniz aşağıdaki gibi türkçe seçeneğini seçtiğinizde size sadece elinizde mevcut türkçe şablonları gösterecektir ;

 

 

Bu seçimlerin ardından bu site için bir veya iki yönetici tanımlayıp gerek duyuyorsak kota tanımını yapıp ( önceden central administration bölümünden kota şablonlarını tanımlamanız gerekli ) collection kurulumunu tamamlıyoruz.

 

 

Son bölümde artık sitemizi ziyarete açabiliriz ( dns üzerinde www.cozumpark.com için kayıt açmayı unutmayın ).

 

Yine karşımıza bir kimlik logon penceresi gelir ve siz yine yetkili bir kullanıcı ile giriş yapabilirsiniz.

 

 

Artık içinde bir Collection olan sitemiz hazır. Bir collection dememin sebebi bu site içerisine birden çok collection açabiliyor olmam. Sharepoint mimarisinde Açtığınız bir site içerisine bir collection ve bu collection içerisine ise pek çok alt siteler açabilirsiniz. Veya bir site içerisine birden çok collection açarak yine bu collectionların içine alt siteler açabilirsiniz.

 

Bu kavramları daha iyi anlamak için aşağıdaki şekli kullanabiliriz

 

 

Bu şekilde Shrapoint yapısındaki “Web Application” , “Web Site Collection” , “Sites” ve “Subsites” kavramları son derece açık bir şekilde çizilmiştir.

 

Kapsam olarak ise aşağıdaki şekilde de gösterilebilmektedir ;

 

1. Web Application

1.1 Site Collection (SPSite)

1.1.1 Site (SPWeb)

1.1.2 Site (SPWeb)

1.2 Site Collection (SPSite)

1.2.1 Site (SPWeb)

1.2.1.1 Sub Site (SPWeb)

1.2.1.2 Sub Site (SPWeb)

Yukarıdaki örnekte bir adet Web Application içerisinde iki adet site collection bulunmakta ve ilk site collection içerisinde iki adet site bulunmaktadır. İkinci site collection içerisinde ise bir tane site ve o site a ait olan iki tane subsite görünebiliyor.

 

Peki biz ne zaman collection açmalıyız ne zaman subsite yapmalıyız ? Bir site yaptınız ( web application ) ve içine gerekli olan ilk collection’ı yüklediniz artık elinizde bir web application ve bir web site collection var. Peki bunun içine 20 ayrı site açabilirmiyiz ?  tabiki açabiliriz. Peki bir bu kadar collection açıp içlerine siteler ekleyebilirmiyiz ? yine sorunun cevabı evet olacaktır. Bu durumda collection ‘ı ayıran en önemli özellik kotalardır. Yani eğer farklı sitelere ( şirket bölümleri , eğitim bölümleri , vb ) farklı kotalar uygulamak istiyorsanız ayrı collection’lar açmak zorundasınız ( bu aslında yapılabilir ancak biraz yazılım bilgisi gerekmektedir ) . Bunun dışında gerek güvenlik gerekse diğer konular için collection açmanıza gerek yoktur.

 

Şimdi ÇözümPark.com sharepoint sitesi için yeni bir collection oluşturalım ;

 

Central Administration bölümünden aşağıdaki adımları izleyelim ;

 

 

 

Bu bölümde yeni açacağımız collection için bir isim veriyoruz ve burada da görüldüğü üzere ilk collection içeriği ( root dizininde “/” çalışıyor ancak bundan sonrakiler ise “/sites” yolu ile temsil ediliyor ). ÇözümPark sitesi için ilk collection ana sayfası temsil ederken bu açacağım ikinci collection ise makaleleri temsil edecek.

 

 

 

 

 

Bu collection için ihtiyaç duyduğumuz şablonu seçiyor ve kurulumu tamamlıyoruz.

 

 

Artık bir Site içerisinde iki adet collection’ a sahibiz. Ancak bu iki collection yapı gereği birbirinden bağımsız olduğu için aynı sayfa üzerinde görüntülenmeyecektir.

 

Ana Sayfamız ;

 

 

Ve yeni açtığımız collection

 

 

Yukarıdaki iki şekle baktığımızda zaten collection kavramını bir kez daha anlamış oluyoruz. Görüldüğü gibi birbirinden bağımsız iki ayrı site gibi görünmektedir ki isterse birbirleri arasına link koyarak bu siteleri bağlayabiliriz. Yani ana sayfaya ( www.cozumpark.com) makale collection için bir bölüm , makale bölümüne ise ( www.cozumpark.com/sites/makale/) ana sayfa için bir link koyabiliriz .

 

Şimdi makale collection’ını gibi yeni bir collection daha açıyorum ve ismini forum olarak belirliyorum.

 

Son durumda onunda resmi aşağıdaki gibidir ;

 

 

Son durumda bir ana sayfa ( ve içerisinde bir collection = root collection “/” ) ve altında iki adet collection açmış bulunuyoruz. Oysaki bunu bir ana sayfa ve altında root collection içine subsite ile bu işi aynı şekilde yapabilirdik. Böyle bir durumda tek ana sayfa ( ve içerisinde bir collection = root collection “/” ) ve bunun içinde iki tane alt site olacak ve şu andaki durumda tek farkı kota uygulaması olacaktı. Eğer her bir sitenin fiziksel disk üzerinden ne kadar alan kullanacağına dair bir yönetim planı yapmayacaksanız ayrı collection açmanıza gerek yoktur .

 

Şimdi ise root dizini altına iki tane alt site açacağım ( yani collectionların bir nevi olmadığını düşünüyorum root altına iki tane alt site açacağım ) .

 

Bunun için root yani ana sayfada site ayarları sayfasına geliyorum ;

 

 

 

 

 

Sitemiz için bir isim belirliyoruz ve gerekli şablonu seçiyoruz ;

 

Bu bölümde ise önemli bir nokta bulunmaktadır. Pek çok kişi collection ları güvenlik nedenleri ile kullanmaktadır. Yani sanki Active Directory yapısındaki farklı forestlar gibi. Burada anlatmak istediğim şudur ki ; eğer iki ayrı collection varsa ortamda zaten onların güvenlik izinleri birbirinden bağımsız bir şekilde çalışır. O kadar ki siz ayarlamadığınız sürece bu collection içindeki siteler birbirilerini dahi göremezler. Bu nedenle bir site içerisindeki alt siteleri güvenlik nedenleri ile ayırmak içinde collection kullanılabilir. Ancak ben bunun bir neden olacağından bahsetmedim . Çünkü bu bölümden de göreceğiniz gibi siz isterseniz aynı collection içindeki sitelerin yukarıdan izin almayarak kendine özel izinlerin tanımlanmasını sağlayabilirsiniz. Buradaki gerekli seçenekler tamamen sizin yönetim planlarınız doğrultusunda değişebilir.

 

Sitemizin açıldıktan sonra ana sayfadaki durumu aşağıdaki gibidir ;

 

 

Bunun gibi hemen ikinci bir site daha oluşturdum ve son durum aşağıdaki gibidir ;

 

 

Bu arada “Wiki sayfaları” nedir diye düşünüyorsanız ; ben değişiklik olsun diye açtığım her site veya collection için farklı bir şablon seçmeye gayret gösteriyorum.

 

Son durumda ana sayfa ise aşağıdaki gibidir ;

 

 

Yukarıdaki şekil bize ; bir web application içinde root collection içinde iki site olduğunu gösteriyor ve tabiki bizim bildiğimiz ama burada görünmeyen iki collection ve içlerinde root siteler var. Bu makale yardımı ile artık WSS üzerinde web application , collection , site ve subsite kavramlarını anlamış bulunuyoruz. Bir sonraki makalemde ise güvenlik konuları üzerinde duracağım. Bir sonraki Sharepoint makalesinde görüşmek üzere.

Hakan UZUNER

Sharepoint içerisinde özel içeriklerin görüntülenebilmesi ve kişiselleştirilebilme için webpartları kullandığımızdan daha önce söz etmiştik. Hazırladığımız webpartlarda dinamikliğin sağlanabilmesi için “EditorPart” veya “ToolPart” olarak adlandırabileceğimiz, webpartın önyüzünde görüntülenmeyen ancak düzenleme modundayken görebildiğimiz bir konsolu vardır. Bu konsol içerisinde Appearance, Layout ve Advanced isminde varsayılan tablar her zaman bulunur ancak bizde bu bölüme yeni kontroller ekleyebilir ve bu kontrollerde yapacağımız değişikliğin webpart içerisinde aktif hale gelmesini sağlayabiliriz.

Örneğin Sharepoint’te yer alan bir listedeki verileri çeken ve sizin istediğiniz farklı bir görünümde gösteren bir webpart yazdığımızı varsayalım. Sharepoint’te yer alan 100 tane listeniz varsa ve hepsinde aynı görünüm değişikliğini yapmak istiyorsanız 100 farklı webpart yazmanız gerekir. Oysa ToolPart’ı kullanarak okunacak listeyi parametre olarak geçebiliecek olursa tek bir dinamik webpart yazıp her sayfada webpartın okuyacağı liste özelliğini değiştirip aynı webpartı tekrar tekrar kullanabiliriz.

Toolpart içerisinde pek çok kontrol türünden ASP.Net kontrolleri yaratabilirsiniz. Textbox, dropdownlist, checkbox, radiobutton gibi. Şimdi bir toolpart nesnesini projemize nasıl ekleriz ve yukarıda bahsettiğim türde farklı veri türlerini barındıran toolpart kontrollerini nasıl yaratabiliriz bunu örnekleyelim.

TextBox Türünde

private string _myString;

[Category("Custom Properties")]
[DefaultValue(c_MyStringDefault)]
[WebPartStorage(Storage.Personal)]
[FriendlyNameAttribute("Custom String")]
[Description("Type a string value.")]
[Browsable(true)]
[XmlElement(ElementName = "MyString")]
public string MyString
{
get
{
return _myString;
}
set
{
_myString = value;
}
}

Checkbox Türünde

private bool _myBool;

[Category("Custom Properties")]
[DefaultValue(c_MyBoolDefault)]
[WebPartStorage(Storage.Personal)]
[FriendlyNameAttribute("Custom Boolean")]
[Description("Select to set value to True.")]
[Browsable(true)]
[XmlElement(ElementName = "MyBoolean")]
public bool MyBool
{
get
{
return _myBool;
}
set
{
_myBool = value;
}
}

DropDownList Türünde

public enum myFarmEnum
{
barn = 0,
tractor,
hay,
pitchfork
};

[Category("Custom Properties")]
[DefaultValue(myFarmEnum.hay)]
[WebPartStorage(Storage.Personal)]
[FriendlyName("Custom Enum")]
[Description("Select a value from the dropdown list.")]
[Browsable(true)]
public myFarmEnum MyEnum
{
get
{
return _myEnum;
}
set
{
_myEnum = value;
}
}

DateTime Türünde

private System.DateTime _myDateTime;

[Category("Custom Properties")]
[WebPartStorage(Storage.Personal)]
[FriendlyNameAttribute("Custom Date Time")]
[Description("Type a DateTime value.")]
[Browsable(true)]
[XmlElement(typeof(System.DateTime))]
public System.DateTime MyDateTime
{
get
{
return _myDateTime;
}
set
{
_myDateTime = value;
}
}

Yukarıdaki örnekler ve birkaç farklı örneği projemize eklediğimizde aşağıdaki şekilde bir ekran görüntüsüyle karşılaşacağız webpartımızın editorpartında.

Toolparta girdiğimiz bilgilerin webpartın “Render” metodunda görüntülenebilmesi için ise standart .Net bilgimizden başka bir şeye ihtiyacımız yok.

protected override void RenderWebPart(HtmlTextWriter output)
{
output.Write(“<b>Stored Property Values</b>”);
output.Write(“<br><b>String: </b>” + this.MyString);
output.Write(“<br><b>Boolean: </b>” + this.MyBool.ToString());
output.Write(“<br><b>Int: </b>” + this.MyInt.ToString());
output.Write(“<br><b>Float: </b>” + this.MyFloat.ToString());
output.Write(“<br><b>DateTime: </b>” + this.MyDateTime.ToString());
output.Write(“<br><b>Enum: </b>” + this.MyEnum.ToString());
output.Write(“<br><b>Color Enum: </b>” + this.MyColor.ToString());
}

Evren AYAN
WSS Architecture MVP, ISPA Regional Evangelist

Microsoft Office Sharepoint Designer 2007, Microsoft Office Sharepoint Server 2007 ve Windows Sharepoint Services 3.0 üzerinde pek çok özelleştirme işleminin yapılabilmesi için tek araç konumundadır.

Microsoft’un Office 2007 ürününde Frontpage’e yer vermemesi ve Frontpage’in üstlendiği görevlerin tamamına ek olarak MOSS 2007 ve WSS 3.0 üzerinde özelleştirme çalışmaları için de bu aracı adreslemesi bunda temel sebeptir.

Teknik anlamda Sharepoint Designer’ın tek ürün olma sebebi ise Sharepoint sistemlerinde sayfa, stil dosyası, imajlar, içerikler gibi tüm yapıların veritabanında binary formatta tutulması ve bu binary dosyalar üzerinde güncelleme yeteneğinin sadece bu üründe yer alması gösterilebilir.

Sharepoint Designer aracılığı ile Sharepoint sistemleri üzerinde tasarım özelleştirmesinin yapılabilmesinin yanı sıra bazı etkin kullanıcı ve yönetici eylemleri de bu ürün aracılığı ile yapılabilmektedir. Örneğin doküman kütüphanesi, liste, anket gibi Sharepoint öğelerinin yaratılabilmesi, sitelerin yedeğinin alınabilmesi, yeni sayfa ve layoutların yaratılabilmesi bu eylemlere örnek olarak gösterilebilir. Yine Sharepoint Designer aracılığı ile yapılabilecek eylemlerden bir tanesi de iş akışlarının hazırlanabilmesi ve bu iş akışlarının mevcut sistem üzerindeki liste ve kütüphanelere deploy edilebilmesidir.

SHAREPOINT DESIGNER İŞ AKIŞI YETENEKLERİ

Microsoft Office Sharepoint Designer aracılığı ile yaratılabilecek iş akışları in-browser iş akışlarına göre bazı temel farklılıklar ve artılar gösterir. İki iş akışı arasındaki temel farklar aşağıda listelenmiştir.

• In-browser iş akışlarında herhangi bir iş akışı koşulu belirtilemezken Sharepoint Designer iş akışlarında kütüphane veya listedeki alanlara ilişkin koşullar tanımlanabilir. (Örneğin masraf formunun 500 YTL’den büyük bir tutara sahio olması durumu gibi)
• In-browser iş akışlarında görev formu sabit iken (onay/red, yorum gibi alanlar) Sharepoint Designer iş akışlarında özelleştirilmiş görev formları aracılığı ile kullanıcıdan daha fazla bilgi toplanabilir.
• In-browser iş akışlarında organizasyon hiyerarşisi gibi iş akışlarında dinamikliği sağlayacak yapılar sunmak son derece zorken Sharepoint Designer iş akışlarında bu tip bilgiler dışarıdaki veya içerideki bir kaynaktan okunarak iş akışına dahil edilebilir.
• In-browser iş akışlarında iş akışı esnasında yapılabilecekler kısıtlıyken Sharepoint Designer iş akışlarında 21 adet temel ve eklenebilecek özel aktiviteler ile pek çok sayıda özel aktivitenin gerçekleşmesi sağlanabilir. (Örneğin liste öğesinin güncellenmesi, log kaydının girilmesi, iş akışının bekletilebilmesi gibi)

Yukarıda sayılan farklar sebebiyle Sharepoint ortamında iş akışı hazırlanması konusunda en çok tercih edilebilecek yöntemlerden bir tanesi Sharepoint Designer iş akışlarıdır. Bu türün daha da gelişmişi olarak adlandırabileceğimiz bir diğer yöntem ise Windows Workflow Foundation kullanarak iş akışları geliştirmektir ki .Net Framework 3.0 / 3.5 bilgisi gerektirmesi ve sonuç itibariyle kod yazıyor olmanız sebebiyle development süresini uzatacak ancak diğer yandan çok daha esnek yöntemleri kullanabileceğiniz bir iş akışı geliştirme ortamıdır.

Microsoft Office Sharepoint Designer 2007 kolay bir arayüzde tek bir satır kod yazmaya gerek kalmaksızın iş akışlarını oluşturmanıza ve deploy etmenize imkan verecek şekilde tasarlanmıştır. Özel aktivitelerin yazılabiliyor ve eklenebiliyor olması aracın varsayılan özelliklerinin dışında da yeteneklere kavuşabilmesini sağlayacaktır.

SHAREPOINT DESIGNER ILE İŞ AKIŞI GELİŞTİRMEK

Microsoft Office Sharepoint Designer 2007 ile iş akışı geliştirmek için öncelikle iş akışını hangi kütüphane veya liste üzerinde çalıştırmak istediğinizi belirlemeniz gerekir. Çünkü Sharepoint Designer’da iş akışı, tasarım özelleştirmesi gibi işlemler site bazında yapılır. İlgili kütüphane veya listeye karar verildikten File>New>Workflow seçeneği aracılığı ile yeni iş akışını yaratacağınız sihirbaz karşınıza getirilir.

Bu ekranda iş akışına o site için tekil bir isim vermeli ve iş akışının hangi liste veya kütüphane üzerinde çalışacağını belirtmelisiniz. İş akışı sisteme deploy edildikten sonra bu iki alandaki değerler değiştirilemeyecektir.

Bu temel bilgileri verdikten sonra iş akışının başlama şeklini seçmeniz gerekir. Üç farklı şekilde başlatılabilir Sharepoint Designer iş akışları:

1. Manuel : Bu durumda kullanıcı liste veya kütüphanede ilgili öğenin üzerindeki menüyü açar ve “Workflows” butonuna tıkladığı zaman birazdan tasarlayacağınıziş akışını listede görür. İsterse o anda sadece ilgili öğe için manuel bir iş akışı başlatabilir.
2. “Created” Anında : Bu durumda iş akışı seçtiğiniz kütüphane veya listeye atanır ve deploy anından itibaren o liste veya kütüphanede yaratılacak tüm öğeler için otomatik olarak çalışır.
3. “Modified” Anında : Bu durumda iş akışı seçtiğiniz kütüphane veya listeye atananır ve deploy anından itibaren o liste veya kütüphanede değiştirilecek tüm öğeler için otomatik olarak başlar.

Aynı ekranda üç adet konfigürasyon butonu da görmekteyiz. Bunlar aşağıda belirtilen işlemler için kullanılmaktadır.

1. Check Workflow : İş akışı içerisinde herhangi bir hata yapılıp yapılmadığını denetler. İş akışı sihirbazının devamında da sürekli olarak görünür. Bir iş akışını deploy etmeden önce bu butona tıklayarak çalışmayı engelleyici bir hata yapıp yapmadığınızı görebilirsiniz.
2. Initiation : İş akışının initiation yani başlangıç aşamasında çalışacak formu tasarlamanızı sağlar. Özellikle bir iş akışı manuel olarak kullanıcı tarafından başlatılacaksa initiation formunu başlangıç anında kullanıcıdan alması gereken bilgilere göre konfigüre edebilirisiniz. Butona tıklamanızın ardından bir sihirbaz başlatılacak ve iş akışı başlatılırken kullanıcıya gösterilip veri toplanacak formun alanlarını oluşturmanız sağlanacaktır.
3. Variables : İş akışı değişkenlerini yaratmanıza olanak tanır. İş akışının devamı boyunca kullanıcıdan topladığınız bilgileri veya iş akışı içerisinde çalıştırdığınız aktiviterlerden dönen sonuçları burada yaratacağınız değişken listesinde depolayabilirsiniz.

Tüm bu ana konfigürasyonları yaptıktan sonra “Next” butonuna tıklayarak iş akışında tanımlayacağınız koşulları ve bu koşullara karşılık iş akışının çalıştıracağı aktiviteleri tasarlayabilirsiniz.

Bu bölümde ekranın sağ köşesinde gördüğünüz “Workflow Steps” kısmı iş akışındaki mevcut adımlarınızı görüntüler ve yeni adımlar yaratabilmenizi sağlar. Böylelikle iş akışı esnasında karmaşık bir tasarım yerine adım adım ilerlemeleri tasarlayabilmenize olanak tanır.

Ekranın sol bölümü ise seçili adımda iş akışının yapması gereken koşul kontrolleri ve bu koşullara ilişkin çalıştıracağı aktiviteleri gösterir. Burada “Conditions” alanını kullanarak iş akışının üzerinde çalıştığı liste veya kütüphanede bulunan alanların değerlerini karşılaştırabilip üzerinde koşul çalıştırma işlemi yapabileceğiniz gibi farklı kütüphane ve listedeki alanlar için de bu işlemi gerçekleştirebilirsiniz.

Aynı bölümde yer alan “Actions” butonu aracılığı ile ise üstte seçmiş olduğunuz koşulun gerçeklemesi durumunda iş akışının alması gereken aksiyonları sıralayabilirsiniz. Örneğin koşul kısmında listede yer alan “Tutar” alanının “500” değerinden büyük yada küçük olması koşulunu sorgulayabilir ve bu koşul doğru ise o anki öğe için alttaki Actions bölümünde bir kullanıcıya görev oluşturması, aynı kullanıcıya email ile görevi bildirmesi, iş akışı loglarına görevin yaratıldığına dair bir mesaj yazmasını ve görevin atandığı kullanıcının bir aksiyonu yerine getirmesini beklemesini söyleyebilirsiniz. Gerekli aksiyon yerine geldiğinde siz ikinci iş akışı adımında yeni bir koşul ve yeni aksiyonları tanımlamış olabilirsiniz.

Bu bölümde seçilecek aksiyonlar 21 varsayılan ve bunun üzerinde sizin ekleyeceğiniz özel aksiyonlar olabilir. Dolayısıyla Sharepoint Designer’ın varsayılanları ile sınırlı kalmayıp edineceğiniz veya yazacağınız özel aksiyonlar ile iş akışının kendi sistemleriniz ile entegre olmasını sağlayabilirsiniz. Örneğin yazacağınız özel bir aktivite aracılığı ile iş akışına konu olan öğaye ait bilgileri bir veritabanı sistemine yazdırabilirsiniz.

ŞAYET GÖREV ATANAN BİR İŞ AKIŞINIZ VAR İSE

Sharepoint Designer aracılığı ile yaratılan iş akışları her zaman görev atama yönünde ilerlemez. Bazen bir öğenin yaratılmasını takiben o öğe üzerindeki yetkileri değiştirmek veya o öğenin yaratıldığından bazı kullanıcıları haberdar etmek de bir iş akışı olarak adlandırılabilir.

Eğer hazırladığınız iş akışında bir kullanıcıya görev ataması yaptıysanız ve Sharepoint Designer tarafında ikinci bir iş akışı yaratmanızı gerektirecektir. Zira ilk yarattığınız iş akışı normal bir liste veya kütüphane üzerinde çalışırken bu iş akışı içerisinden bir kullanıcıya görev oluşturduğunuzda görev öğesi bir görev listesinde yaratılacaktır. Yani yarattığınız iş akışının kontrolünde olmayan bir yerde. Bu durumda Görev listesi üzerinde çalışacak ikinci bir iş akışı yaratabilir ve yaratılan görevin durumuna göre ilk yaratılan iş akışı ile entegre olmasını sağlayabilirisiniz.

Evren AYAN
WSS Architecture MVP, ISPA Regional Evangelist

Sharepoint amacı ve yapısı itibariyle bir veritabanı gibi çalışır. Çünkü kurumsal veya topluluk amacınız ne olursa olsun Sharepoint’i kullanım amaçlarınızdan bir tanesi de içerikleri yönetmektir. İçerik yönetimi diyoruz farkındaysanız “Doküman Yönetimi” değil. Çünkü “İçerik Yönetimi” tabiri ile sadece doküman olmayan ve saklamayı hedeflediğimiz liste türündeki verileride Sharepoint içerisinde saklıyor ve yönetiyoruz. Örneğin şirketinizin kütüphanesinde yer alan kitap ve dergileri Sharepoint siteniz aracılığı ile paylaştığınızı varsayarsak burada sakladığınız şey bir doküman değil kitapların Yazar, Sayfa Sayısı, ISBN Numarası, Yayınevi gibi profil bilgileridir.

Sharepoint’in bilgileri saklayan bir yapıda olduğunu söylediğimize göre bu bilgilere Sharepoint içerisinde yarattığımız web partlar veya Sharepoint dışındaki uygulamalarımızdan da erişebilmeyi isteriz. Aynı örnekten devam edecek olursak şirket kütüphanesinde yer alan kitapların profil bilgilerini Sharepoint sitemiz aracılığı ile saklıyoruz ve aynı zamanda bu bilgilere yazdığımız bir Windows veya Web uygulamasından da erişmek istiyoruz. Tıpkı bir veritabanından bu bilgileri okur gibi. Bu işlem için iki temel yöntem kullanabiliriz.

• Sharepoint Object modeli aracılığı ile ilgili uygulamaya bağlanıp Microsoft.Sharepoint.dll içerisindeki metodlar ve sınıflarla bu veriye erişmek
• Sharepoint uygulamamızın sunduğu ve ISAPI klasörü içerisinde yer alan Sharepoint web servisleri yardımıyla bu veriye erişmek

Biz burada Web Servisleri aracılığı ile veriye erişmeye ve verileri listelemeye çalışacağız. Bu işlem için öncelikle Sharepoint sitemiz içerisinde bir liste yaratıyoruz ve bu listeyede özel kolonlar ekleyip yukarıda bahsettiğimiz yazar, yayınevi, sayfa sayısı gibi bilgileri ekliyoruz. Listeyi oluşturalım ve okuyabileceğimiz birkaç test verisini ekleyelim.

Şimdi bu verileri okuyacağımız bir Windows uygulaması yaratalım kendimize Visual Studio içerisinden.

Formumuzunda tasarımı tamamlandıktan sonra referans olarak Sharepoint kurulumu ile beraber gelen web servislerinden lists.asmx’i ekliyoruz. Sharepoint web servisleri üzerinde çalışılan siteye göre instance üretir bu nedenle biz ana sayfa üzerindeki lists.asmx’e bağlantı kuracağız ancak sonra kod içerisinde web servis URL’ini manipüle edeceğiz.

Şimdi kod kısmında root site olarak verdiğimiz bu URL’i “Test” sitesine göre değiştireceğiz. Sharepoint üzerinde web servisleri ile işlem yaparken unutmamanız gereken bazı noktalar var:

• Web servislerinizi adresi http://<siteKoleksiyonuAdi>/<siteAdi>/_vti_bin/<servisAdi>.asmx olacak şekilde kullanmalısınız.
• Web servislerini referans olarak eklerken site koleksiyonunun adresine göre eklemeli ve sonra kod içerisinde sitenize göre URL’i değiştirmelisiniz.
• Web servisi ile bilgi çekme veya yazma işlemi yaparken web servisine kod üzerinden yetkili bir kullanıcının credential bilgilerini göndermelisiniz.
• Web servisleri aracılığı ile bilgi okurken alan isimleri ve batch olan herşeyi XML olarak göndermelisiniz.

Kodumuzu çalıştırdığımızda oluşturduğumuz “viewFields” alanı web servis metodumuza gönderilecek ve sadece bu listede verdiğimiz alanlara ait bilgiler XML olarak geri dönecek. Ardından XQuery ile belirttiğimiz

listItems.SelectNodes(“//*[local-name()='row']“)

komutu ile “row” cinsindeki tüm satırları okuyoruz ve datatable a ekliyoruz.

Evren AYAN
WSS Architecture MVP, ISPA Regional Evangelist

ASP.Net 2.0′ın hayatımıza girmesinin ardından .Net Framework içerisinde pek çok yeni kontrol grubu ve alt frameworkler ile çalışmaya başladık. Membership, Webpart gibi alt frameworkler işimizi son derece kolaylaştıran ve development süremizi kısaltan bir yapıyı hizmetimize sunmaya başladı. Aynı dönemde ortaya çıkan pek çok internet sitesinde bu alt frameworklerin kullanım örneklerini gördük ve teşvik edildik. Örneğin Live ürün ailesi içerisinde yer alan “Spaces” bize webpart konusunda örnek sunan ilk sitelerdendi. Sitenin kavuştuğu yeni yapı ile kullanabileceğimiz bölümler webpart olarak geliştirilmiş ve istediğimizi sayfamızda gösterebilir, istediğimizi engelleyebilir hale geldik. Webpartların yerlerini değiştirerek daha kişiselleştirilmiş siteler yaratabildik.

Aslında webpartın ortaya çıkışında temel nedenlerden biri de buydu. Yani sadece site sahibine değil kullanıcıya da sitenin tasarımı ve içeriği konusunda tercihte bulunma hakkı vermek. Bu sayede ben bir portala girdiğimde ana sayfada IMKB Endeksi, Döviz Kuru gibi beni daha çok ilgilendiren bölümleri görmek isterken bir başka kullanıcı aynı bölümlerde Flaş Haberler ve Oyunları görmeyi tercih edebildi.

Microsoft Office Sharepoint Server 2007 ve Windows Sharepoint Services 3.0 altyapısını kullanan sitelerde de hem developmentı parçalar halinde gerçekleştirebilmeyi sağlamak hemde sitelerin kişiselleştirilebilmesine olanak tanımak adına webpart frameworkden yoğun bir şekilde faydalanılmış durumda. Alttaki ekran görüntüsünde Sharepoint ile beraber gelen standart bir “Team Site” ın düzenleme modunu görüyorsunuz. Resimden de göreceğiniz üzere site içerisinde gördüğümüz herşey kutucuklara ayrılmış durumda ve ister kişisel tercihlerle ister yöneticilerin uygun gördükleri şekilde bu kutucukların görünümünde ve yerlerinde değişiklik yapma şansımız var.

 

 

Burada gördüğümüz “Left” ve “Right” ifadeleri WebPartZone olarak isimlendirdiğimiz ASP.Net bileşenlerine karşılık geliyor. WebPartZone kontrolleri birer konteynır görevi üstlenip içerisinde webpartları barındırabiliyor. Dolayısıyla o kadar da özgür olmadığımız anlıyoruz. WebPartZone’lar dışında bir yerde webpartlarımızı görüntülememiz mümkün değil.

Hedefimizi biraz daha Sharepoint odaklı hale getirirsek akla ilk olarak şu soru gelecektir: “Neden Webpart?”

Çünkü webpart hem iç hemde dış verileri görüntüleyebilmek ve bunları modül halinde yazabilmek için elimizdeki men kullanışlı tekniği bize sunar ve Sharepoint sistemlerinde özelleştirme genellikle webpartlar aracılığı ile yapılır. Bazen site içerisinde yarattığınız bir listenin farklı bir şekilde görüntülenebilmesi için webpart yazarsınız bazense tamamen dışarıdaki bir veritabanından bilgileri okumak ve Sharepoint sisteminiz içerisinde göstermek için. Sharepoint’te temel amaç sunulabilen tüm kurumsal bilginin birlikte çalışabilirlik adına tek adresten sunulması olduğundan örneğin bir CRM uygulamanızdaki müşterileriniz için veri girişini hala uygulamanın kendisinden yaparken verilerin sorgulanması işini Sharepoint’e bırakabilirsiniz. Bu sayede CRM uygulamasını sadece veri sorgulamak için kullanacak kullanıcılarınıza CRM clientını kurmaktan kurtulabilir ve her türlü bilgiye tek ekrandan ulaşma prensibini yerine getirebilirsiniz.

Burada konu alnınacak şey webpartın ne olduğu ve temel bir “Merhaba Dünya” webpartının nasıl geliştirilip deploy edileceği konusu. Ancak konu bununla sınırlı değil elbette. Daha ileri aşamalarda daha özelleştirilebilir webpartların, birbirine bağlı webpartlarında örneklerini bulabileceksiniz.

Sharepoint sitenizde yeni bir webpart geliştirmek için öncelikle Visual Studio 2005 veya 2008′de yeni bir “Class Library” projesi yaratıyoruz. Microsoft’un hazırlamış olduğu ve çok daha hızlı webpart geliştirmenizi sağlayabilecek VS 2005 ve 2008 proje templateleri de bulunmakta, isterseniz bu templateleri de kullanabilirsiniz geliştirirken. Projemizi yaratalım.

 

 

 

 

Projenizi ekledikten sonra yapmanız gereken bazı temel referans eklemeleri, using satırı eklemeleri ve WebPart sınıfından kalıtım sağlama eklentilerini yapmamız gerekiyor.Sırasıyla :

• References bölümünde yeni bir referans olarak “System.Web” kütüphanesini ekleyin
• using elemanı olrak “using System.Web.UI.WebControls.WebParts” namespaceini ekleyin
• Sınıfınızın “WebPart” sınıfından referans almasını sağlayın. “TemelWP:WebPart” şeklinde.

 

 

Not : WebPart sınfından referans almak için “System.Web” yerine “Microsoft.Sharepoint” kütüphanesini de tercih edebilirsiniz. Aynı WebPart sınıfını her ikisi de barındırmaktadır.

Şimdi kalıtımı sağladığımız “WebPart” sınıfındaki “Render” metodunu override edeceğiz, yani yeniden kodlayacağız. “Render” metodu webpartın içeriğinin oluşturulduğu metoddur ve string bir ifadeyle HTML olarak her türlü içeriği gönderebilirsiniz. Bu sayede ekrana bir şeyler yazdıralım.

 

 

 

Webpartımız kod itibariyle hazır. Şimdi bunun Sharepoint sistemimiz tarafından kullanılabilir hale gelmesi için deploy edilmesi gerekiyor. Deploy ederken webpart projemizin oluşturduğu “dll” e ihtiyaç duyacağız. Ancak eğer GAC’a deployment yapacaksanız oluşacak assemblyi “sign” etmeniz gerekiyor. Bu işlem için Solution Explorer’da proje üzerinde sağ tıklayıp “Özellikler” penceresine ve burada da “Signing” tabına geliyoruz. “Sign the assembly” checkboxını iaretleyip alttaki dropdownmenüden “New” seçeneğini işaretliyoruz. Karşınıza assemblyniz için oluşturacağınız “snk” uzantılı dosyanın yaratılacağı basit form geldi. Herhangi bir isim verin ve “Protect my key file with a password” checkboxını kaldırın.

 

 

Şimdi projenizi build edebilir ve deployment adımlarına geçebilirsiniz.

 

DEPLOYMENT ADIMLARI

1. Elde ettiğiniz TemelWebPart.dll’i C:\Windows\assembly dizinine deploy edin. Bu işlem için gacutil’i de kullanabilirsiniz. Eğer manuel deploy edecekseniz ilgili klasör copy/paste i desteklemediğinden sürükle/bırak ile işlemi gerçekleştirebilirsiniz.
2. Sharepoint’in hazırladığınız webpartı güvenli bulabilmesi için uygulamanın web.config dosyasında yer alan <SafeControls> bölümüne gitmeli ve webpartınızı tanıtmalısınız. Bu işlem için C:\Inetpub\wwwroot\wss\VirtualDirectories\<UygulamanizinAdi> klasöründe yer alan web.config dosyasını açın, <SafeControls> tagını bulun ve içerisine şu satırı kopyalayın. (Tabi kendi Public Key Toke’ınızla. Public Key Token’a dll’i deploy ettiğiniz GAC’dan ulaşabilirsiniz.)<SafeControl Assembly=”TemelWebPart, Version=1.0.0.0, Culture=neutral, PublicKeyToken=11b24de2dc63fc73″ Namespace=”TemelWebPart” TypeName=”*” Safe=”True” />

3. IIS’i restart edin

4.     

 

5.     

 

6.                 

 

Evren AYAN
WSS Architecture MVP, ISPA Regional Evangelist