1 Isnu Febriadi - 5108100512 Abstrak – Fleksibilitas, adanya perbedaan dan produktivitas menjadi fokus utama ERP saat ini. Berbagai perusahaan melihat ketiga faktor tersebut sebagai suatu masalah yang cukup berpengaruh dalam aktivitas– aktivitas bisnis perusahaan. Account payable, Account Receivable serta Fixed Asset merupakan bagian dari aktivitas-aktivitas untuk pengelolaan keuangan dalam hal pembuatan jurnal. Apabila ini masalah ini bertahan sampai sekarang, maka akan terjadi pengeluaran cost tak terduga yang dialami oleh perusahaan.
Disinilah peran SOA untuk memecahkan masalah tersebut. Dengan menggunakan web services sebagai media perantara untuk menyediakan layanan,yang berisi tentang proses bisnis internal maupun eksternal pada perusahaan, membuat integrasi serta pengelolaan data menjadi lebih mudah untuk dikelola
.
Kata kunci: Service Oriented Analysis (SOA), Web Services, Account Payable, Account Receivable, Fixed Asset
1. Pendahuluan
Secara garis besar, manajemen keuangan pada perusahaan merupakan suatu kegiatan pengendalian aliran keuangan secara khusus ataupun periodik yang ditujukan ke internal perusahaan maupun eksternal perusahaan. Saat ini, manajemen keuangan beberapa perusahaan sudah menerapkan sistem Enterprise untuk meningkatkan produktivitas manajemennya. Tetapi, adanya suatu pengaruh dari luar yang menuntut manajemen keuangan perusahaan untuk beradaptasi secara cepat, menyebabkan sistem menjadi kompleks kembali.
Dengan menerapkan sistem integrasi, segala permasalahan di manajemen keuangan yang kompleks dapat diatasi. Sebagai contoh, jika melakukan pembelanjaan di Amazon.com, disana telah tersedia catalog buku yang dibutuhkan dan bebas untuk memilihnya. Jika tertarik untuk membeli, maka proses selanjutnya adalah memasukkan informasi yang dibutuhkan misal kartu kredit. Data kartu kredit pelanggan tersebut harus di validasi kaitannya dengan nomer PIN, masa berlaku, saldo dan sebagainya. Amazon.com tidak berhak untuk melakukan validasi data yang terdapat di kartu kredit, karena perusahaan yang berwenang adalah bank . Untuk itu Amazon.com melakukan kerjasama dengan beberapa bank, agar diberikan kemudahan dalam transaksi on-line tersebut. Sehingga Amazon.com hanya akan melakukan pengecekan terhadap kartu kredit tersebut dengan memanggil service yang disediakan oleh beberapa bank.
Dari ilustrasi diatas, SOA sangat tepat untuk diterapkan karena memiliki beberapa sifat, antara lain : antara lain : loosely coupled (tingkat ketergantungan antar komponen rendah), higly interoperable (mudah dioperasikan), reusable (dapat digunakan kembali), dan interoperability
(dapat berkomunikasi antar platform tanpa memperhatikan vendor pembuat ).
Dengan menggunakan SOA, dapat dijadikan solusi permasalahan sistem yang kompleks dan terbentuk suatu infrastruktur yang terkelola dengan baik, fleksibel serta adaptif. Dan juga tentunya akan meningkatkan kinerja perusahaan, yaitu mengendalikan segala perubahan–perubahan yang terjadi dan kemudahan memelihara sistem.
2. Dasar Teori
Bagian ini akan menjelaskan dasar-dasar teori yang menyusun makalah ini yaitu :
2.1 SOA
Secara singkat SOA diartikan sebagai sebuah permodelan perangkat lunak yang dibangun dengan pendekatan service oriented yang merupakan sebuah pendekatan yang memiliki visi ideal di mana setiap resource dari perangkat lunak terpartisi secara bersih satu sama lain [1].
SOA menerapkan pendekatan bottom-up yang berawal dari mengimplementasikan class-class yang telah dirancang hingga menyediakan service sesuai dengan proses bisnis. Berikut ini gambaran dari pendekatan Bottom-up dari SOA :
Application 1 Application 3 SV1 SV2 SV3 Service Layer Application Landscape Bussiness Layer BP1 BP2
Gambar 1 Pendekatan Bottom-Up dari SOA
Rancang Bangun Perangkat Lunak
Untuk Account Payable, Account Receiveable dan Fixed Asset
Menggunakan Metode Service Oriented Architecture (SOA)
Isnu Febriadi, Riyanarto Sarno, Rizky Januar Akbar
Jurusan Teknik Informatika, Fakultas Teknologi Informasi, Institut Teknologi Sepuluh Nopember
2 Isnu Febriadi - 5108100512 2.2 SOAD
Untuk dapat mengetahui service yang disediakan itu baik sehingga implementasi SOA diterapkan bisa dikatakan berjalan sesuai rencana atau berhasil, penggunaan Service Oriented Analysis and Design (SOAD) sangat dibutuhkan karena merupakan sebuah permodelan yang menerapkan suatu kedisplinan dalam pembangunan implementasi SOA yang sistematis.
Component 1 Component 2 Component 3 SV1 SV2 SV4 Service Layer Component Layer Bussiness Layer Bussiness Service Bussiness Process Functional Domain FD 1 BP 1 BP 2 BS 1 BS 2
Gambar 2 Hirarki pendekatan dari SOA Hirarki diatas menunjukkan pendekatan Top-down yang mempunyai tiga layer, yaitu Bussiness Layer, Service Layer dan Component Layer. Bussiness Layer berisi tentang segala aktivitas yang ada di perusahaan. Cakupan masalah dari aktivitas yang terjadi tergambar pada functional domain. Bussiness Proses menjelaskan tentang aktivitas-aktivitas yang ingin dicapai perusahaan yang kemudian akan didetailkan menjadi bussiness services sebagai layanan-layanan proses bisnis. Di Service Layer, akan direalisasikan ke dalam bentuk webservice yang mengambil fungsi dari komponen- komponen pada Component layer.
Pendekatan Bottom-up (pada Gambar 1) untuk melakukan analisis terhadap asset yang ada, yang merupakan kandidat untuk komponen dan service yang nantinya akan di-expose. Bisa disebut juga sebagai proses identifikasi software service di layer Service, yang mungkin akan digunakan atau tidak dalam penyusunan proses bisnis. Terlihat pada Gambar 1, Application Landscape akan mengekspos service yang dibutuhkan sesuai dengan business layers dan mengidentifikasi kecocokan service melalui kedua metode yaitu pendekatan Top-down dengan Bottom-up.
Agar dapat memahami pola Top-down dari SOAD lebih jauh, berikut ini adalah gambaran dari pola yang mempunyai tiga sudut pandang [5], yaitu
- Functional Domain Diagram - Mapping of the functional domains - Business Process Activity Diagram (BPAD) - Sub Business Process Activity Diagram (SBPAD) - Stakeholder
- Workflow
- Matrix of the Business Service versus the Business Entities - Business Service Activity Diagram
- Web Service Layer, including web methods - Presentation Layer
- Application Service Layer, including methods - Domain Model Layer, including components, classes, class activity diagram, and sequence diagram - Data Access Layer
Conceptual View Physical View Logical View
Gambar 3 Service Portofolio Views 2.3 DDD
Domain Design Driven [3] merupakan sebuah pendekatan yang bagaimana untuk memodelkan core logic dari sebuah aplikasi. Yang mendasari terciptanya adalah bagaimana caranya design dari perangkat lunak harus langsung mencerminkan domain dan domain-logic dari (bussiness) problem yang dapat diselesaikan sesuai dengan kebutuhan perangkat lunak. Sehingga dapat membantu pemahaman permasalahan serta pengimplementasian dan juga meningkatkan maintenance dari software.
Sebagai permisalan, ketika para developer tidak pernah cukup mengetahui problem yang dihadapinya. Sebaliknya, domain experts lebih mengetahui segala aktivitas domain yang mereka bentuk dan tentunya sebagai developer harus bisa memahaminya. Tetapi, seringkali domain experts tidak sadar menggunakan tersebut karena sudah merupakan hal yang wajar untuk merancang sistem yang ingin mereka bangun. Oleh karena itu, diperlukan pengindentifikasian model domain yang tepat untuk memberikan solusi antara kedua belah pihak. Pengunaan bahasa yang umum antara users (domain experts) dan developers, benar–benar diperlukan untuk membantu memahami domain dan permasalahannya, bisa dikatakan domain model telah menawarkan sebuah kesederhanaan, abstraksi view dari permasalahan. Biasanya, model sebuah domain dapat digambarkan sebagai sketsa UML, sebagai code, dan dalam bahasa domain. 2.4 Functional Domain
Berikut ini penjelasan sekilas tentang functional domain yang akan digunakan sebagai cakupan dalam pembangunan perangkat lunak, diantaranya :
a. Account Payable
Berfungsi untuk mengelola akun perusahaan terhadap hutang yang dimiliki, akibat adanya transaksi pembelian barang atau jasa secara kredit ataupun tunai [5]. Fungsi- fungsi yang disediakan di Account Payable antara lain : Purchase Down payment, Credit Adjustment ,Debit Adjustment, Purchase Invoice , dan Purchase Return Invoice.
3 Isnu Febriadi - 5108100512 b. Account Receivable
Berfungsi untuk mengelola piutang perusahaan.karena adanya penjualan barang atau jasa secara kredit maupun tunai kepada customer [5]. Fungsi- fungsi yang disediakan di Account Receivable antara lain : Sales Down payment, Credit Adjustment ,Debit Adjustment, Sales Invoice , dan Sales Return Invoice. c. Fixed Asset
Berfungsi untuk mengelola aktiva tetap perusahaan [5]. Fungsi-fungsi yang disediakan di Fixed Asset antara lain : Fixed Asset Additional, Fixed Asset Transfer, Fixed Asset Depreciation, Fixed Asset Revaluation, Fixed Asset Disposal, Fixed Asset Maintenance, dan Fixed Asset Stoke Take
3. Analisis
Untuk mencapai SOA, harus memahami permasalahan yang telah dimodelkan melalui Service Oriented Analysis and Design (SOAD). Dengan metode Top-down nya yang mempunyai tiga sudut pandang yaitu conceptual view,logical view serta physical view dan SOA yang menerapkan metode Bottom-up, menyebabkan kesalahan dalam membangun suatu aplikasi dapat diminimalkan. SOA akan membaca permodelan tersebut dari sudut pandang yang terakhir yaitu physical view. Di sudut pandang ini, akan dimulai suatu arsitektur aplikasi yang mendasari terbentuknya suatu aplikasi. Arsitektur ini akan bermula dari pengimplementasian class-class dan melakukan interaksi dengan database hingga menyediakan proses bisnis internal maupun eksternal perusahaan. Proses bisnis yang disediakan harus sesuai dengan apa yang dimodelkan oleh SOAD.
Arsitektur Perangkat Lunak
Arsitektur merupakan suatu perancangan terhadap struktur yang kompleks.Arsitektur perangkat lunak yang akan dibangun terdiri dari lima layer yaitu :
Data Access Layer – Layer ini memiliki tanggung jawab operasional ke database Domain Layer– Layer ini berisi implementasi class- class yang merupakan gambaran domain permasalahan yang digunakan untuk dasar pembangunan perangkat lunak.
Application Service Layer – Layer ini berisi bussines logic dari dibutuhkan oleh Presentation Layer dan Web Services Layer. Presentation Layer – Layer ini merupakan user interface yang terdiri kumpulan bussiness logic yang berasal dari Application Service Layer.
Web Service Layer – Layer ini berisi implementasi dari web service yang disediakan aplikasi. Presentation Layer FunctionalDomain.Web Application Service Layer FunctionalDomain.Service.Application Data Access Layer DAO Implementation FunctionalDomain.Data Web Service Layer FunctionalDomain.Service.Web Domain Layer Impleme ntation Do main Obje ct Function alDo main .Core
* FunctionalDomain = Account Payable Account Receivable Fixed Asset
ORM Nhibernate 2.1
ORACLE 11g
Gambar 4 Arsitektur Perangkat Lunak
4. Perancangan
Bagian ini mengacu pada perancangan yang telah didesain oleh designer [5] yang membahas gambaran suatu pembuatan perangkat lunak sebelum di implementasikan ke dalam suatu aplikasi. Agar terlaksana dengan pencapaian maksimal, maka penerapannya menggunakan metode Bottom-up dari SOA, yang dimulai dari interaksi ke layer paling terendah (Data Access Layer) sampai menuju titik puncak yaitu Presentation Layer dan Web Services.
5. Uji Coba dan Evaluasi
Pada bagian ini akan dibahas pengujian dari fitur-fitur aplikasi yang sudah dibuat. Pengujian meliputi pengujian proses bisnis internal sampai penyediaan web service untuk aplikasi Account Receivable dengan sub bisnis proses Sales Down Payment.
5.1 Uji coba Aplikasi Account Receivable Uji coba sub proses bisnis Sales Down Payment akan dilakukan dengan memasukkan data yang terlihat pada tabel 1 sedangkan untuk skenario jalannya aplikasi akan dijelaskan pada tabel 2.
Tabel 1 Data Uji Coba
Field Keterangan Data isian
Transaction Date Menentukan tanggal
transaksi 03/05/2010
Transaction
Code Memilih code transaction SDP01
Reference
Number Memasukkan reference number -
Sales Order
4 Isnu Febriadi - 5108100512 Tabel 2 Hasil Uji Coba
Tujuan Menguji fungsionalitas transaksi Sales Down Payment
Aksi Aktor Reaksi Aplikasi Cek 1. User memilih icon sales down payment pada halaman menu utama
2. Aplikasi menampilkan list record data yang telah tersimpan 3. User memilih tekan add record 4. User menginputkan data uji
5. Muncul pesan berhasil
Gambar 5 Output Sales Down Payment 5.2 Uji coba Account Receivable Web Services
Uji coba AR Web Service akan dilakukan dengan memasukkan data yang terlihat pada tabel 4 sedangkan untuk skenario jalannya fungsionalitas service akan dijelaskan pada tabel 5.
Tabel 3 Data Uji Coba WebService
Web Service Method Data Isian
ARAdjustment
Service ditAdjusmentJournal PostAccountPayableCre ( 01/01/2010 , 12/12/2010 )
PostAccountPayableDebi
tAdjusmentJournal ( 01/01/2010 , 12/12/2010 )
ARDownPay
mentService entJournal PostPurchaseDownPaym ( 01/01/2010 , 12/12/2010 )
ProvidePurchaseDownP
aymentInvoiceData SDP01/09/2010/002
ARInvoiceSer
vice rnal PostPurchaseJournalJou ( 01/01/2010 , 12/12/2010 )
ProvidePurchaseInvoice
Data ARI01/09/2010/003
ARReturnInvo
iceService iceJournal PostPurchaseReturnInvo ( 01/01/2010 , 12/12/2010 )
ProvidePurchaseRetur nInvoiceData
SRI03/05/201 0/001
Di bawah ini akan dijelaskan tentang skenario pengujian salah satu web service yang terdapat pada account receivable yaitu ARDownPayment Service
Tabel 4 Skenario Uji Coba WebService
Tujuan Menguji fungsionalitas ARDownPayment Aksi
Aktor Reaksi Aplikasi Cek 1. User memilih web service 2. User memilih “browse with..” 3. User melakukan input data uji
4. Internet
explorer yang dipakai user sebagai media uji coba web service
5. Aplikasi akan
menampilkan web browser beserta web method dari web service 6. User memilih web method ProvideSales DownPaymen tInvoiceData 7. User menginputkan data uji 8. User menekan tombol invoke 9. Web browser menampilkan XML yang berisi data APinvoce
Gambar 6 Hasil Uji Coba AR DownPayment Service
6. Kesimpulan
Berdasarkan pengamatan selama proses perancangan, implementasi dan uji coba, dapat diambil kesimpulan :
1. Implementasi SOA dan adanya dukungan Enterprise Architecture yang dirancang oleh designer, memudahkan developer dalam membangun suatu aplikasi.
2. Penggunaan web service yang diimplementasikan dalam pengintegrasian data akan membuat user memahami data yang akan dikelola.
5 Isnu Febriadi - 5108100512 7. Daftar Pustaka
1. Erl, Thomas.(2005) Service-Oriented Architecture: Concepts, Technology, and Design. Prentice Hall PTR.
2. IBM. (2004). Patterns: Elements of Service-Oriented Analysis and Design, <url:
http://www.ibm.com/developerworks/library/w s-soad1/> , diakses tanggal 10 Juli 2010. 3. Sarno, R. and Herdiyanti, A. (May 2010),
“Developing Information Technology Policies for Enterprise Resource Planning to Improve Customer Orientation and Service”, International Journal of Computer Science and Network Security, ISSN – 1738 – 7906, Vol. 10, No. 5, pp. 82-94.
4. Sarno, R. and Herdiyanti, A. (March 2010), “A Service Portfolio for an Enterprise Resource Planning”; International Journal of Computer Science and Network Security, ISSN – 1738 – 7906, Vol. 10, No. 3, pp. 144-156.
5. Evans, Eric.(2004) Domain-Driven Design : Tackling Complexity in the Heart of Software 6. Khan,Aslam.(2009) Getting Started with
Domain-Driven Design
7. Oktavianty,Ikti .(2010). Service Oriented and Design (SOAD) untuk Perangkat Lunak Account Payable, Account Receivable dan
Fixed Asset dan Pembangunan
