Intel Edison üzerinde Azure Service Bus Queue

Merhaba arkadaşlar,

Bir önceki yazımda Azure Service Bus’ı örnek senaryolarla birlikte elimden geldiğince açıklamaya çalışmıştım. Bu yazımda Intel Edison üzerinden Azure Service Bus Namespace’imizde bulunan bir Queue’ya nasıl veri aktarırız onu anlatmaya çalışacağım.

Bu yazının amacı gereği mesajı bir Intel Edison cihazdan göndereceğiz, bir Console Application‘dan mesajları consume edeceğiz. Yazının bu kısmından sonrasını biraz daha az detaylı anlatacağım, en sonda kaynak kodları paylaşacağım.

Intel Edison üzerinde mesaj gönderecek olan uygulamamızı yazmak için Nodejs kullanacağız. Çünkü Arduino’nun WifiClient, WebClient kütüphanelerinde SSL bağlantıları kuramıyoruz.

Message Sender’ı hazırlayalım

Eğer daha önce hiç Nodejs kullanmadıysanız, sadece beginner seviyesinde olduğumdan sizleri yanlış yönlendirmek istemiyorum. Nodejs hakkında güzel bir giriş yazısı buldum: http://blog.ilkerguller.com/2012/01/nodejs-dersleri-bolum-1-kurulum-ve-ilk.html

Öncelikle Node commant prompt’u açalım ve aşağıdakileri sırasıyla yazalım;

> cd c:\
> mkdir serviceBusMessageSender
> cd serviceBusMessageSender

> npm init

Buradan sonra name, description, version, entry point gibi bilgiler sorulacak. Bunları girdikten sonra;
> touch [entrypoint] yazmanız gerekecek. Örneğin touch index.js.

Böylelikle uygulamamızın giriş noktasını oluşturduk. Şimdi bazı paketler yüklememiz gerekecek.

Uygulamayı oluşturduğumuz dizine gittikten sonra(serviceBusMessageSender) npm’den aşağıdaki paketleri yüklememiz gerekecek.

azure

Nodejs uygulamarında azure servislerini kullanmak için ‘azure’ pakedini yüklememiz gerekiyor.

cylon
cylon-gpio
cylon-i2c
cylon-intel-iot

