SharePoint Projesi Hakkında

Yaklaşık 3 haftadır iyi dostum, iş arkadaşım Kutlu'yla birlikte, bir SharePoint Projesi üzerinde çalışıyoruz. Proje şudur ki; İş Bankası bünyesindeki birimlerin kendi süreçlerini işleteceği bir talep yönetimi mekanizması geliştirmek. İsminin çok cafcaflı olduğuna bakmayın, birçok alandan oluşan basit bir formun Banka içinde dolaşıp, farklı birimlerdeki farklı insanlar tarafından doldurulması işleminden ibaret. Yani bir ASP.NET formu kullanarak gerçeklemenin en fazla birkaç günü alacağı bir uygulama :) Yeni teknoloji takip etmeyi seven bir firma olarak tabii ki zor olanı seçiyoruz ve hiç know-how sahibi olmadığımız bir konu olan SharePoint ile bu sorunu çözmeye çalışıyoruz ;)

3 haftada neler yaptık, kısaca özetlemek gerekirse;

1. Bu SharePoint nedir, ne değildir öncelikle bir araştırma gerekti tabii. Teknolojinin yetenekleri hakkında bilgi edinmeye başladık. Bir sonraki post'umun konusu bu olacak.
   
   
2. Nerede yapacaktık bu SharePoint geliştirmesini? Daha doğrusu custom bir geliştirme yapacak mıydık? Yoksa uzay çağı gelmişti de her şeyi sürükle-bırak'la basit arayüzlerle mi yapacaktık? (Bunu bir kere bile düşünmedik aslen :)) Kısa bir debelenmeden sonra MS 2003 ve VS 2008 içeren bir WM üzerinde geliştirmenin en hızlı çözüm olacağını düşündük. Ancak WM'in yavaşlığı bizi öldürdüğü için kendi sunucumuzu kurma konusunda şirkette taarruza geçtik. Acılı bir kuşatma döneminden sonra elimizde -kurulumunu da kendimiz yaptığımız- bir Win2003, VS 2008, MOSS 2007 (daha sonra buna da değineceğim) içeren 3 GB Ram'li bir SharePoint Sunucusu ve bu sunucuya atanmış Win2008, SQL Server 2008 kurulu 2 GB Ram'li bir SQL Sunucusu vardı. Artık bizi kimse tutamazdı (ya da biz öyle zannediyorduk).
   
   
3. SharePoint hakkında bilgi sahibi olduk tamam. Sunucular da ok. Eee geliştirmeyi nasıl yapacağız bu merette? Projenin deadline'ı çok sıkı (Mart başı) olduğundan ve ikimizin de SharePoint konusundaki tecrübesi sıfıra yakınsadığından stratejik bir karar vererek, pair programming yaklaşımına geçtik. Kararı verir vermez, yeni yerim olan şirketin köşesindeki Kutlu'nun masasına damladım :) SharePoint'te custom kod geliştirme deyince akla ilk gelen kavram olan WebPart'ları incelemeye koyulduk. User control benzeri bu mekanizmaların detayına inmeye gerek yok, ancak geliştirmek için sunucu tarafına Office Server SDK kurduğumuza değinmeden geçmek istemiyorum.
   
   
4. SharePoint mantığını anladıkça listeler, döküman kütüphaneleri, wikiler bize daha anlamlı gelmeye başladı ve ufak tefek örneklerle bu veri yapılarını kullanmaya başladık. Yaptığımız şirket içi harcama onay uygulaması örneğinden biraz bahsetmek istiyorum. Şirketlerde çalışanların yaptıkları harcamaların (taksi, yemek fişi vs.) tutarlarını şirketten tahsil edebilmek için bazı formları doldurup, bu formları yönetici veya IK birimlerinin onayından geçirmek durumundadırlar. Biz bu akışı örnek alarak, SharePoint'te geliştirmeye başladık. Buna göre, geliştirdiğimiz WebPart'ları kullanan SharePoint sayfaları çalışanlardan harcama tutarı, açıklama, tarih gibi bilgileri alacak, bu giriş yapılan formlar bir döküman kütüphanesinde veya custom bir listede tutulacak ve daha sonra bu form onay verilmesi için çalışanın yöneticisine gönderilecekti. Bu assign işlemi içinse SharePoint'teki task list'leri kullanacaktık. Yöneticiler duruma göre bu task list'lerdeki item'ları onaylayacak, duruma göre tutarını güncelleyip onaylayacak, duruma göre de reddedecekti. Aslında çok basit gibi görünen bu mekanizma bir süredir annemizi ağlatmakla meşgul :) Bu örnekte ilerledikte burayı dolduracağım :)
   
   
5. Hadi diyelim WebPart'lar ile sayfaları geliştirdik, user interaction'ı da sağladık. Peki iş akışımız nasıl işleyecek? İşte asıl üzerinde durmamız gereken yere gelmiştik. SharePoint Designer ve VS2008 Workflow mimari ile bu işe girersek acaba işin içinden çıkabilir miydik? Yoksa iş akışı olayını tamamen custom WebPart'lar üzerinde sağlayarak kolaya mı kaçmalıydık (aslında hamallığa)? Tabii ki yine temiz yönetimi seçerek iş akışlarımız SP Designer ve VS2008 WF üzerinde geliştirmeye karar verdik. Ta ki ekip liderimizden aldığımız o acı habere kadar: "Nintex kullanın!"
   
   
6. Nintex, aslında daha önce biraz inceleme fırsatı bulduğum tatlı mı tatlı bir araç. Detayına girmeden biraz bahsedicek olursam, SharePoint üzerinde iş akışları tasarlamaya yarayan, direkt SharePoint sunucusuna kurulan (web arayüzlü), third-party (lisanslaması ayrı) bir zamazingo. Proje takviminin neredeyse ortasında böyle bir karar değişikliğine gidilince, bugün apar topar Nintex kurulumu (tabii ki Trial versiyonu) yaptık sunucumuz üzerine. Bizi çok üzmedi sağolsun ve hemen denemelere giriştik kendisiyle. İlk gözlemlerimiz olumlu ve umuyoruz ki bu projenin altından kalkacak kendisi..

1 Şubat itibariyle resmi olarak başladığımız projede, 15 günde geldiğimiz durum bundan ibaret. Tabii arada, projenin müşterisi olan Banka birimi ile yaptığımız analiz toplantılarını saymıyorum :s