Script Engine

inSCADA JDK21, iki ayrı script ortamı sunar: server-side (ins.*) ve client-side (Inscada.*). İkisi farklı yerlerde çalışır, farklı amaçlar için tasarlanmıştır ve birbirinden izole API yüzeyleri vardır.

İki Ayrı Dünya

	Server-side (ins.*)	Client-side (Inscada.*)
Nerede çalışır	inSCADA sunucusu (JVM)	Tarayıcı (browser JS)
Engine	GraalJS (Nashorn uyumlu)	Tarayıcının kendi motoru
Binding	ins (global)	new InscadaApi(projectName)
Amaç	Otomasyon, hesap, alarm, zamanlı iş	Kullanıcı etkileşimi, UI kontrolü
Tipik kullanım	Scheduled script, variable / alarm / log expression, MQTT parse	Animation click, custom HTML widget, dashboard widget

→ Server-side (ins.*) detayları → Client-side (Inscada.*) detayları

Nerede Kullanılır?

inSCADA’da script’ler pek çok yerde devreye girer. Aşağıdaki tablo her kullanım yerinin hangi ortamda çalıştığını gösterir.

Kullanım Yeri	Ortam	Tetikleme
Scheduled Script	server (ins.*)	Periodic / Daily / Once / manuel
Variable Expression	server (ins.*)	Poll döngüsünde otomatik
Alarm Expression	server (ins.*)	Değer değişiminde otomatik
Log Expression	server (ins.*)	Poll döngüsünde otomatik
MQTT Subscribe/Publish	server (ins.*)	Her MQTT mesajında
Animation Expression	server (ins.*)	UI güncellemesinde (uzaktan)
Animation Click Script	client (Inscada.*)	Kullanıcı tıklaması
Custom HTML Widget	client (Inscada.*, sandboxed iframe)	Widget kendi içinde
Dashboard Widget	client (Inscada.*)	Dashboard render / etkileşim

Hangisini seçmeliyim?

Veri yazıp/okuyor, alarm tetikliyor, zamanlanmış bir hesap yapıyorsan server-side (ins.*). Kullanıcıya popup gösterecek, SVG zoom yapacak, animasyon değiştireceksen client-side (Inscada.*). İkisini birleştirmek istersen: client’ın mirror metodları server metodlarını async çağırır.

Sandbox ve Güvenlik

İki ortamda da script’ler izole çalışır, ama kısıtlar farklıdır:

• Server tarafı — HostAccess.EXPLICIT: yalnızca @HostAccess.Export işaretli Java metodlarına erişilebilir. eval ve with kapalı, host sınıf araması tamamen engelli (yani Java.type(...) ve java.* ad alanı yok); thread, native erişim, process oluşturma, ortam değişkeni erişimi ve guest dosya I/O’su da yok.
• Client tarafı — Custom HTML widget’lar sandboxed iframe’de çalışır; ana sayfa API’sine InscadaBridge üzerinden, origin-doğrulamalı postMessage ile erişir.

Server tarafındaki iki sınır

Sınır	Varsayılan	Neyi sınırlar
Statement sayısı	Koşum başına 100.000	Kaçak döngüyü. while(true){} milisaniyeler içinde durdurulur
Çalışma süresi	5 dakika	Döngüye girmemiş ama takılmış koşumu — dönmeyen bir host çağrısı

Yazarların pratikte karşılaştığı sınır statement sınırıdır ve normal bir hata gibi gelmez: motor yakalanabilir bir hata atmak yerine context’i iptal eder, yani kendi try/catch’iniz bunu yutup devam edemez.

Her örneği tek tek gezen script bu duvara eninde sonunda çarpar

Loglanmış değerler üzerinde dönen bir rapor datasource’u örnek başına yaklaşık beş-altı statement harcar; yeterince tarihçe biriktiğinde 100.000’i aşar. Yani birkaç yüz örnekle testte geçer, sahada aylar sonra düşer. Sınırı yükseltmek duvarı kaldırmaz, yerini değiştirir. Çıkış yolu sunucuda toplayan bir çağrı kullanmak ya da erken çıkışlı sayfalama yapmaktır.

Kontrol dizilerini yeniden koşabilir yazın

Çalışma süresi sınırı koşumu öldürür. Cihaza yazan bir script bu yüzden bir dizinin ortasında kesilebilir; çok adımlı bir yazma dizisinin bütün olarak tamamlanacağına güvenmeyin, bu tür dizileri idempotent kurun.

Client tarafında böyle bir bütçe yoktur; tarayıcı sekmesini donduracak kod yazmaktan kaçının.