Cylon paketleri ise bir Nodejs uygulamasından Edison cihazını kontrol edebilmek için kullanıyoruz. 4’ünü birden yüklememiz gerekiyor, birbirine bağımlı paketler. (http://cylonjs.com/)

Bu paketleri de yükledikten sonra entry pointimizi(index.js, app.js veya her ne ise) not defterinde açalım.

index.js
——————–

var azure = require('azure');
var Cylon = require('cylon');

var connstring = 'Endpoint=sb://xxxxx.servicebus.windows.net/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=xxxxx';
var serviceBusClient = azure.createServiceBusService(connstring);


var message = {
 customProperties: {
        TestProperty: new Date()
   }
   };

Cylon.robot({
  connections: {
    edison: { adaptor: "intel-iot" }
  },

  devices: {
    button: { driver: "button", pin: 2 }
  },

  work: function(my) {
    my.button.on("push", function () {
		serviceBusClient.sendQueueMessage('edisondataqueue', message, function(error){
    if(!error){
        // message sent
    }
});

 });
  }
}).start();

Yukarıda öncelikle yüklediğimiz kütüphanelerin referanslarını aldık. Ve daha sonra Service Bus Namespace’imizin connectionString’ini tanımladık. Bu key’i Azure Portal’dan Service Bus Namespace’inize girdikten sonra manage keys bölümünden edinebilirsiniz.

Ve Azure Service Bus üzerinde herhangi bir işlem yapmamıza olanak sağlayan serviceBusClient sınıfından bir nesne türettik.

Cylon paketi sayesinde edison bağlantımızı, cihazlarımızı ve cihaz üzerinde çalışacak fonksiyonelliği tanımladık. PIN 2’deki butonumuza basıldığında yapılacak olan işi tanımladığımız fonksiyonun içinde ise, henüz tanımladığımız serviceBusClient nesnesinin sendQueueMessage metodunu çağırarak Service Bus’taki Queue’muza mesajımızı gönderdik.

Şimdi uygulamamızı edison üzerine göndereceğiz.

Öncelikle edison üzerinde uygulamamız için bir klasör oluşturalım.

> ssh root@192.168.x.x
> mkdir servicebusapp

WinSCP(http://winscp.net/eng/download.php)’yi yükledikten sonra aşağıdaki kodu prompt’a yazarak uygulamamızı Intel Edison’a göndereceğiz ve çalışabilir hale gelecek.

> scp -r serviceBusMessageSender root@192.168.x.x:/home/wwwroot/servicebusapp

Bu komuttan sonra bir süre sonra uygulamamız gönderilmiş olacak.

> cd servicebusapp
> node index.js

Ve uygulamamız çalışıyor, pin 2’deki  butona bastığınızda Service Bus’a mesajın gönderildiğini göreceksiniz.

Consumer uygulamamızı hazırlayalım

  • Consumer uygulamamız C# Console Application olacak. Visual Studio’dan File -> New Project -> Console Application ile uygulamamızı oluşturalım.
  • Solution Explorer‘da projenin üzerine sağ tıklayıp Manage Nuget Packages‘e tıklayalım.
  • service bus‘ yazıp aratalım ve ilk sırada çıkan paketi yükleyelim. Şu anki sürüm: 2.6.5

Paket yüklendikten sonra app.config dosyasında Service Bus Namespace’imiz için ConnectionString’i ayarlamamız gerekiyor.

<appSettings>
<add key="Microsoft.ServiceBus.ConnectionString"
value="Endpoint=sb://xxxxxxx.servicebus.windows.net/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=xxxxxxxx="/>
</appSettings>

 

Program.cs
——————————————–

class Program
    {
        static string _connStr = CloudConfigurationManager.GetSetting("Microsoft.ServiceBus.ConnectionString");
        static void Main(string[] args)
        {
            QueueClient qc = QueueClient.CreateFromConnectionString(_connStr, "edisondataqueue");

            OnMessageOptions options = new OnMessageOptions();
            options.AutoComplete = false;
            options.AutoRenewTimeout = TimeSpan.FromMinutes(1);

            qc.OnMessage((message) =>
            {
                Console.WriteLine("NEW MESSAGE");
                Console.WriteLine("MessageID: " + message.MessageId);
                Console.WriteLine(message.Properties["testproperty"]);
                Console.WriteLine();
                Console.WriteLine();

                
                message.Complete();
            });

            Console.Read();

        }
    }

Uygulamayı derleyip çalıştıralım. Edison üzerinde butona basıldığında Console Uygulamamıza mesajın geldiğini göreceğiz.

Projenin tamamı: http://1drv.ms/1OjAEn6

Bu yazıda Intel Edison üzerinden Service Bus’ta bulunan bir Queue’ya mesaj gönderdik. Faydalı olması dileğiyle.

Fazlasını Oku

Azure Service Bus Queue : Genel Bakış

Merhaba arkadaşlar,

Bu yazımda Azure Service Bus Queue ile ilgili bilgiler vermeye çalışacağım.

Brokered Messaging

Öncelikle Brokered Messaging kavramından bahsetmek isterim. Brokered Messaging altyapısında mesajlar güvenilir bir broker’da –broker’ı aracı olarak çevirebiliriz sanırım– saklanır. Broker, mesajları alacak olan consumer uygulamanın mesajları almaya hazır duruma gelinceye kadar saklar.

Bu mesajlaşma modeli sayesinde dağıtık uygulamalar birbiriyle bağlantılı olmadan çalışır, mesajlarını broker’a gönderir. Dağıtık sistemdeki cihazların birinin bakımı sırasında veya olası bir çökme durumunda bu durumdan tüm sistem etkilenmemiş olur.

Şimdi bir dağıtık uygulama örneği vermeye çalışacağım.

Uluslararası bir lojistik firması olduğumuzu düşünelim ve bize bağlı olan 1000 transport aracı var. Ve biz bu araçların konumlarını 10 saniyede bir almak istiyoruz.

Mevcut senaryoda göre 10 saniyede bir 1000 cihazdan veri alacağız. Bunları alınıp işlenmesi sunucuya çok büyük bir yük olacaktır.

Brokered Messaging modeli uygulandığında bu istekleri karşılayacak bir sunucunun bulunup bulunmaması önemli değildir, cihazların istekleri gönderdiklerinde bir yanıt almaları da şart değildir. Cihaz mesajını gönderir, ve bu mesajı birinin almadığını önemsemez. Herhangi bir yanıt da beklemez, çalışmasına devam eder.

Consumer uygulama –yani mesajları alacak olan uygulama– eğer hazır durumdaysa mesajları anlık olarak alır ve işler. Herhangi bir bakım veya bozulma durumunda ise kuyruktaki mesajlar zarar görmez, hazır olduğunda tekrar mesajları alıp işlemeye devam eder.

Azure Service Bus Queue

Service Bus’ta bulunan Queue’lar –bundan sonra kuyruk diyeceğim– biraz önce bahsettiğimiz bir brokered messaging gerçeklemesidir. Dağıtık uygulamalar tüm mesajlarını bir kuyruk yapısına gönderir. Hepimizin bildiği gibi kuyruklar FIFO – First in First out (İlk giren ilk çıkar) prensibine göre çalışır.

service-bus-queue

Yukarıdaki grafikte gördüğümüz gibi Message Sender: mesaj gönderen uygulama Azure Service Bus Namespace’imizde yer alan kuyruğa mesajları bırakır ve basitçe Message Receiver: mesajları alacak olan uygulama, consumer Queue’dan mesajları alır ve işler.

Queue’nun çalışma modeli gereği consumer uygulama mesajların gönderilme sırasına göre ilk gönderileni öncelikli olarak okur ve kuyruktan siler. (Dequeue)

Mesaj gönderen uygulama bir web sitesi, mobil uygulama veya servis olabilir. Aklınıza gelebilecek olan bütün teknolojileri kullanarak Azure Service Bus Queue’ya mesaj gönderip alabiliyoruz. Zira Azure Service Bus REST API destekliyor.

Azure Service Bus Namespace’i oluşturma

Azure Portal’ında soldaki menüden Service Bus bağlantısına tıklayın.

1

Burası Service Bus Namespace’lerimizi görebileceğimiz ve yönetebileceğimiz sayfadır. Açılan sayfadan Create New Namespace bağlantısına tıklayın.

Azure Service Bus Namespace oluşturma

Açılacak olan formda bizden

  1. Namespace ismi
  2. Bölge
  3. Tip 
  4. Tier* bilgileri isteniyor.

*Tier’ı abonelik pakedi olarak çevirebiliriz, fiyatlandırma ayrıntıları için: Azure Service Bus Fiyatlandırma

Type olarak Messaging‘i seçmemiz gerekiyor, Notification Hub’ı Push notification için kullanıyoruz. İleride bununla ilgili bir yazı yazarsam değinebilirim : ) Tier için ise Basic seçmemiz yeterli olacaktır. Formu gönderdikten yaklaşık 30 saniye sonra Service Bus Namespace’imiz kullanılabilir olacak.

Service Bus Queue Oluşturma

Service Bus Namespace’imiz oluşturulduktan sonra üzerine tıklayıp bu namespace’i yöneteceğimiz sayfaya ilerleyeceğiz.

3

Service Bus Namespace’imizi oluşturduk. Şimdi bir Queue oluşturmamız gerekiyor. Yönetim sayfasından Queues sekmesine gitmemiz gerekiyor.

4

Queues sekmesine gittiğimizde Queue’larımızı burada görüyor olacağız. Tabii ki henüz hiçbir queue oluşturmadığımız için burası boş gelecek. Yeni bir Queue oluşturmak için Create New Queue bağlantısına tıklayacağız.

5

Create New Queue bağlantısına tıkladığımızda karşımıza bir pencere açılacak ve Queue için bilgiler girmemiz istenecek.

6

  1. Queue Name
  2. Region
  3. Namespace

bilgilerini gireceğiz. Queue için bir isim seçtikten sonra Türkiyeye en yakın konum olan West Europe’u seçeceğiz. Namespace için de biraz önce oluşturduğumuz Namespace’i seçeceğiz ki zaten bunlar seçili gelecek. Ve formu gönderiyoruz. Birkaç saniye sonra Queue’muz kullanıma hazır olacak.

7

Artık mesaj göndermeye ve almaya hazırız.

Bu yazımda Azure Service Bus Queue’yu elimden geldiğince açıklamaya çalıştım. Örnek senaryolar vermeye çalıştım. Faydalı olması dileğiyle.

Şu yazımda Intel Edison üzerinden Azure Service Bus Queue’ya mesaj göndermekten ve C# Console Application’dan mesajları consume etmekten bahsettim: Intel Edison üzerinde Azure Service Bus Queue

Fazlasını Oku

Azure Mobile Services .NET Backend : Custom API Oluşturmak

Merhabalar,
Bir önceki yazımda Azure’da barındırılan bir mobil servise nasıl tablo eklendiğinden bahsetmiştim. Bu yazımda ise mobil servise bir Custom api ekleyeceğiz.

Tablo oluştururken önce tablo şablonu için EntityData sınıfında türeyen bir sınıf ekleyip daha sonra bir Controller(Table controller) eklemiştik. Custom api oluştururken ise Custom controller ekliyor olacağız.

Bu yazımda şöyle bir basit senaryo düşündüm.

  • Parametre olarak bir sitenin url’sini alan bir api yazacağız
  • Bu api parametre olarak gelen sitenin başlığını çekecek (<title></title> etiketleri arasını)
  • Çekilen başlığı mobil servisimizin veritabanındaki Titles adındaki tablosuna ekleyecek.

Başlamadan önce mobil servise kullanacağımız Title şablonuna uygun bir tablo ekleyeceğiz. Bu yazının konusu tablo eklemeyle ilgili olmadığı için burayı atlıyorum. Şöyle bir tablo ekledim;

Site ve value alanları sitenin adresi ve başlığı için.

Şimdi solution explorer’da Controllers klasörüne sağ tık yapıp Add -> Controller seçelim.

Bunu yaptıktan bir pencere açılacak, o pencereden Custom controller seçip Add butonuna tıklayalım.

İsim olarak getTitleController verdim. Dikkat edilmesi gereken nokta controller isminin controller ile bitmesi gerekiyor. Bu işlemi de yaptıktan sonra controller sınıfımız açılmış olacak. Default olarak şöyle geliyor:

Gördüğünüz gibi son derece basit bir örnek, api çağrıldığında geriye “Hello” dönecek.

Şimdi apimizi yazının başında verdiğim senaryoya göre düzenleyeceğiz. Api, parametre olarak bir website url string alacak, o url’in <title></title> etiketleri arasındaki veriyi çekecek ve bizim mobil servisimizdeki Titles tablosuna ekleyecek.

 public class getTitleController : ApiController
{
public ApiServices Services { get; set; }

servicesampleContext context = new servicesampleContext();

// GET api/getTitle
public string Get(string url)
{
WebClient client = new WebClient();
string source = client.DownloadString(url);
string title = Regex.Match(source, @"\<title\b[^>]*\>\s*(?<Title>[\s\S]*?)\</title\>", RegexOptions.IgnoreCase).Groups["Title"].Value;

this.context.Titles.Add(new Title { Id = (context.Titles.Count<Title>() + 1).ToString(), Site = url, Value = title });
this.context.SaveChanges();

return url + " basligi eklendi";
}

}

Bu kodda açıklanması gereken bir kaç kısım var. serviceSample benim azure üzerinde oluşturduğum mobil servisin ismi idi. serviceSampleContext ise bu servisimin Data context’i. (Data context kavramından bir önceki makalede bahsetmiştim. Kısaca açıklamak gerekirse Data context bizim tablolarımız arasındaki ilişkiyi kuran yapı. Bir tabloya custom api üzerinden veri eklemek için serviceSampleContext’i kullanmamız gerekecek.)


Kodu düzenlemen önce Get metodu parametre almıyordu, biz onu url parametresini alacak şekilde düzenledik. Daha sonra WebClient sınıfını kullanarak url’in html kaynağını string olarak indirdik. Sonrasında regex ile site başlığını çektik.(İtiraf ediyorum regex patternı ben yazmadım. : ) )

