İş Emri Kalıcılığı¶

Aşağıdaki uç nokta için MongoDB kalıcılık kurallarının özeti:

POST /api/v1/inbound/work-orders (canlı yazma)

Halka açık format doğrulama endpointi POST /api/v1/inbound/work-orders/test bu kalıcılık planını kullanmaz. Bkz. Gelen İş Emirleri.

API kullanımı ve örnekler: Gelen İş Emirleri.

Kapsam¶

Canlı uç nokta doğrulama sonrası kabul edilen projeleri müşteri MongoDB collection'larına yazar:

projects
products
machines (salt okunur çözümleme)
users (salt okunur çözümleme)

Test uç noktası yalnızca JSON/XML format ve sözleşme doğrulaması yapar. Business collection okuma/yazma yapmaz, api_idempotency_records yazmaz ve api_request_archive yazmaz.

Live endpoint idempotency (Idempotency-Key) ve ham istek arşivi uygulanmıştır. Bkz. Idempotency ve İstek Arşivi.

Kiracı alanları¶

Her istek, outbound GET uç noktalarıyla aynı çift ve geri dönüş kurallarını kullanarak kök company_id ve organization_id ile kiracı çözümler:

Durum	Sonuç
Her iki istek değeri mevcut	İstek çifti kullanılır
Hiç istek değeri yok	Her ikisi yapılandırılmışsa `DEFAULT_COMPANY_ID` ve `DEFAULT_ORGANIZATION_ID` kullanılır
Tam olarak bir istek değeri	İstek reddedilir (`TENANT_CONTEXT_INCOMPLETE`)
Ne istek ne yapılandırılmış varsayılan	İstek reddedilir (`TENANT_CONTEXT_REQUIRED`)

Tüm sorgular çözümlenmiş kiracıya kapsamlanır. Servis kiracı filtresi olmadan çalışmaz.

Collection tip farklılıkları¶

Mevcut şemalar korunur (bu sürümde tip migrasyonu yok):

Collection	`company_id` / `organization_id`
`projects`	ObjectID
`machines`	ObjectID
`products`	string
`users`	string

Doğal anahtarlar¶

Varlık	Anahtar
Proje	kiracı + `project_code`
Üretim	proje belgesi içinde `production_code`
Aşama	üretim içinde `production_stage_code`
Ürün	kiracı + `product_code`
Makine	kiracı + `machine_code`
Çalışan	kiracı + `username`

Ürün upsert¶

Payload içindeki tüm ürün occurrence'ları products içine upsert edilir:

Yoksa oluştur; varsa _id korunur
Güncellenen alanlar: product_name, category, unit, ideal_cycle_time
product_code değişmez
Mevcut description ve image_url korunur
quantity yalnızca gömülü occurrence'da tutulur
Aynı product_code birden fazla gelebilir; master upsert bir kez yapılabilir, occurrence quantity'leri ayrı kalır

Proje / üretim / aşama birleştirme¶

Kod yoksa yeni proje; kod ve ad eşleşiyorsa güncelle
Aynı kod farklı ad → projeyi atla (PROJECT_NAME_CONFLICT); belgeyi değiştirme
Gönderilmeyen mevcut üretimler ve aşamalar korunur
Eşleşen üretim/aşamalar sözleşme alanlarını günceller; operasyonel alanlar (production_stage_operation, dosyalar, sözleşmede olmayan status) korunur
Yeni üretim aşamaları varsayılan olarak tamsayı status: 0 (BSON integer) alır. Mevcut aşama status değerleri istek tarafından asla üzerine yazılmaz
Bir üretim için tüm gelen aşamalar atlanırsa → üretim atlanır (ALL_STAGES_SKIPPED)
Bir proje için tüm üretimler atlanırsa → proje atlanır (ALL_PRODUCTIONS_SKIPPED)

Ortak processing plan¶

Canlı uç nokta doğrulama sonrası tek deterministik ProcessingPlan oluşturur:

Decode → normalize → sözleşme doğrulama
Kiracı ObjectID ve duplicate kontrolleri
Integration actor doğrulama
Proje / ürün / makine / çalışan lookup (okuma)
Ürün create/update/unchanged önizlemesi
Üretim ve aşama birleştirme önizlemesi, skip kuralları dahil

Ardından canlı planı MongoDB yazılarıyla uygular.

Halka açık test endpointi decode/normalize/sözleşme doğrulamasından sonra durur; processing plan oluşturmaz veya uygulamaz.

Test / canlı farkı¶

Başarılı bir format testi, sonraki canlı isteğin başarılı olacağını garanti etmez. Canlı işleme hâlâ veritabanı durumuna, kiracı çözümlemeye, actor yapılandırmasına ve iş kurallarına bağlıdır.

Makine çözümleme¶

Makineler kataloğu salt okunurdur. Eksik machine_code tüm aşamayı atlar (MACHINE_NOT_FOUND). Boş machines dizilerine izin verilir. Kanonik machine_name / machine_code MongoDB'den gelir.

Çalışan çözümleme¶

Kullanıcılar kataloğu salt okunurdur. Eksik username yalnızca o atamayı atlar (EMPLOYEE_NOT_FOUND) ve aşamayı atlamaz. Password, email, phone ve role asla gömülmez.

Kısmi işleme¶

Projeler bağımsız işlenir. Yanıt data.status:

success — alınan tüm projeler işlendi
partial_success — en az biri işlendi ve bir veya daha fazlası atlandı
HTTP 409 NO_PROJECT_PROCESSED — hiçbiri işlenmedi

Integration actor¶

INTEGRATION_ACTOR_USER_ID, yeni ve güncellenen proje/ürün denetim alanları için ObjectID / hex sağlar. Runtime Users store’undaki mevcut ve aktif kullanıcının ObjectID’si olmalıdır. Hex biçimi doğru olsa bile rastgele ObjectID geçersizdir. Bilinen aktör hataları INTERNAL_ERROR yerine HTTP 409 (INTEGRATION_ACTOR_USER_NOT_FOUND, INTEGRATION_ACTOR_USER_INACTIVE, INTEGRATION_ACTOR_TENANT_MISMATCH) döner. Yanıtta aktör ObjectID yoktur. Bkz. Yapılandırma ve Hata Kodları.

Standalone MongoDB¶

Çok belgeli transaction yoktur. Proje belgesi yazıları tek belge atomikliğindedir. Ürün upsert'leri bağımsızdır; sonraki proje yazısı başarısız olursa ürünler kalabilir.

İlgili HTTP kodları¶

Kod	HTTP
`NO_PROJECT_PROCESSED`	409
`INTEGRATION_ACTOR_USER_NOT_FOUND`	409
`INTEGRATION_ACTOR_USER_INACTIVE`	409
`INTEGRATION_ACTOR_TENANT_MISMATCH`	409
`DATABASE_UNAVAILABLE`	503
`INTERNAL_ERROR`	500