Cara Kerja Perakitan EDI
BizTalk Server melakukan sebagian besar pemrosesan pertukaran yang dikodekan EDI untuk dikirim dalam Alur Kirim EDI (Microsoft.BizTalk.DefaultPipelines.EDISendPipeline). Alur ini mencakup komponen alur perakitan EDI, yang melakukan pemrosesan berikut:
Membuat serialisasi pertukaran EDI, mengubah pesan yang dikodekan XML menjadi set transaksi EDI dalam pertukaran.
Melakukan validasi skema EDI, validasi lintas bidang untuk pesan yang dikodekan X12 (jika dikonfigurasi), validasi struktural EDI, dan validasi skema yang diperluas (jika skema disesuaikan dengan simpul yang memiliki jenis data non-EDI).
Menerapkan amplop ke pesan EDI.
Memproses pengakuan Teknis dan Fungsional yang diterima sebagai respons terhadap pesan EDI, memperdebatkan pengakuan jika dikonfigurasi.
Menerapkan Amplop ke Pesan EDI Keluar
Ketika EDI mengirim alur membangun pesan EDI keluar dari file XML perantara, EDI menerapkan amplop yang berisi pertukaran dan header grup ke pesan berdasarkan properti EDI yang ditetapkan untuk perjanjian sisi penerima. Jika alur pengiriman tidak dapat menentukan perjanjian penerima dari port pengiriman, alur tersebut akan menggunakan perjanjian fallback untuk menerapkan amplop.
EdiOverride.OverrideEdiHeader Jika properti konteks diatur ke true, alur pengiriman EDI akan menggunakan nilai yang ditentukan dalam kumpulan properti EdiOverride untuk membuat amplop. Jika nilai tidak ada dalam koleksi, nilai EDI yang sesuai dalam properti perjanjian akan digunakan. Jika nilai tidak ada dalam koleksi EdiOverride atau properti perjanjian, properti dalam perjanjian EDI fallback akan digunakan.
Jika file XML perantara memiliki tag yang dipesan atau properti konteks ReuseEnvelope, pesan adalah batch yang dipertahankan dan logika aplikasi amplop tidak akan berlaku.
Sumber untuk Nilai Amplop X12
Tabel berikut menunjukkan di mana alur pengiriman EDI mendapatkan informasi yang dibutuhkan untuk setiap bagian amplop X12:
| Header | Sumber |
|---|---|
| Header Kontrol Pertukaran (ISA) | - Properti konteks EdiOverride (jika EdiOverride.OverrideEdiHeader benar).- Jika perjanjian ditentukan, definisi segmen ISA dari halaman yang berbeda di bawah bagian Pengaturan Pertukaran di properti perjanjian satu arah dalam kotak dialog Properti Perjanjian . - Jika tidak ada perjanjian yang ditentukan, definisi segmen ISA dari halaman yang berbeda di bawah bagian Pengaturan Pertukaran dalam kotak dialog Pengaturan Fallback EDIFACT . |
| Header Grup Fungsional (GS) | - Properti konteks EdiOverride (jika EdiOverride.OverrideEdiHeader benar)- Jika perjanjian ditentukan, definisi segmen GS dari halaman Amplop (di bawah bagian Pengaturan Set Transaksi) di properti perjanjian satu arah dalam kotak dialog Properti Perjanjian - Jika tidak ada perjanjian yang ditentukan, definisi segmen GS dari halaman Amplop (di bawah bagian Pengaturan Set Transaksi) dalam kotak dialog Pengaturan Fallback X12 Jika perjanjian ditentukan, nilai untuk elemen data GS ditentukan berdasarkan kombinasi Pengidentifikasi Set Transaksi (ST1), versi, dan namespace target. Nilai-nilai ini dibandingkan dengan kisi di halaman Amplop (di bawah bagian Pengaturan Set Transaksi ) dari properti perjanjian (jika perjanjian ditentukan) atau properti perjanjian fallback (jika tidak ada perjanjian yang ditentukan): - Jika ada baris yang cocok, maka nilai yang terkandung dalam baris yang cocok digunakan untuk header GS. - Jika tidak ada kecocokan, tetapi baris default ditentukan, semua elemen data GS kecuali GS01 diisi dari baris default. GS01 ditentukan secara dinamis berdasarkan nilai ST1. - Jika tidak ada baris yang cocok, dan tidak ada baris default, pesan ditangguhkan. Catatan: Agar grup unik dari grup lain, tidak semua nilai ini bisa sama dengan grup lain. Jika tidak ada perjanjian yang ditentukan, maka elemen data GS diisi dari properti perjanjian fallback. |
Sumber untuk Nilai Amplop EDIFACT
Tabel berikut menunjukkan di mana alur pengiriman EDI mendapatkan informasi yang dibutuhkan untuk setiap bagian amplop EDIFACT:
| Header | Sumber |
|---|---|
| Saran String Layanan (UNA) | - Properti konteks EdiOverride (jika EdiOverride.OverrideEdiHeader benar).- Jika perjanjian ditentukan, definisi segmen UNA dari halaman Charset dan Pemisah di properti perjanjian satu arah dalam kotak dialog Properti Perjanjian . - Jika tidak ada perjanjian yang ditentukan, definisi segmen UNA dari halaman Charset dan Pemisah dalam kotak dialog Pengaturan Fallback EDIFACT . |
| Header Kontrol Pertukaran (UNB) | - Properti konteks EdiOverride (jika EdiOverride.OverrideEdiHeader benar).- Jika perjanjian ditentukan, definisi segmen UNB dari halaman yang berbeda di bawah bagian Pengaturan Pertukaran di properti perjanjian satu arah dalam kotak dialog Properti Perjanjian . - Jika tidak ada perjanjian yang ditentukan, definisi segmen UNB dari halaman yang berbeda di bawah bagian Pengaturan Pertukaran dalam kotak dialog Pengaturan Fallback EDIFACT . |
| Header Grup Fungsional (UNG) | - Properti konteks EdiOverride (jika EdiOverride.OverrideEdiHeader benar).- Jika perjanjian ditentukan, definisi segmen UNG dan UNH dari halaman Amplop (di bawah bagian Pengaturan Set Transaksi) di properti perjanjian satu arah dalam kotak dialog Properti Perjanjian - Jika tidak ada perjanjian yang ditentukan, definisi segmen UNG dan UNH dari halaman Amplop (di bawah bagian Pengaturan Set Transaksi) di properti perjanjian satu arah dalam kotak dialog Properti Perjanjian dalam kotak dialog Pengaturan Fallback EDIFACT Jika perjanjian ditentukan, nilai untuk elemen data UNG ditentukan berdasarkan kombinasi Jenis Pesan (UNH2.1), Nomor Rilis Pesan (UNH2.3), Kode yang Ditetapkan (UNH2.5), versi, dan namespace target. Catatan: Agar grup unik dari grup lain, tidak semua nilai ini bisa sama dengan grup lain. |
Menerapkan Header Set Transaksi dan Segmen Trailer
Kumpulan transaksi XML yang diserialisasikan ke dalam pertukaran EDI keluar harus memiliki header dan trailer set transaksi. Namun, EDI Assembler akan memproses pesan jika tidak memiliki header atau trailer set transaksi. Segmen header dan trailer set transaksi dalam skema X12 dan EDIFACT bersifat opsional untuk set transaksi XML. Jika transaksi tidak memiliki header atau trailer, EDI Assembler di alur pengiriman EDISend atau AS2EDISend akan menambahkan header set transaksi dan nilai trailer ke dalamnya. Nilai-nilai ini akan didasarkan pada pemetaan atau perhitungan. EDI Assembler akan melakukan ini untuk pertukaran XML (batch yang dipertahankan), XML set transaksi batch, dan XML set transaksi.
Jika pemetaan menyebabkan kesalahan validasi, set transaksi XML atau XML pertukaran ditangguhkan dengan kesalahan yang sesuai dalam penampil peristiwa, seperti panjang atau jenis data yang tidak valid, atau Kode Agensi Kontrol yang tidak valid.
Header Set Transaksi X12 dan Segmen Trailer
Untuk kumpulan transaksi yang dikodekan X12 yang tidak memiliki segmen header dan trailer, EDI Assembler akan mengatur segmen ST dan SE ke yang berikut:
| Segmen Header/Footer | Nilai |
|---|---|
| ST01 (Kode Pengidentifikasi Set Transaksi) | Dipetakan ke tiga karakter terakhir nama RootNode dari kumpulan transaksi XML masuk. Misalnya, "855" dari "X12_00401_855". Untuk Klaim HIPAA yang memiliki Kode Pengidentifikasi TS 837P, 837D, atau 837I, "837" digunakan. |
| ST02 (Nomor Kontrol Set Transaksi) | Nilai EdiOverride.ST02 (jika EdiOveride.OverrideEdiHeader benar,) atau dipetakan ke nilai Nomor kontrol set transaksi (ST02) di halaman Pengaturan Host Lokal (di bawah Pengaturan Pertukaran) dari tab perjanjian satu arah dalam kotak dialog Properti Perjanjian .Nomor kontrol baru atau bertahap diterapkan terlepas dari pengaturan properti Terapkan ID Baru . |
| ST03 (Pengidentifikasi versi) | Dipetakan ke nilai ST03 dari kumpulan transaksi XML masuk. Misalnya, "005010X218" untuk dokumen 5010 HIPAA 820 (Pengurangan penggajian). ST03 divalidasi terhadap skema yang digunakan untuk memvalidasi kumpulan transaksi. Catatan: ST03 wajib untuk semua transaksi HIPAA versi 5010 kecuali untuk 835. |
| SE01 (Jumlah Segmen yang Disertakan) | Atur ke jumlah total segmen dalam kumpulan transaksi, termasuk segmen ST dan SE. |
| SE02 (Nomor Kontrol Set Transaksi) | Dipetakan ke nilai ST02 dalam kumpulan transaksi. |
Elemen data lain dalam header kumpulan transaksi, seperti ST03, bersifat opsional dan karenanya tidak dinilai dalam segmen yang dihasilkan.
Header Set Transaksi EDIFACT dan Segmen Trailer
Untuk kumpulan transaksi yang dikodekan EDIFACT yang tidak memiliki segmen header dan trailer, EDI Assembler akan mengatur segmen UNH dan UNT ke yang berikut:
| Segmen Header/Footer | Nilai |
|---|---|
| UNH01 (Nomor Kontrol Referensi Pesan) | Nilai EdiOverride.UNH1 (jika EdiOverride.OverrideEdiHeader benar,) atau dipetakan ke nilai Nomor Referensi (UNH1) di halaman Pengaturan Host Lokal (di bawah Pengaturan Pertukaran)dari tab perjanjian satu arah dalam kotak dialog Properti Perjanjian . Nomor kontrol baru atau bertahap diterapkan terlepas dari pengaturan properti Terapkan ID Baru . |
| UNH2.1 (Jenis Pesan) | Dipetakan ke enam karakter terakhir dari nama RootNode dari kumpulan transaksi XML masuk. Misalnya, "INVOIC" dari "EFACT_D96A_INVOIC". |
| UNH2.2 (Nomor Versi Pesan) | Dipetakan ke karakter ketujuh dari nama RootNode dari kumpulan transaksi XML masuk. Misalnya, "D" dari "EFACT_D96A_INVOIC". |
| UNH2.3 (Nomor Rilis Pesan) | Dipetakan ke karakter kedelapan, kesembilan, dan kesepuluh dari nama RootNode dari set transaksi XML masuk. Misalnya, "96A" dari "EFACT_D96A_INVOIC". |
| UNH2.4 (Control Agency Coded) | Selalu dipetakan ke string 'UN'. |
| UNT01 (Jumlah Segmen yang Disertakan) | Atur ke jumlah total segmen dalam kumpulan transaksi, termasuk segmen UNH dan UNT. |
| UNT02 (Nomor Kontrol Referensi Pesan) | Dipetakan ke nilai Nomor Referensi (UNH1) di halaman Pengaturan Host Lokal (di bawah Pengaturan Pertukaran)dari tab perjanjian satu arah dalam kotak dialog Properti Perjanjian |
Elemen data lain dalam header kumpulan transaksi UNH, seperti UNH3 ke UNH6, bersifat opsional dan jadi tidak dinilai dalam segmen yang dihasilkan. Jika salah satu bidang ini diperlukan, Anda harus mengaturnya ke nilai dalam kumpulan transaksi XML masuk.
Pemrosesan Tambahan pada Amplop Pesan Keluar
Alur pengiriman EDI melakukan pemrosesan berikut pada amplop pesan keluar.
Nomor kontrol
Alur pengiriman EDI akan memasukkan nomor kontrol pertukaran, nomor kontrol grup, dan nomor kontrol set transaksi (atau referensi) ke dalam segmen amplop dari setiap pertukaran keluar. Angka-angka ini diperlihatkan dalam tabel berikut:
| Nomor Kontrol | Bidang X12 | Bidang EDIFACT |
|---|---|---|
| Nomor kontrol pertukaran | ISA13 | UNB5 |
| Nomor kontrol grup | GS6 | UNG5 |
| Nomor kontrol set transaksi (X12) Nomor referensi set transaksi (EDIFACT) |
ST2 | UNH1 |
BizTalk Server akan mengatur nomor kontrol pertukaran untuk pertukaran berikutnya yang dikirim berdasarkan rentang nilai yang Anda masukkan di properti Nomor kontrol pertukaran (ISA13) di halaman Pengaturan Host Lokal (di bawah Pengaturan Pertukaran) dari tab perjanjian satu arah dalam kotak dialog Properti Perjanjian . Ini akan menaikkan angka ini untuk setiap pertukaran berikutnya, sampai nilai maksimum tercapai.
Jika nomor kontrol pertukaran ditentukan menggunakan properti konteks EdiOverride, nilai yang ditentukan akan digunakan untuk pertukaran ini dan tidak akan memengaruhi nomor kontrol pertukaran yang ditentukan dalam perjanjian.
Catatan
Nomor kontrol grup di EDIFACT hanya bertahap jika properti Terapkan segmen UNG di halaman Amplop properti perjanjian EDIFACT dipilih. Bidang kedua (nomor referensi) dinaikkan; bidang awalan dan akhiran tidak bertahap. Nomor kontrol set transaksi hanya bertahap jika properti Terapkan ID baru dipilih.
Catatan
Dalam pertukaran batch yang dipertahankan, Anda dapat membuat nomor kontrol pertukaran kustom menggunakan sampel pengayaan pesan. Untuk informasi selengkapnya, lihat Sampel Pengayaan Pesan (Sampel Server BizTalk).
Jika tidak ada perjanjian yang ditentukan, angka diambil dari halaman yang sama dalam perjanjian fallback. Alur pengiriman menyimpan nomor kontrol yang terakhir digunakan, lalu memasukkan nomor bertahap untuk set pertukaran, grup, dan transaksi berikutnya.
Catatan
Jika ada nomor kontrol yang mencapai nilai maksimum rentang yang ditentukan, BizTalk Server akan memunculkan kesalahan dan menangguhkan pertukaran. Anda dapat mengatur ulang nomor kontrol secara manual, atau mengonfigurasi BizTalk Server untuk mengatur ulang secara otomatis ke batas bawah, di halaman Pengaturan Host Lokal dalam kotak dialog Properti Perjanjian untuk pesan X12 dan EDIFACT.
Catatan
Nomor kontrol disimpan di dbo. Tabel EdiSequenceNumbers dari database BizTalk MessageBox. Anda harus mengelola tabel database ini dengan membersihkan nomor kontrol dari tabel atau mengarsipkan nomor kontrol, sebagaimana mestinya.
Dalam EDIFACT, nomor kontrol terdiri dari nilai alfanumerik. Format berikut didukung:
Angka (misalnya, "1")
PrefixNumbersSuffix (misalnya, "WA1A")
PrefixNumbers (misalnya, "AA1")
NumbersSuffix (misalnya, "1AA")
Dalam format ini, karakter angka dapat dari "0" hingga "9", dan karakter awalan dan akhiran dapat berupa karakter apa pun selain angka. Hanya angka yang akan dinaikkan untuk mencapai nilai maksimum.
Jumlah segmen
Untuk setiap set transaksi dalam pertukaran, alur pengiriman EDI akan memverifikasi jumlah segmen dalam kumpulan transaksi, seperti yang ditunjukkan dalam elemen data SE01 untuk X12 dan elemen data UNT01 untuk EDIFACT. Jika nilai elemen data yang sesuai tidak cocok dengan jumlah aktual, alur kirim akan memperbarui hitungan untuk mencerminkan jumlah segmen aktual. Kumpulan transaksi tidak akan ditolak karena jumlah yang salah. Pembaruan hitungan akan dicatat dalam peringatan di penampil peristiwa. Ini tidak berlaku untuk pemrosesan batch yang dipertahankan.
Langkah Tambahan dalam Serialisasi Pertukaran EDI
Alur pengiriman EDI juga melakukan langkah-langkah berikut selama serialisasi.
Serialisasi Indikator Rilis
Selama serialisasi pesan EDIFACT, alur pengiriman EDI akan menyisipkan indikator rilis yang diperlukan ke dalam pertukaran EDI. Diasumsikan bahwa XML perantara yang dirutekan ke alur pengiriman tidak menyertakan data yang lolos. Misalnya, jika indikator rilis ada dalam data XML yang dirutekan ke alur kirim, alur kirim akan menambahkan indikator rilis lain sebelum indikator rilis yang ada untuk menghindarinya.
Indikator rilis tidak akan disertakan dalam validasi EDI. Alur pengiriman EDI tidak akan menyertakan indikator rilis ketika menghitung pembatasan panjang.
Menambahkan Nol Berikutnya untuk Memenuhi Persyaratan Desimal Tersirat
Jika EDI Assembler menemukan angka yang memiliki jumlah digit yang tidak mencukupi setelah titik desimal, itu akan menambahkan nol berikutnya setelah titik desimal untuk memenuhi persyaratan desimal tersirat. Misalnya, jika EDI Assembler menemukan angka "4,5" ketika angka harus memiliki format N2, Assembler akan mengubah angka menjadi "4,50".
Mengganti Pemisah dalam Data Payload
Jika data dalam pesan keluar berisi karakter yang juga dikonfigurasi sebagai pemisah data, segmen, atau komponen, alur pengiriman EDI dapat menggantikan karakter ini. Misalnya, jika pesan berisi nilai "test*data" dan pemisah elemen data dikonfigurasi sebagai '*', ini dapat menyebabkan masalah penguraian pada sistem penerima.
Alur pengiriman EDI dapat dikonfigurasi untuk mengganti karakter ini dengan mengaktifkan ganti pemisah dalam payload dengan properti dan menentukan karakter pengganti. Properti ini terletak di halaman Charset dan Pemisah di tab perjanjian satu arah dari kotak dialog Properti Perjanjian .
Mengubah Rekaman HIPAA Berdasarkan Bidang Pemicu
Jika dokumen keluar adalah kumpulan transaksi HIPAA, EDI Assembler akan mengubah rekaman XML unik yang berisi bidang pemicu menjadi segmen EDI generik yang cocok (lihat Anotasi Bidang Pemicu Skema HIPAA). Ini dicapai dengan menghilangkan akhiran nama rekaman XML setelah karakter "_".
Misalnya, elemen <N1_PayerIdentification_TS835W1_1000A> dan <N1_PayeeIdentification_TS835W1_1000B> akan menjadi segmen N1.