20220818170828_ISYS6332-LN5-R1.pdf

LECTURE NOTES ISYS6332 Data Warehouse Week ke - 5 Extraction, Transformation, and Loading ISYS6507 – Testing and System Implementation LEARNING OUTCOMES LO1 : Describe data warehouse concept on business organization. LO1 : Mahasiswa diharapkan mampu mendeskripsikan konsep data warehouse dalam organisasi bisnis OUTLINE MATERI : 1. Introduction 2. Business Process Modeling Notation 3. Conceptual Design of the Northwind ETL Process 4. Integration Services and Kettle 5. The Northwind ETL Process in Integration Services 6. The Northwind ETL Process in Kettle ISI MATERI A. Introduction Proses ekstraksi, transformasi, dan loading (ETL) digunakan untuk mengekstrak data dari sumber internal dan eksternal organisasi, mengubah data ini, dan memuatnya/load ke dalam data warehouse. Karena proses ETL rumit dan mahal, penting untuk mengurangi biaya pengembangan dan pemeliharaannya. Pemodelan proses ETL pada tingkat konseptual adalah cara untuk mencapai tujuan ini. Namun, alat ETL yang ada, seperti Microsoft Integration Services atau Pentaho Data Integration (juga dikenal sebagai Kettle), memiliki bahasa khusus mereka sendiri untuk mendefinisikan proses ETL. Dalam bab ini, kita akan mempelajari desain proses ETL menggunakan pendekatan konseptual. Model yang akan digunakan didasarkan pada Business Process Modeling Notation (BPMN), standar de facto untuk menentukan proses bisnis. Model ini menyediakan satu set primitif yang mencakup persyaratan proses ETL yang sering digunakan. Selanjutnya, BPMN menyediakan spesifikasi independen konseptual dan implementasi dari proses tersebut, yang menyembunyikan detail teknis dan memungkinkan pengguna dan desainer untuk fokus pada karakteristik penting dari proses tersebut. Akhirnya, proses ETL yang diekspresikan dalam BPMN dapat diterjemahkan ke dalam spesifikasi yang dapat dieksekusi untuk alat ETL. B. Business Process Modeling Notation Proses bisnis adalah kumpulan aktivitas atau task terkait dalam sebuah organisasi yang tujuannya adalah untuk menghasilkan layanan atau produk tertentu. Sebuah task dapat dilakukan oleh sistem perangkat lunak, manusia, atau kombinasi dari semuanya. Pemodelan proses bisnis adalah aktivitas mewakili proses bisnis dari suatu organisasi sehingga proses saat ini dapat dianalisis dan ditingkatkan. Banyak teknik untuk memodelkan proses bisnis telah diusulkan selama bertahuntahun. Teknik tradisional termasuk grafik Gantt, diagram alir/flowchart, diagram PERT, dan diagram aliran data/data flow diagram. Namun, masalah dengan teknik ini adalah kurangnya semantik formal. Di sisi lain, teknik formal seperti Petri Nets memiliki semantik yang terdefinisi dengan baik tetapi sulit dipahami oleh pengguna bisnis dan, di samping itu, tidak memiliki ekspresi untuk mewakili beberapa situasi khas yang muncul dalam pengaturan dunia nyata. Banyak upaya telah dilakukan sejak tahun 1990-an di bidang sistem manajemen workflow untuk menentukan bahasa dan alat untuk pemodelan dan pelaksanaan proses bisnis. Proses standardisasi ini menghasilkan BPMN yang dirilis oleh Object Management Group (OMG). Versi standar saat ini adalah BPMN 2.0. BPMN menyediakan notasi grafis untuk mendefinisikan dan memahami proses bisnis suatu organisasi dan untuk mengomunikasikannya dengan cara standar. Alasan di balik BPMN adalah untuk mendefinisikan bahasa yang dapat digunakan oleh komunitas bisnis, dibatasi untuk mendukung konsep pemodelan yang berlaku untuk proses bisnis, dan berguna dalam menggambarkan proses yang kompleks dengan jelas. BPMN didefinisikan menggunakan Unified Modeling Language (UML). Selain itu, semantik bahasa yang tepat dan semantik eksekusi juga ditentukan. BPMN bertujuan untuk mengatasi dua persyaratan yang saling bertentangan, yaitu menyediakan mekanisme sederhana untuk membuat model proses bisnis dan menangani kompleksitas yang melekat padanya. Pendekatan yang dilakukan untuk mengatasi dua persyaratan ini adalah dengan mengatur aspek grafis dari notasi ke dalam kategori, sehingga pembaca diagram BPMN dapat dengan mudah mengenali tipe dasar elemen dan memahami diagram. Dalam kategori elemen dasar, variasi dan informasi tambahan dapat ditambahkan untuk mendukung persyaratan kompleksitas tanpa mengubah tampilan dan nuansa dasar diagram secara dramatis. Ada empat kategori dasar elemen, yaitu: 1. Flow objects Flow objects adalah elemen utama untuk mendefinisikan proses bisnis. Ada tiga jenis Flow objects yaitu : a. Activities Activity adalah pekerjaan yang dilakukan selama proses. Activity dapat berupa tugas tunggal atau subproses, dan dengan demikian activity dapat berupa atomik atau nonatomik. Gambar 5.1a menunjukkan bagaimana task diwakili. Subproses adalah proses yang dienkapsulasi yang detailnya ingin kita sembunyikan. Gambar 8.1b menunjukkan bahwa ada dua cara untuk merepresentasikan subproses: collapsed and expanded (diciutkan dan diperluas). Fig. 5.1 Activities. (a) Single task. (b) Collapsed dan expanded subprocess b. Gateways Gateway digunakan untuk mengontrol urutan aktivitas/activities dalam suatu proses tergantung pada kondisi. Perlu dicatat bahwa BPMN tidak menyatakan bagaimana ketentuan ini harus ditulis; ini diserahkan kepada pemodel. Gateway diwakili oleh bentuk diamond/berlian. BPMN mendefinisikan beberapa jenis gerbang, ditunjukkan pada Gambar 5.2a, yang dibedakan dengan simbol yang digunakan di dalam bentuk berlian. Semua jenis ini dapat memisahkan atau menggabungkan gateway, seperti yang ditunjukkan pada Gambar 5.2b, tergantung pada jumlah cabang yang masuk dan keluar. Gambar 5.2 (a) Berbagai jenis gateway. (b) Memisahkan/splitting dan menggabungkan/merging gateway Gateway exklusive memodelkan keputusan OR eksklusif, yaitu, tergantung pada suatu kondisi, gateway mengaktifkan tepat satu cabang keluarnya. Ini dapat direpresentasikan sebagai bentuk berlian kosong atau bentuk berlian dengan 'X' di dalamnya. Sebuah gateway inklusif memicu atau menggabungkan satu atau lebih aliran. Dalam splitting inclusive gateway, kombinasi aliran keluar apa pun dapat dipicu. Namun, aliran default tidak dapat dimasukkan dalam kombinasi seperti itu. Dalam merging inclusive gateway, kombinasi apa pun dapat dipilih untuk melanjutkan aliran. Sebuah gateway paralel memungkinkan sinkronisasi antara aliran keluar dan masuk sebagai berikut. Sebuah splitting parallel gateway sebanding dengan operator AND: aliran masuk memicu satu atau lebih aliran paralel keluar. Di sisi lain, parallel gateway synchronizes menyinkronkan aliran yang menggabungkan semua aliran masuk menjadi satu aliran keluar. Akhirnya, complex gateways dapat mewakili kondisi yang kompleks. Misalnya, penggabungan gateway kompleks dapat memodelkan bahwa ketika tiga dari lima aliran diselesaikan, proses dapat dilanjutkan tanpa menunggu penyelesaian dua lainnya. c. Events Event (lihat Gambar 5.3) mewakili sesuatu yang terjadi yang mempengaruhi urutan dan waktu aktivitas alur kerja. Event mungkin internal atau eksternal sehingga task menjadi pertimbangan. Ada tiga jenis event, yang dapat dibedakan tergantung pada apakah mereka digambar dengan garis tunggal, ganda, atau tebal. Gambar 5.3. Contoh Event Start dan End Event menunjukkan awal dan akhir dari suatu proses, masingmasing. Intermediate Event termasuk waktu, pesan, batalkan, dan akhiri acara. Event Time dapat digunakan untuk mewakili situasi ketika tugas harus menunggu beberapa waktu sebelum melanjutkan. Message Event dapat digunakan untuk mewakili komunikasi, misalnya, untuk mengirim email yang menunjukkan bahwa telah terjadi kesalahan. Event ini juga dapat digunakan untuk memicu task, misalnya, sebuah pesan mungkin menunjukkan bahwa suatu activity dapat dimulai. Cancel event mendeteksi kesalahan dalam suatu proses dan memberitahukannya baik dengan tindakan eksplisit seperti mengirim pesan, seperti pada activity yang dibatalkan seperti ditunjukkan pada Gambar 5.4, atau dengan tindakan implisit yang akan ditentukan dalam langkah selanjutnya dari pengembangan proses. Compensation events dapat digunakan untuk memulihkan kesalahan dengan meluncurkan aktivitas compensation khusus, yang terkait dengan peristiwa kompensasi dengan objek penghubung asosiasi (Gbr. 5.5), seperti yang ditunjukkan pada Gbr. 5.4. Gambar 5.4. Penanganan kesalahan: aktivitas yang dibatalkan (cancelled) dan diberi kompensasi (compensated) Akhirnya, Terminated Event menghentikan seluruh proses, termasuk semua proses paralel. 2. Connecting objects Connecting objects digunakan untuk mewakili bagaimana objek terhubung. Ada tiga jenis objek penghubung, diilustrasikan pada Gambar 5.5, yang akan dijelaskan selanjutnya. Gambar 5.5. Connecting Object Sequence ﬂow mewakili batasan urutan antara flow object. Ini adalah objek penghubung dasar dalam workflow. Sequence flow menyatakan bahwa jika dua aktivitas dihubungkan oleh workflow, aktivitas target akan dimulai hanya ketika sumbernya telah selesai. Jika beberapa Sequence ﬂow (Multiple sequence flow) keluar dari suatu aktivitas, semuanya akan diaktifkan setelah eksekusinya. Jika ada kebutuhan untuk mengontrol sequence ﬂow, dimungkinkan untuk menambahkan kondisi ke sequence ﬂow dengan menggunakan conditional sequence ﬂow. sequence ﬂow dapat diatur sebagai default flow jika terjadi banyak outgoing flow. Message ﬂow mewakili pengiriman dan penerimaan pesan antara batas-batas organisasi (yaitu, pool, dijelaskan di bagian swimlane). Message ﬂow adalah satusatunya objek penghubung yang dapat melewati batas pool dan juga dapat terhubung ke objek aliran di dalam pool itu. Asosiasi/Association menghubungkan artefak (seperti anotasi) dengan ﬂow objects (seperti activity). Asosiasi dapat menunjukkan arah menggunakan panah terbuka, misalnya, saat menautkan aktivitas kompensasi jika terjadi penanganan kesalahan. Sebuah loop (lihat Gambar 5.6) mewakili eksekusi berulang dari suatu proses selama kondisi looping yang mendasarinya benar. Kondisi ini harus dievaluasi untuk setiap iterasi loop dan dapat dievaluasi pada awal atau akhir iterasi. Gambar 5.6. Activity and subprocess loops Dalam contoh Gambar 5.7, kita melihat sebuah task dalam proses ETL yang terhubung ke server. Pada tingkat abstraksi yang tinggi, aktivitas subproses menyembunyikan detailnya. Ini memiliki simbol loop yang terpasang (panah melengkung), yang menunjukkan bahwa subproses dieksekusi berulang kali sampai kondisi akhir tercapai. Ketika kita memperluas subproses, kita dapat melihat apa yang terjadi di dalamnya: server menunggu selama 3 menit (tugas menunggu ini diwakili oleh time event). Jika koneksi tidak dibuat, permintaan koneksi diluncurkan lagi. Setelah 15 menit (time event lagi), jika sambungan tidak tercapai, task dihentikan, dan email kesalahan dikirim (message event). Gambar 5.7. Contoh loop subproses 3. Swimlanes Swimlane (lihat Gambar 5.8) adalah objek terstruktur yang terdiri dari pool dan lane. Keduanya digunakan untuk mendefinisikan batas proses. Hanya message yang diizinkan di antara dua pool, bukan sequence ﬂows. Dengan kata lain, workflow harus dimuat hanya dalam satu pool. Namun, pool dapat dibagi menjadi beberapa lanes, yang mewakili peran atau layanan dalam perusahaan. Lane di dalam pool tidak memiliki special constraints, dan dengan demikian sequence ﬂows dapat melintasi lane dengan bebas. Gambar 5.8. Swimlanes: pool dan lane 4. Artifacts Artefak digunakan untuk menambahkan informasi ke diagram. Ada tiga jenis artefak. Objek data mewakili data yang dimasukkan ke dalam suatu proses, data yang dihasilkan dari suatu proses, data yang perlu dikumpulkan, atau data yang perlu disimpan. Sebuah Group mengatur tugas atau proses yang memiliki beberapa jenis signifikansi dalam model keseluruhan. Sebuah grup tidak mempengaruhi aliran dalam diagram. Anotation/Anotasi digunakan untuk menambahkan informasi tambahan ke objek aliran. Misalnya, anotasi untuk aktivitas dalam proses ETL dapat menunjukkan kondisi gateway atau atribut yang terlibat dalam lookup task, seperti yang ditunjukkan pada Gambar 5.9. Anotasi dapat dikaitkan dengan aktivitas dan subproses untuk menggambarkan semantiknya. Gambar 5.9. Artefak BPMN: anotasi C. Conceptual Design of the Northwind ETL Process Di bagian ini, dengan menggunakan konsep yang dijelaskan di bagian sebelumnya, kami menyajikan model konseptual dari proses ETL yang memuat/load data warehouse Northwind dari database operasional dan sumber lainnya. Data operasional berada dalam database relasional, yang skema logisnya ditunjukkan pada Gambar 5.10. Data ini harus dipetakan ke data warehouse, yang skemanya diberikan pada Gambar 5.11. Selain database operasional, beberapa file lain diperlukan untuk memuat data warehouse. Gambar 5.10. Skema database operasional Northwind Gambar 5.11. Schema dari Northwind data warehouse Kita dapat melihat pada Gambar 5.11 bahwa di Northwind data warehouse tabel dimensi Customer dan Supplier berbagi hierarki geografis mulai dari level City. Data untuk hierarki State → Country → Continent dimuat dari file XML bernama Territories.xml yang dimulai seperti yang ditunjukkan pada Gambar 5.12a. Representasi grafis dari skema file XML ditunjukkan pada Gambar 8.12b. Di sini, persegi panjang mewakili elemen XML, dan persegi panjang bulat mewakili atribut XML. Kardinalitas hubungan juga ditunjukkan. Perhatikan bahwa type adalah atribut State yang berisi, misalnya, nilai state untuk Austria. Namun, untuk Belgia mengandung nilai provinsi (tidak ditunjukkan pada gambar). Perhatikan juga bahwa EnglishStateName, RegionName, danRegionCode adalah opsional, seperti yang ditunjukkan oleh kardinalitas 0..1. Gambar 5.12. (a) Awal dari file Territories.xml. (b)XML skema file Perlu dicatat bahwa atribut Region dari tabel Customers and Suppliers di database Northwind sebenarnya berisi nama negara bagian atau provinsi (mis., Qu´ebec) atau kode negara bagian (mis., CA). Demikian pula, atribut Negara berisi nama negara (mis., Kanada) atau kode negara (mis., AS). Untuk mengidentifikasi negara bagian atau provinsi mana yang dimiliki sebuah kota, sebuah file bernama Cities.txt digunakan. File berisi tiga field yang dipisahkan oleh tab dan dimulai seperti yang ditunjukkan pada Gambar 5.13a, di mana baris pertama berisi nama field. Dalam kasus kota-kota yang terletak di negara-negara yang tidak memiliki negara bagian, seperti halnya Singapura, nilai nol diberikan untuk field kedua. File di atas juga digunakan untuk mengidentifikasi kota mana dalam atribut TerritoryDescription dari tabel Territories dalam database Northwind yang sesuai. Tabel sementara di gudang data, dilambangkan TempCities, akan digunakan untuk menyimpan konten file ini. Struktur tabel diberikan pada Gambar 5.13b. Gambar 5.13. (a) Awal dari file Cities.txt. (b) Associated table TempCities Perlu dicatat bahwa key dari database operasional digunakan kembali di gudang data sebagai key pengganti/surrogate key untuk semua dimensi kecuali untuk dimensi Customer. Dalam dimensi ini, key database operasional disimpan dalam atribut CustomerID, sementara key pengganti baru dibuat selama proses ETL. Selain itu, untuk tabel Sales di Northwind data warehouse, diperlukan transformasi berikut: 1. Atribut OrderLineNo harus dibuat dalam urutan ascending dari ProductID (dalam database operasional, tidak ada nomor baris pesanan). 2. Atribut SalesAmount harus dihitung dengan mempertimbangkan harga satuan, diskon, dan kuantitas. 3. Atribut Freight, yang dalam database operasional terkait dengan seluruh pesanan, harus didistribusikan secara merata di antara baris pesanan. Gambar 5.14 memberikan gambaran umum dari keseluruhan proses ETL. Gambar menunjukkan tugas kontrol yang diperlukan untuk melakukan transformasi dari database operasional dan file tambahan yang disajikan di atas dan loading data yang diubah ke dalam gudang data. Kita dapat melihat bahwa proses dimulai dengan start even, diikuti oleh activities (dengan subproses) yang dapat dilakukan secara paralel (diwakili oleh splitting parallel gateway) yang mengisi hierarki dimensi. Akhirnya, splitting parallel gateway menyinkronkan flow, yang berarti bahwa proses loading fact table Sales (activities Sales Load) hanya dapat dimulai ketika semua task lainnya telah diselesaikan. Jika proses gagal, cancelation event terpicu dan pesan kesalahan dalam bentuk email dikirim. Gambar 5.14. Tampilan keseluruhan proses ETL konseptual untuk gudang data Northwind Gambar 5.15 menunjukkan task yang me-load tabel Category di gudang data. Task ini hanya terdiri dari sebuah input data task dan sebuah insertion data task. Yang pertama membaca tabel Category dari database operasional. Yang terakhir memuat tabel Category di gudang data, di mana atribut CategoryID dalam tabel Category dipetakan ke atribut CategoryKey di tabel Category. Demikian pula, Gambar 5.16 menunjukkan task yang me-load tabel Time dari file Excel. Ini mirip dengan task yang dijelaskan sebelumnya tetapi mencakup konversi kolom, yang mendefinisikan tipe data dari atribut tabel target Time di gudang data, dan penambahan kolomTimeKey yang diinisialisasi dengan nilai nol sehingga database dapat menghasilkan kunci pengganti untuk atribut ini. Kami tidak menampilkan task yang memuat tabel TempCities seperti yang ditunjukkan Gambar 5.13b, karena ini mirip dengan task yang memuat tabel Category yang baru saja dijelaskan, kecuali bahwa data dimasukkan dari file, bukan database. Gambar 5.15 Load tabel dimensi Category Gambar 5.16 Load tabel dimensi Time D. The Northwind ETL Process in Integration Services Di bagian ini, kami menunjukkan implementasi dalam Layanan Integrasi dari proses ETL yang memuat Northwind data warehouse. Dalam implementasi kami, database operasional Northwind dan Northwind data warehouse terletak di database SQL Server. Gambar 5.17 menunjukkan proses ETL secara keseluruhan. Proses terdiri dari satu sequence container task (yang memiliki panah biru di sebelah kiri) dan sebelas data ﬂow tasks. Semua task ini dihubungkan oleh batasan prioritas, yang diwakili oleh panah hijau. Anda dapat membandingkan representasi ini dengan yang ada pada Gambar 5.14. Perhatikan bahwa gateway tidak ada, tetapi semantik dari panah yang menghubungkan sangat mirip: tidak ada task yang dapat dimulai sampai semua task yang mendahului selesai. Gambar 5.17. Tampilan keseluruhan dari proses ETL di Layanan Integrasi/Integrated Service Beberapa data ﬂow tasks sederhana. Misalnya, task yang me-load tabel Category diberikan pada Gambar 5.18a (bandingkan dengan Gambar 5.15), di mana data ﬂow tasks adalah OLE DB Source task yang membaca seluruh tabel dari database operasional dan DB OLE Destination task yang menerima output dari task sebelumnya dan menyimpannya di gudang data. Aliran data serupa digunakan untuk memuat tabel Product, Shipper,dan Employee. Tugas sederhana lainnya adalah data flow memuat tabel dimensi Time, yang ditunjukkan pada Gambar 5.18b. Setelah memuat file Excel sumber, data conversion transformation diperlukan untuk mengubah tipe data dari file Excel menjadi tipe data database. Kita juga dapat melihat bahwa ini sangat mirip dengan spesifikasi konseptual yang digambarkan pada Gambar. 5.16, kecuali bahwa penambahan kolom kunci pengganti tersirat dalam task Time Load. Gambar 5.18 Load tabel dimensi Category (a) dan Time (b) Di beberapa tabel, kunci database operasional digunakan kembali sebagai kunci pengganti/surrogate key di gudang data, sedangkan di tabel lain kunci pengganti harus dibuat di gudang data. Oleh karena itu, pemetaan kolom dalam task OLE DB Destination harus dilakukan dengan salah satu cara yang ditunjukkan pada Gambar 5.19. Misalnya, untuk tabel Category (Gbr. 5.19a), kita menggunakan kembali kunci dalam database operasional (CategoryID) sebagai kunci dalam gudang data (CategoryKey). Di sisi lain, untuk tabel Customer (Gbr. 5.19b), kunci CustomerID dalam database operasional disimpan di kolom CustomerID di gudang data, dan nilai baru untuk CustomerKey dihasilkan selama insertion/penyisipan di gudang data. Gambar 5.19. Pemetaan source dan destination columns, tergantung pada apakah kunci dalam database operasional digunakan kembali di gudang data Gambar 5.20 menunjukkan data flow yang digunakan untuk memuat tabel TempCities dari file teks Cities.txt. Data conversion transformation diperlukan untuk mengubah tipe default yang diperoleh dari file teks ke dalam tipe database. Gambar 5.20. Load tabel TempCities Gambar 5.21a menunjukkan aliran data yang memuat hierarki yang terdiri dari tabel Continent, Country, dan State. Sequence Container digunakan untuk tiga aliran data yang memuat tabel hierarki. Karena Continent adalah level tertinggi dalam hierarki, pertamatama kita perlu membuat kunci untuknya, sehingga nanti dapat dirujuk dari level Country. Aliran data untuk memuat tabel Continent diberikan pada Gambar 5.21b. Konversi data diperlukan untuk mengubah tipe data dari file XML menjadi tipe data database. Ini ditunjukkan pada Gambar. 5.22, di mana ContinentName, dibaca dari file XML, secara default dengan panjang 255, dan diubah menjadi string dengan panjang 20. Akhirnya, tabel Continent dimuat, dan ContinentKey secara otomatis dihasilkan . Gambar 5.21. (a) Load tabel untuk hirarki Continent → Country → State. (b) Load tabel dimensi Continent. (c) Load tabel dimensi Country Gambar 5.22. Konversi tipe data yang dimasukkan dari file XML Data flow yang me-load tabel Country diberikan pada Gambar 5.21c. Sebuah merge join transformation diperlukan untuk mendapatkan ContinentName yang sesuai untuk Country tertentu. Transformasi konversi data diperlukan untuk mengubah tipe data dari file XML menjadi tipe data database. Kemudian, lookup transformation diperlukan untuk mendapatkan, dari database, ContinentKey yang sesuai dengan ContinentName. Atribut ini juga ditambahkan ke dalam flow. Terakhir, tabel Country dimuat secara analog dengan tabel Continent di atas. Perhatikan bahwa aliran data yang memuat tabel State serupa; oleh karena itu, kami menghilangkannya. Gambar 5.23 menunjukkan aliran data untuk memuat tabel City. Aliran data perlu dikaitkan ke setiap kota di tabel TempCities baik StateKey atau CountryKey, tergantung pada apakah negara terkait terdiri dari negara bagian (state) atau tidak. Untuk ini, split bersyarat menguji apakah State itu bernilai nol atau tidak. Gambar 5.23. Proses Load dari table dimensi City KESIMPULAN 1. Proses ekstraksi, transformasi, dan loading (ETL) digunakan untuk mengekstrak data dari sumber internal dan eksternal organisasi, mengubah data ini, dan memuatnya/load ke dalam data warehouse. 2. Business Process Modeling Notation (BPMN) terdiri: flow object, connecting object, swimlanes, artifact. DAFTAR PUSTAKA 1. Alejandro Vaisman, Esteban Zimanyi. (2014). Data Warehouse System Design and Implementation. Springer Verlag Berlin. ISBN 978-3-642-54655-6

20220818170828_ISYS6332-LN5-R1.pdf

Document Details

Tags

Related

Full Transcript

Upgrade to continue