Sonrasında ise context’imizin Titles adlı özelliğine yeni bir Title sınıfı örneği ekledik. Ve bu değişiklikleri kaydetmek için SaveChanges() metodunu çağırdık.

Servisi bu haliyle test ettiğimizde parametre olarak girilen url’in tabloya eklendiğini göreceğiz. Browser üzerinden apiye direk çağrıda url’de : ve // karakterleri olduğundan izin verilmiyor, bu sebeple mobile services’ın test aracını kullandım.

Bu apileri client üzerinden nasıl çağrıldığına, nasıl parametreler gönderildiğine önümüzdeki günlerde değineceğim fakat kısaca bahsetmek gerekirse

Mobil servisin InvokeApiAsync(string apiismi) veya InvokeApiAsync(string apiismi, IDictionary<string,string> parametreler) metodlarını kullanarak custom apilere client üzerinden çağrı gönderebiliyoruz. 

Azure mobile services üzerinde custom api oluşturup basit bir örnek yaptık, faydalı olması dileğiyle.

Fazlasını Oku

Azure Mobile Services .NET Backend : Tablo Ekleme

Merhaba arkadaşlar,

Bu yazımda Azure Mobile Services .NET backend’inde tablo oluşturmayı anlatacağım. Bu yazıyı okumadan önce mobil servislerdeki tablolarla ilgili kavramları anlattığım buradaki yazıyı okumanızı tavsiye ederim.

