Eryxon Flow'un Supabase mimarisi atölyede neyi belirler?

Bir iş emrinde kesim tamamlandıktan sonra bükümün başlayabilmesi gerekir. Kesimdeki operatör tabletten işlemi bitirdiğini kaydeder, planlamacı ofiste durumun değiştiğini görür. Bu akışın ekranda görünmesi kolay tarafıdır. Asıl soru, iki kişinin aynı kaydı gördüğünden, başka bir atölyenin kaydını görmediğinden ve bağlantı kesildiğinde yanlış bir tamamlandı bilgisi üretilmediğinden nasıl emin olunacağıdır.

Eryxon Flow’un Supabase üzerine kurulmuş olması bu soruyu somutlaştırıyor. Ürünün mimari belgesinde arka uç için PostgreSQL, satır düzeyinde erişim kuralları, kimlik doğrulama, dosya depolama, gerçek zamanlı güncellemeler ve Edge Functions yer alıyor. Bunlar ayrı ayrı moda sözcükler değil; iş emrinin kim tarafından değiştirilebileceğini ve başka ekranda ne zaman görüneceğini belirleyen parçalar. Kağıtsız iş emrinin saha tarafını ve işin ilerleme bilgisinin sınırlarını daha önce ele almıştık. Burada odak, bu akışların altındaki mimari.

Tek kayıt, birden çok görünüm

Eryxon’un tanımladığı veri düzeni iş, parça ve operasyon katmanlarından oluşuyor. Bir siparişin parçaları olabilir; her parçanın kesim, büküm ya da kaynak gibi operasyonları vardır. Aynı operasyon planlamacının ekranında geciken iş olarak, operatörün ekranında sıradaki görev olarak görünebilir. Ekranların birbirinden bağımsız listeler tutması yerine aynı kalıcı kayıtlardan beslenmesi, durumun nereden geldiğini araştırmayı kolaylaştırır.

Supabase’in PostgreSQL temeli bu kayıtların duracağı yeri sağlar. Ancak bir veritabanı seçmek, operasyonun hangi anda bittiğini kendiliğinden tanımlamaz. Kesim masasından çıkan parçanın kontrolü yapılmadan sonraki hücreye bırakılıp bırakılmayacağı iş kuralıdır. Mimari belgesine göre Eryxon’da üretim yaşam döngüsündeki değişiklikler belirli işlem fonksiyonlarından geçer. Bunun pratik değeri, farklı arayüzlerin aynı geçiş kurallarını uygulamasıdır. Yeni bir ekran geliştiren ekip, yalnızca tabloya yeni durum yazmanın doğru işlem olduğunu varsaymamalı.

Varsayımsal bir örnekte iki operatör aynı parçayı kendi tabletlerinde açık bırakmış olsun. Biri işlemi bitirirken diğeri hâlâ süre sayacını çalıştırıyor. Sadece arayüzde düğmeyi gizlemek bu çakışmayı çözmez. Sunucu tarafında kabul edilen geçişin, aktif sayacın ve olay zamanının nasıl ele alınacağı belirlenmelidir. Kaydın doğruluğu, ekrandaki son renkten daha önemlidir.

Yetki, giriş ekranından ibaret değil

Bir üretim uygulamasında oturum açabilmek, bütün üretim kayıtlarına erişme hakkı anlamına gelmez. Eryxon’un mimari belgesi, Supabase Auth oturumlarını, yönetici ve operatör rollerini, çok kiracılı veri ayrımını ve PostgreSQL’in Row Level Security kurallarını birlikte anlatıyor. Ayrım, yalnızca menüdeki seçenekleri saklamaya dayanmıyor; veri sorgularında da uygulanması gerekiyor.

Bu özellikle aynı altyapıda birden fazla atölye bulunduğunda önemlidir. Bir iş emrinin ait olduğu kiracı yanlış eşlenirse, bir kullanıcı kendi işini göremeyebilir ya da görmemesi gereken bir kaydı görebilir. Pilot sırasında iki farklı deneme hesabıyla, aynı iş için beklenen erişimleri ve reddedilmesi gereken erişimleri sınamak bu yüzden yararlıdır. Ekran kontrolü kadar API sorgusunun ve dosya erişiminin sonucuna da bakılmalı. Sistemin mimarisinde kural bulunması, uygulanan her yetkinin otomatik olarak doğru kurulduğunu kanıtlamaz.

