Teknik Kılavuzlar > Netsim System Agent İstemci Protokolü Referansı > 5. Mesaj kuyruğu ve kanallar > 5.1 /message ucu (MessageQueue işlemcisi)

Yol adı conf'taki path değeridir (NetsimSystemAgent.conf.json → "processor": "MessageQueue", "path": "/message"), işlemci adı değil; bu belgede daha önce yazılan /MessageQueue/... yanlıştı (A10, 2026-09-15). Uç IVEDIBL_Code'daki genel ILHttpProRestMQ işlemcisidir ve K3 sözleşmesini kullanmaz: yanıt gövdesi yalnızca GET'lerde vardır, başarı ve hata HTTP durum koduyla ayırt edilir. Oturum MQSessionId çerezinden bulunur (sessionManager MessageQueue, cookieName); anonymousSender: true olduğundan yalnız POST MESSAGE oturumsuz kabul edilir. Öteki her /message isteği açık oturum ister (2026-09-16, kullanıcı isteği): oturum çerezi yoksa 401 + WWW-Authenticate ve bağlantı kapanır. Eskiden çerezsiz POST SUBSCRIBE paylaşılan GUEST oturumunu abone ediyor, mesajlar onun kuyruğunda birikiyordu (kapı yazılmıştı ama hiç çağrılmıyordu ve GUEST kimliğini boş sanıyordu).

Oturum açma (2026-09-17): POST /message/OpenSession'a HTTP Basic kimliği (MASTER login'i) eklenir; başarıda 200 + Set-Cookie (oturum yöneticisinin cookieName'i, conf'ta MQSessionId) döner, yanlış kimlikte 401. Eskiden işlemci Basic yöntemini etkinleştirmediği için bu istek her zaman 401 alıyordu. İsteğe Connection: close konursa oturum bağlantıya bağlı sayılır ve çerez verilmez. Gövdesiz yanıtlar (OpenSession, 202'ler) Content-Length taşımaz; istemci bağlantıyı açık tutuyorsa gövde okumaya çalışmamalıdır.

Çok süreçli abonelik (2026-09-17): POST /message/SUBSCRIBE ile abone olunan konuya başka bir işçi süreçten yapılan yayın eskiden ajanı ACCESS_VIOLATION'a düşürüyordu (abonelik dizgesi süreç-yerel bellekte kalıyordu); düzeltildi. WhatsApp webhook'u olayları öndeğer olarak /whatsapp/event konusuna yayınlar. Mesaj gövdesi JSON'dur; anahtarları ivd$whatsapp_event kolonlarının camelCase adlarıdır: eventId, eventKind (MESSAGE | STATUS), accountId, phoneNumberId, wamid, sender, senderName, recipient, messageType, status, text, mediaId, replyToWamid, errorCode, errorMessage, eventTime (ISO 8601 UTC, 2023-11-14T22:13:20Z). Boş alan yazılmaz; ham JSON tabloda kalır.

Uç	Başarı	Hata / boş
`POST /message/MESSAGE` `{"topic", "message", "messageId", "options"}`	`202` + boş gövde (abone sayısı yalnız loga yazılır; `messageId` verilmezse ajan üretir)	`400` gövde yok; `413` `message` `maxMQMessageSize`'ı aşıyor
`GET /message/MESSAGE`	`200` `{"ILQueueMessage": {"sequence", "options", "messageId", "topic", "message"}}` — kuyruktaki ilk mesaj, silinmez (silme `DELETE` ile)	`204` kuyruk boş / oturumun kuyruğu yok. `sequence` sorgu parametresi okunuyor ama henüz uygulanmıyor
`DELETE /message/MESSAGE` `{"messageId": "<guid>"}`	`202` mesaj silindi	`400` + `messageId not specified/invalid` (kuyruk doluyken); `204` bulunamadı ya da kuyruk boş
`GET /message/SUBSCRIPTIONS`	`200` `{"subscriptions": ["/broadcast", "/user/bob", ...]}`	—
`POST /message/SUBSCRIBE` `{"topic"}`	`202`	`400` + `topic not specified`; `406` + `already subscribed` ya da `invalid subscription topic: …` (kanal bu oturuma kapalı, bkz. yukarıdaki kural)
`DELETE /message/UNSUBSCRIBE` `{"topic"}`	`202`	`400` + `topic not specified`; `204` abonelik yoktu

Bilinmeyen alt yol 404 (gövdesiz). Hepsi 2026-09-15'te canlı ölçüldü; ölçüm iki kusur buldu ve ikisi de aynı gün düzeltildi: (1) DELETE istekleri işleyiciye hiç ulaşmıyor, 405 alıyordu (işlemci yöntem listesine DELETE eklenmemişti); (2) her /message isteği yanıttan sonra bağlantıyı kapatıp oturumu closeSessionOnDisconnect yapıyordu, yani oturum çerezini taşıyan bir istemci (köprü dahil) GET SUBSCRIPTIONS çağırınca kendi oturumunu kapatıyor, sonraki istekleri GUEST'e düşüyor ve yayınladığı mesaj kimseye ulaşmıyordu. Artık oturumun ömrü yalnız oturum yöneticisinin (idleTimeout/lifeTime) elindedir. Web köprüsü bu ucu yayın (POST MESSAGE) ve abonelik listesi (GET SUBSCRIPTIONS) için kullanır; tüketim WebSocket getNextMQMessage iledir.