Öncelikle mobil servis projesini azure portaldan bilgisayara indirdikten sonra projeyi Visual Studio’da açalım. (Projeyi ilk defa açıyorsanız önce build etmek gerekiyor.)

Tablo oluşturmak için oluşturacağımız tablo için bir Data Object sınıfı hazırlamamız gerekiyor. Data object sınıfında ilgili tablonun alanlarını belirtiyoruz.

1. Data Object tanımlama: Solution Explorer’da DataObjects klasörünün üzerine sağ tık yapıp Add -> New Class seçerek yeni bir sınıf ekleyelim. Ve ismine Kitap.cs verelim.

Bu sınıfı EntityData sınıfından türetmemiz ve oluşturacağımız tabloda hangi alanların olacağını belirtmemiz gerekiyor.


2 . Table Controller Ekleme : Şimdi de tablomuz için bir Controller ekleyeceğiz. Bu controller ise tabloya veri ekleme, silme, güncelleme gibi işlemleri handle ettiğimiz sınıf olacak.

Solution Explorer’da Controllers klasörüne sağ tıklayıp Add -> Controller seçelim.

Açılan pencereden Table Controller’ı seçip Add butonuna tıklayalım.

Şimdi de açılan pencerede Model Class kısmında biraz önce oluşturduğumuz Kitap sınıfını seçelim.