Üç boyutlu dosya ya da iş talimatı PDF’si gibi ekler, satır kaydıyla aynı yetki tartışmasının parçasıdır. Eryxon belgesi Supabase Storage ve süreli imzalı bağlantılardan söz ediyor. Bir iş kaydını görüntüleme yetkisi kaldırıldığında daha önce üretilmiş dosya bağlantısının ne kadar süre açık kalacağı da gözden geçirilmeli. Dosya adı veya bağlantısı yanlış iş emrine eklenirse, veritabanı satırındaki doğru yetki tek başına yeterli koruma sağlamaz.

Canlı görünüm ile kalıcı kayıt farklı şeyler

Supabase Realtime, kayıt değişikliklerini açık ekranlara taşıyabilir. Bu, planlamacının sayfayı sürekli yenilemeden değişikliği görmesini sağlar. Ama bağlantısı kopan tabletin daha sonra her ara değişikliği eksiksiz gördüğü varsayılmamalı. Ekrana gelen olay bir bildirim gibi düşünülmeli; oturum yeniden bağlandığında güncel durum kalıcı kayıttan tekrar okunmalı.

Bu ayrım, vardiya değişiminde önem kazanır. Bir operatör üretim hücresinden çıkarken tabletin kablosuz bağlantısı kesilmişse, düğmeye basıldığını görmek işlemin sunucu tarafından kabul edildiği anlamına gelmeyebilir. Arayüzün bekleyen, kaydedilmiş ve reddedilmiş işlemleri ayırması gerekir. Kesinti sonrasında aynı işlemin iki kez gönderilmesi de denenmelidir. Bu davranışların Eryxon’un belirli bir kurulumunda nasıl gerçekleştiği belgelenmeden çevrimdışı çalışmayı garanti etmek doğru olmaz.

Eryxon’un Edge Functions üzerinden sunduğu API, başka sistemlerden iş veya durum alışverişi için bir sınır oluşturuyor. Dışarıdaki ERP’nin iş numarası ile MES içindeki iş kimliği farklı olabilir. Entegrasyonda önce bu eşlemenin sahibi belirlenmeli. Yeniden gönderilen bir olay yeni iş mi açacak, mevcut kaydı mı güncelleyecek? Aynı durum değişikliği iki kez gelirse iz nasıl tutulacak? API’nin varlığı bu soruları çözmez; üzerinde anlaşılmış kimlik ve hata sözleşmesi gerekir.

Kurulumu değerlendirirken sorulacaklar

Supabase’i altyapı tercihi olarak anlamak için küçük bir prova yeterlidir. Tek bir işi iki parçaya ve birkaç operasyona bölüp yönetici ve operatör hesaplarıyla kaydedin. Durum değişimini iki ekrandan izleyin, sonra bir tabletin bağlantısını kesin. Yeniden bağlandığında ekrandaki durumla veritabanındaki kaydı karşılaştırın. Ayrı bir hesapla erişilmemesi gereken işe ve dosyasına erişmeyi deneyin. API üzerinden aynı olayı tekrar gönderip sonuçları not edin. Bunlar ürünün kusurlu olduğunu varsayan testler değil, her üretim uygulamasında kritik olan sınırları görünür kılan testlerdir.

Barındırma kararı da ayrı tutulmalı. Supabase üzerinde kurulmuş bir uygulamanın aynı yöntemle her ortamda zahmetsizce çalışacağını varsaymayın. Kullanılan sürüm, kimlik sağlayıcısı, veritabanı yedeği, dosyalar, gerçek zamanlı bağlantılar ve Edge Functions için kimin sorumlu olduğu belgelenmeli. Barındırma yöntemi değişirse bu parçaların birlikte taşınması ve geri yüklenmesi gerekir. Supabase’in bir uygulama için genel arka uç bileşenlerini düşünmek burada yararlı; Eryxon’un iş kuralları ise genel platformun üstünde ayrıca durur.

Eryxon Flow’da Supabase tercihi, iş emrinin tek bir ekrandan fazlasına güvenle taşınması için ortak bir teknik zemin sunuyor. Değerlendirmede ölçü, kullanılan bileşenlerin sayısı değil: yanlış kullanıcıya kapanan kayıt, kesintiden sonra doğru görünen durum ve gerektiğinde geri getirilebilen üretim verisi. Bu sınırlar küçük bir iş üzerinde gösterilemiyorsa daha çok ekran eklemek sorunu çözmez.

Kaynaklar: Luke van Enkhuizen’in açık kaynak metal işleme yazılımları derlemesi ve Eryxon Flow uygulama mimarisi. Atölye senaryoları açıklama amaçlıdır; belirli bir kurulumun test sonucu değildir.