Add butonuna tıklandığında Kitap tablosu oluşmuş olacak. 

Şimdi servisi localde çalıştırıp Kitap tablosu için veri ekleyelim.

Gördüğünüz gibi tabloya ilk veriyi ekledik.

Bu işlemden sonra Visual Studio’da Server explorer’da ilgili tablo görünür olacak.

Bu yazımda Azure Mobile Services’te bulunan .NET backendli servisi için nasıl tablo oluşturulacağı hakkında bilgiler verdim. Faydalı olması dileğiyle.

Fazlasını Oku

Azure Mobile Services .NET Backend : Temel Kavramlar

Merhaba arkadaşlar,

Bildiğiniz gibi bir süre önce Azure Mobile Services için .NET backend’i preview’dan çıktı. Ben dahil javascript yazmak istemeyenleri sevindiren bir olaydı.

Bu yazımda Azure Mobile Services’teki Data Context, Data Object ve Controller kavramlarına değineceğim. 

Data Context
Mobil servisin data kısmını bağlayan iskelet gibi düşünebiliriz. Oluşturulan tüm tablolar datacontext’te belirtilmelidir. Data context, Mobil servisi bilgisayarınıza indirdiğinizde default olarak \Models klasörüne bulunan \sampleContext.cs dosyasıdır. Bu context’i silmeyip bunu kullanmanızı öneririm.

Data Object
Data object oluşturacağınız her bir tabloda bulunacak alanları belirttiğiniz bir şablondur. Oluşturacağınız her bir tablo için \DataObjects klasörüne EntityData sınıfından türemiş bir sınıf eklemelisiniz ve oluşturacağınız tabloda olmasını istediğiniz alanları bu sınıf içerisine property olarak eklemelisiniz. Bildiğimiz sınıf, fakat EntityData‘dan türemesi şarttır.

Örnek bir data object sınıfı:

 public class Ogrenci : EntityData
{
public string Name { get; set; }
public string Surname { get; set; }
}


Controller
Tablo ile ilgili her işlem controller sınıflarında yapılır. Javascript backendindeki insert, del, update scriptlerindeki işlemler .NET backend inde controller sayesinde yapılır. Ayrıca custom api oluşturmak için de controller oluşturulur.

Örneğin: Tabloya her ekleme işlemini handle eden Controller içinde bulunan PostTodoItem metodu:

        // POST tables/TodoItem/[id]
public async Task<IHttpActionResult> PostTodoItem(TodoItem item)
{
TodoItem current = await InsertAsync(item);
return CreatedAtRoute("Tables", new { id = current.Id }, current);
}

.NET backendi ile bilinmesi gereken temel kavramlar bunlardı. Önümüzdeki günlerde Tablo oluşturma, custom api oluşturma, controller’a parametre gönderme konularında yazılar yazacağım.

Görüşmek üzere.

Fazlasını Oku