Rancang Bangun Orkestrasi Web Service serta Implementasi Single Sign On pada Enterprise Resource Planning

Transkripsi

1 Rancang Bangun Orkestrasi Web Service serta Implementasi Single Sign On pada Enterprise Resource Planning Riyanarto Sarno 1, Ahmad Dzulfikar Adi Putra 2, Dwi Sunaryono 3 1,2,3 Jurusan Teknik Informatika, Fakultas Teknologi Informasi, Institut Teknologi Sepuluh Nopember Kampus ITS Sukolilo Surabaya, 60111, Indonesia 1 riyanarto@gmail.com, 2 dzulfikar.adiputra@gmail.com, 3 dwi.syn@gmail.com Abstrak Pada Enterprise Resource Planning (ERP) yang disusun dari beberapa aplikasi/domain yang berdiri sendiri, proses bisnis yang spesifik ditangani pada masing-masing domain. Proses bisnis pada ERP sebagian besar merupakan aliran informasi data yang berjalan dari satu domain ke domain lainnya. Pada beberapa proses bisnis antar domain yang masih dilakukan secara manual sebenarnya dapat dilakukan otomatisasi. Otomatisasi proses bisnis dapat dilakukan melalui komposisi web service yaitu orkestrasi web service. Pada ERP autentikasi pengguna merupakan hal penting. Ini karena pada ERP tiap-tiap pengguna mempunyai hak akses tertentu, sehingga autentikasi pengguna diperlukan agar pengguna dapat mengakses resources yang sesuai dengan hak aksesnya. Implementasi autentikasi pengguna akan menjadi masalah tersendiri jika penerapannya pada ERP yang terdiri dari domain yang berdiri sendiri-sendiri sehingga diperlukanlah autentikasi pengguna secara terpusat. Single Sign On merupakan solusi efektif untuk menangani permasalahan autentikasi pengguna secara terpusat. Implementasi orkestrasi web service menggunakan Business Process Excecution Language (BPEL) yang merupakan bahasa standard untuk mengeksekusi proses bisnis menggunakan beberapa web service dimana urutan eksekusinya didefinisikan di dalam dokumen BPEL itu sendiri. Manfaat dari implementasi orkestrasi web service ini ialah suatu proses bisnis pada ERP yang biasanya dilakukan secara manual dapat diotomatisasi. Selain itu dampaknya ialah efisiensi kerja serta mengurangi redundansi data pada ERP. Implementasi Single Sign On pada tugas akhir ini mengunakan framework Java Open Single Sign On (JOSSO) yang memiliki arsitektur Gateway Server sebagai pusat autentikasi pengguna, Agent Server sebagai server yang didalamnya terdapat aplikasiaplikasi penyusun ERP, dan Persistence sebagai tempat menyimpan credential pengguna.aplikasi-aplikasi penyusun ERP dalam tugas akhir ini menggunakan desain basis data multi-skema untuk menghasilkan aplikasi sebagai layanan bagi beberapa perusahaan manufaktur. Sehingga dalam implementasi Single Sign On multi-perusahaan autentikasi pengguna berdasarkan credential pengguna yang terdapat pada skema-skema yang ada pada basis data. Implementasi Single Sign On untuk multiperusahaan pada tugas akhir ini mampu menangani autentikasi pengguna yang berasal dari berbagai perusahaan.sehingga apabila ada beberapa pengguna dari perusahaan yang berbeda mengakses aplikasi ERP yang sama, aplikasi akan memberikan data yang sesuai dengan perusahaan dimana ia bekerja. Selain itu dengan adanya single sign on, pengguna tidak perlu login setiap kali mengakses aplikasi/resource yang berbeda pada ERP. Kata kunci : orkestrasi web service, ERP, single sign on, multi-perusahaan 1. Pendahuluan Enterprise resource planning (ERP) merupakan salah satu solusi sistem informasi terintegrasi dan terpadu yang digunakan oleh sebuah perusahaan dalam menjalankan bisnisnya. ERP mencakup beberapa domain fungsi yang saling terintegrasi sehingga menjadi sebuah kesatuan sistem yang tepadu. Integrasi dalam ERP mencakup integrasi dalam hal proses bisnis serta integrasi dalam hal manajemen pengguna. Masalah yang sering dihadapi dalam pengimplementasian ERP dalam perusahaan yaitu dalam menjalankan bisnisnya tiap perusahaan pasti memiliki kebijakan yang tidak sama dengan perusahaan lainnya. Walaupun dalam membangun ERP sudah didasarkan pada best-practice namun tetap saja hal-hal seperti itu tidak bisa dihindari. Service Oriented Architecture (SOA) adalah sebuah gaya arsitektural yang memodularisasi sistem informasi menjadi services. SOA adalah sebuah framework yang mengintegrasikan proses bisnis dan mendukung infrastruktur IT yang aman, berkomponen terstandarisasi

2 (services) yang dapat digunakan kembali dan disertakan dalam prioritas bisnis yang berubah. Service didefinisikan sesuai dengan kebutuhan spesifik bisnis yang dikelompokkan ke dalam proses-proses bisnis yang ada. Dengan membangun aplikasi berbasis SOA, maka aplikasi tersebut akan lebih mudah untuk diintegrasikan dan dimodifikasi apabila terjadi perubahan karena setiap service yang ada sudah memiliki standar yang dapat direuse dan digunakan antar domain fungsi yang berbeda. Pada ERP autentikasi pengguna merupakan hal yang sangat penting ini karena pada ERP tiap-tiap pengguna mempunyai hak akses tertentu,sehingga autentikasi pengguna diperlukan agar pengguna dapat mengakses resources yang sesuai dengan hak aksesnya ERP. Implementasi autentikasi pengguna akan menjadi masalah tersendiri jika penerapannya pada ERP yang terdiri dari domain yang berdiri sendiri-sendiri sehingga diperlukanlah autentikasi pengguna secara terpusat. 2. Analisis dan Desain Pada pembuatan perangkat lunak, proses analisis dan desain merupakan fase yang penting karenapada tahap inilah dirancang perangkat lunak yang akan dibuat. 2.1 Domain Permasalahan Domain permasalahan yang diangkat pada pengerjaan tugas akhir ini dibagi menjadi dua bagian yaitu orkestrasi web service dan single sign on pada ERP 2.1.1Orkestrasi Web Service Sistem ERP yang sudah ada biasanya didesain dan dibangun untuk dapat berdiri sendiri, namun tetap terintegrasi antar aplikasi-aplikasi penyusun ERP. Namun dalam pengimplementasiannya aplikasi-aplikasi tersebut menjalankan proses bisnis yang berkelanjutan Proses yang berkelanjutan tersebut tentunya memiliki informasi yang mengalir dari satu proses ke proses lainnya dan juga secara logika dapat dilakukan otomatisasi proses tanpa adanya interupsi dari pengguna Domain fungsi di dalam aplikasi orkestrasi web service ini akan diselaraskan pada kebutuhan pada proses bisnis yang terjadi di dalam ERP dengan tujuan untuk melakukan otomatisasi proses. Penerapan orkestrasi pada tugas akhir ini dibagi menjadi dua proses besar, yaitu Proceure to Pay, Order to Cash. Dimana di dalam masingmasing orkestrasi terdapat orkestrasi lagi yang ada pada masing-masing fungsional domain sesuai dengan proses bisnis yang dilakukannya. Sehingga dapat pula dikatakan bahwa ini merupakan orchestration of orchestrated web service. Bentuk otomatisasi proses yang paling mungkin diterapkan dalam orkestrasi Procure to Pay yaitu saat : Receving Approval menuju ke Purchase Invoicing kemudian ke Post Journal ( Approval Automatic Invoicing). Purchase Return Approval menuju ke Invoicing kemudian ke Post Journal (Purchase Return Approval Automatic Invoicing). Bentuk otomatisasi proses yang paling mungkin diterapkan dalam orkestrasi Order to Cash ditunjukkan pada yaitu saat : Sales Order menuju ke Delivery Order atau ke Production Request, dan Delivery Order menuju ke Invoicing kemudian ke Post Journal. (Sales Order Approval Automatic Invoicing) Sales Return menuju ke Invoicing kemudian ke Post Journal (Sales Return Approval Automatic Invoicing) Single Sign On pada Multi-Tenancy ERP Pada tugas akhir ini aplikasi penyusun Enterprise Resource Planning merupakan aplikasi yang terpisah antara satu domain dengan domain lainnya. Ada beberapa hal yang harus diperhatikan, yaitu : ERP terdiri dari beberapa aplikasi web yang saling berkaitan Database yang digunakan terdapat di satu tempat Tiap perusahaan mempunyai data yang terpisah dengan perusahaan lain. Saat pengguna masuk ke sistem akan diarahkan untuk mengakses aplikasi dengan koneksi database yang tepat. Gambar 1 Pengaksesan aplikasi oleh pengguna Dengan ketiga poin diatas maka dipilihlah arsitektur data shared database-separate schema, maka sistem diharuskan mampu menunjukkan koneksi pada database mana yang sesuai untuk tiap perusahaan, seperti ditunjukkan pada Gambar 1. Tabel-tabel yang digunakan tiap perusahaan haruslah memiliki informasi tentang connection string, username database, password database, tipe perusahaan dan informasi lainnya.

3 2.2 Arsitektur Perangkat Lunak Aplikasi enterprise umumnya memiliki arsitektur layer, dimana setiap layer memiliki tanggung jawab berbeda. Tujuan dari diadakannya layering ini adalah sebagai bentuk penyederhanaan problem. Dengan adanya layer, masing-masing layer diberi tanggung jawab berbeda sehingga aplikasi dapat dibangun oleh developer yang berbeda Arsitektur Orkestrasi Web Service Perangkat lunak orkestrasi web service menggunakan beberapa web service dari functional domain lain untuk menjalankan proses bisnisnya, seperti ditunjukkan Gambar 2. Sehingga arsitektur aplikasinya menggunakan 3 layer : Presentation Layer Presentation layer melakukan penanganan tampilan (presentation logic) dan interaksi dengan user (user interface). User Interface merupakan implementasi dari GUI pada level design. Application Service Layer Application service layer adalah bagian dari sistem perangkat lunak yang berhubungan dengan kerja dari tugas-tugas bisnis. Layer ini berisi method-method yang digunakan dalam proses internal aplikasi. Layer ini juga berisi web service reference dari fungsional domain lain. Web service ini akan digunakan oleh method-method untuk menjalankan proses bisnis dalam internal aplikasi. Gambar 2 Arsitektur perangkat lunak orkestrasi web service Java Business Integration (JBI) Runtime Environment JBI menstandardkan packaging untuk composite application yang terdiri dari consumer dan provider. Proses bisnis yang direpresentasikan dengan BPEL kemudian dimasukkan ke dalam composite application untuk kemudian dideploy ke dalam BPEL Engine Arsitektur Multi-Tenancy Single Sign On Arsitektur untuk implementasi multi-tenancy single sign on memiliki arsitektur yang terdiri dari 3 bagian seperti pada Gambar 3,yaitu: Gateway Server Gateway Server berperan sebagai gateway/ sentral dari autentikasi layanan sign-on. Pada gateway server dilakukan autentikasi credential berdasarkan informasi yang terdapat pada Persistence. Gateway Server IDENTITY STORE Persistence Authentication Scheme JOSSO Gateway (Identity Provider) CREDENTIAL STORE Access Persistence DATABASE MYSQL / ORACLE / JAVA DB SESSION STORE Assert identity (SOAP) Agent Server Partner Application X JOSSO Agent Create Security Context Security Infrastructure Delegate Authentication Request Partner Application Y Gambar 3 Arsitektur implementasi single sign on Persistence Persistence merupakan data-store dimana credential pengguna disimpan. Persistence dapat berupa Lightweight Directory Access Protocol (LDAP) ataupun database. Pada tugas akhir ini menggunakan database karena informasi pengguna diambil dari data pegawai yang ada pada aplikasi Human Resource Management / HRM [4] Agent Server Agent Server terdiri dari Partner Application yaitu aplikasi yang di SSO-kan, dan JOSSO Agent sebagai penghubung antara Partner Application dengan JOSSO Gateway. Pada agent server ini nantinya akan dideploy partner application. Partner application aplikasi yang akan dijadikan ujicoba multi-tenancy single sign on, yaitu aplikasi HRM [4] 2.3 Desain Conceptual View Desain conceptual view berisi garis besar desain dari proses bisnis yang ada dalam sistem yang akan dibangun untuk memudahkan pihak manajemen untuk mendefinisikan proses bisnis Dalam sebuah pembangunan suatu aplikasi skala enterprise, institutsi dan individu yang berkepentingan harus diidentifikasi. Ada dua aktor pada aplikasi orkestrasi web service, yaitu Warehouse Staff dan Sales

4 Force. Sedangkan pada aplikasi multi-tenancy single sign on untuk ujicobanya ada satuaktor yaitu HR Staff. uc Stakeholder diagram Accountable Responsible Warehouse Staff Sales Force Human Resource Staff Gambar 4 Stakeholder diagram Dalam workflow diagram, akan digambarkan bagaimana alur dari proses bisnis pada aplikasi Orkestrasi Web Service. Untuk aplikasi orkestrasi web service ada dua workflow diagram yaitu Procure to Pay dan Order to Cash. Gambar 6 Alur Kerja Orkestrasi Proses Order to Cash Business service workflow diagram menggambarkan interaksi antar business service antar proses bisnis dan functional domain. Interaksi ini digambarkan dengan sebuah diagram BPMN. Business Service Workflow Diagram merupakan gambaran yang lebih detail dari penjelasan orkestrasi Procure to Pay dan Order to Cash. Gambar 5 Alur Kerja Orkestrasi Proses Procure to Pay Alur kerja orkestrasi proses pada procure to pay digambarkan dalam Gambar 5. Alur kerja orkestrasi proses pada order to cash digambarkan dalam Gambar Desain Logical View Desain logical view berisi gambaran komunikasi antara conceptual view dan physical view. Proses bisnis yang didefinisikan di conceptual view dianalisis lebih dalam hingga keluar output bagi developer. Berikut akan dijelaskan desain-desain logica. Business layer, service layer, dan component layer digambarkan dalam sebuah diagram, yaitu mapping of functional domain. Mapping of the functional domain menggambarkan pemetaan domain fungsi menggunakan SOAD dengan membaginya ke dalam bagian-bagian yang lebih detail. Diagram Mapping Functional Domain dapat dilihat pada Gambar 7 Gambar 7 Mapping Functional Domain

5 Pada business service workflow diagram, Procure to Pay didetailkan lagi menjadi business service workflow diagram untuk proses : Approval Automatic Invoicing Purchase Return Approval Automatic Invoicing Sedangkan pada Order to Cash, didetailkan lagi menjadi business service workflow diagram untuk proses : Sales Order Approval Automatic Invoicing Sales Return Approval Automatic Invoicing Diagram pada Gambar 8 menunjukkan desain orkestrasi untuk proses Approval Automatic Invoicing. ui Inventory List pagination Detail ID Date ID Purchase Order ID Date ID Purchase Order Amount Amount Approve Gambar 8 Business Service workflow diagram orkestrasi Approval Automatic Invoicing 2.5 Desain Physical View Desain physical view berisi implementasi dari apa yang sudah didesain di logical view. Physical view berisi rancangan desain pada tingkat programmer yang akan menggambarkan desain arsitektur perangkat lunak. Setelah melakukan analisis single sign on pada multi-tenancy ERP maka diputuskan untuk membuat library service yaitu User Authentication SSO. User Authentication SSO merupakan library service yang dirancang menyediakan layanan untuk dapat mengetahui informasi dari pengguna yang melakukan login / sign in pada sistem. Library Service ini nantinya akan digunakan oleh functional domain lain ketika mengautentikasi pengguna sesuai privilege/ user role nya ketika mengakses protected resource pada suatu aplikasi. Presentation layer berisi desain antar muka sistem yang menggambarkan bentuk halaman maupun form yang nantinya direalisasikan ke dalam tampilan web sebenarnya. Salah satu desain antarmuka untuk proses orkestrasi receiving approval automatic invoicing ditunjukkan pada Gambar 9. Gambar 9 Rancangan antarmuka untuk melakukan orkestrasi receiving approval automatic invoicing Application Service Layer merupakan fungsi-fungsi yang berisi business logic yang diperlukan dalam pengimplementasian aplikasi Orkestrasi Web Service. Method-method dalam application service layer memanggil web service yang terdapat pada web service reference. Web Service Reference merupakan representasi dari web service yang disediakan oleh functional domain penyusun ERP Java Business Integration Layer merupakan proses bisnis yang yang implementasinya menggunakan diagram BPEL. Tabel 1 menunjukkan daftar web service yang akan digunakan dalam orkestrasi untuk proses receiving appproval automatic invoicing Tabel 1 Web Service yang akan digunakan pada proses orkestrasi Approval Automatic Invoicing Domain Inventor y Account Payable Business Process Purchasi ng Account Payable Invoicing Web Service Providing Receivin g AP Service Method Provide Updating Status Provide Data Provide Detail Data Create Purchase Invoice Create Purchase DP Invoice Update Purchase Invoice Status Description Mengupdate status suatu receiving Menyediakan informasi suatu Menyediakan informasi detail barang yang ada pada tiap receiving Membuat Purchase Invoice Membuat Purchase Down Payment Invoice Mengupdate status suatu purchase invoice

6 Domain General Ledger Business Process Manage Journal Web Service Post Journal Method Update Purchase Invoice DP Status Post Automatic Journal Description Mengupdate status suatu Purchase DP Invoice Mengepost suatu transaksi ke journal. 3. Implementasi Tahap implementasi merupakan tahap pengimplementasian hal-hal yang telah didesain pada bab Analisis dan Desain. 3.1 Implementasi Orkestrasi Web Service Implementasi orkestrasi pada tugas akhir ini menggunakan OpenESB v2.3 dan Glassfish v2.1 yang di dalamnya sudah ada BPEL Engine. Ada dua langkah yang harus ditempuh untuk melakukan orkestrasi, yaitu : Membuat BPEL yang merupakan komposisi dari Web Service yang diorkestrasikan. BPEL dibuat menggunakan BPEL editor pada Netbeans 6.91 yang sudah dibundling dengan Open ESB v2.3. Membuat Composite Application yang di dalamnya terdapat hasil BPEL. Composite Application kemudian dideploy pada Glassfish v2.1 yang didalamnya sudah terdapat BPEL Engine. Pembuatan BPEL pada OpenESB membutuhkan web service atau WSDL yang akan dirangkai dalam sebuah proses orkestrasi. Orkestrasi yang diimplementasikan sesuai dengan bab desain Physical View merupakan orchestration of orchestrated yaitu meng-orkestrasi hasil orkestrasi lain. Tabel 3 menunjukkan daftar web service yang digunakan dalam proses orkestrasi receiving approval. Hasil dari orkestrasi Apprvoal ini nantinya digunakan untuk proses Approval Automatic Invoicing. Tabel 2 Web Service yang digunakan dalam proses orkestrasi receiving approval Domain Web Service Operation Inventory ventoryws/providingrecei vingservice?wsdl ProvideUpdatingReceivin gstatus ProvideDTO ProvideDetail Data ventoryws/providingsupp liersservice?wsdl ProvideSupplierDataDTO ventoryws/providingpurc haseorderservice?wsdl ProvidePurchaseOrderDat abyid Sedangkan Tabel 3 menunjukkan WSDL yang digunakan dalam proses orkestrasi receiving approval automatic invoicing. Tabel 3 WSDL yang digunakan dalam orkestrasi receiving approval automatic invoicing Provider Web Service Operation Orkestrasi Approval Orkestrasi Purchase Invoicing Orkestrasi Post Journal nventorycasaservice1/re ceivingapprovalcasaport?wsdl AccountPayableCASASer vice1/invoicingcasaport? wsdl GLPostJournalCASAServi ce1/postjournalcasaport? wsdl ProvideApproval CreatePurchaseInvoiceTran saction PostAutomaticJournalFrom TransactionForOrkes Method-method pada application service layer mengconsume hasil orchestration of orchastrated, Gambar 10 merupakan representasi dari suatu class pada application service layer. BPMN Inventory Receiv ingasl - provideapproval(provideupdatingstatus) : ProvideUpdatingStatusResponse - providedata(string) : List<DTO> + read(string) : List<DTO> + receivingapprovalorchestration(string, int, String) : String + ASL() Gambar 10 Application Service Layer untuk Approval Automatic Invoicing Presentation logic layer merupakan layer dimana hasil dari application service layer akan ditampilkan pada antarmuka. Pada presentation logic terdapat manage bean yang menjembatani antara class pada application service dengan file xhtml. Gambar 11 merupakan representasi dari suatu class manage bean. BPMN Inv entory Receiv ingmanagebean - receivingasl: ASL - selectedreceiving: DTO - userauth: UserAuthenticationSSO + approve() : String + getall() : List<DTO> + getselectedreceiving() : DTO + isapproved() : boolean + ManageBean() + setselectedreceiving(dto) : void Gambar 11 Presentation Logic untuk Approval Automatic Invoicing File xhtml pada presentation layer memanggil manage bean. File xhtml yang dirender pada browser menggunakan library Primefaces dalam mengembangkan

7 user experience yang menarik. Contoh tampilan halaman receiving approval ditunjukkan pada Gambar 12. Gambar 12 Implementasi halaman Orkestrasi Approval Automatic Invoicing 3.2 Implementasi Multi-Tenancy Single Sign On Pada implementasi single sign on menggunakan framework Java Open Single Sign On (JOSSO) sebagai framework untuk mengimplementasikan single sign on pada ERP. Ada beberapa konfigurasi JOSSO agar dapat menerapkan single sign on. Namun yang terpenting ada dua langkah utama yaitu mengkonfigurasi JOSSO Gateway sebagai Central Authenticate Server dan JOSSO Agent sebagai server yang didalamnya terdapat aplikasi yang di single sign on kan. JOSSO Gateway dan JOSSO Agent merupakan server yang terpisah dan memiliki IP masing-masing. Konfigurasi JOSSO Gateway agar authentikasi yang dilakukan berdasarkan database. Database yang digunakan yaitu Oracle 10g, konfigurasinya sebagai pada file josso-gateway-db-stores.xml sebagai berikut : <db-istore:jdbc-store id="josso-identity-store" drivername="oracle.jdbc.driver.oracledriver " connectionurl="jdbc:oracle:thin:@ :1521:orcl" connectionname="sys as SYSDBA" connectionpassword="admin" userquerystring="/*user query string*/ " rolesquerystring=" /*roles query string*/ " credentialsquerystring="/*credentials query string*/" userpropertiesquerystring="/*user properties query string*/" Konfigurasi JOSSO Agent yaitu pada file jossoagent-config.xml dilakukan konfigurasi agar gateway mengarah ke Gateway sever sebagai berikut: <!-- Gateway LOGIN and LOGOUT URLs --> <gatewayloginurl> osso/signon/login.do</gatewayloginurl> <gatewaylogouturl> josso/signon/logout.do</gatewaylogouturl> <!-- Gateway service locator --> <gatewayservicelocator> <!-- Other properties for ws-servicelocator : username, password, serviceswebcontext, transportsecurity--> <protocol:ws-service-locator endpoint=" :8083" /> </gatewayservicelocator> Konfigurasi selanjutnya adalah mendefinisikan partner application yang akan di SSO kan pada JOSSO Agent Server. Pada implementasi kali ini ada dua aplikasi yang di SSO kan yaitu aplikasi HRM dengan contextpath HRM-TestSignOn <configuration> <agent:agent-configuration> <agent:partner-apps> <agent:partner-app id="hrmtest" context="/hrm-testsignon" defaultresource="/index.xhtml"> <ignore-web-resourcecollections>public-resources</ignore-webresource-collections> </agent:partner-app> </agent:partner-apps> </agent:agent-configuration> </configuration> Setelah server dikonfigurasi maka yang perlu dikonfigurasi yaitu aplikasi yang di-multi-tenancy kan. Ada beberapa tahapan konfigurasi yaitu : Konfigurasi Hibernate Config Konfigurasi Hibernate Reverse Engineering Konfigurasi Hibernate Util Konfigurasi Presentation Logic 4. Uji Coba dan Evaluasi Proses pengujian dilakukan berdasarkan alur proses proses bisnis yang berjalan pada masing-masing aplikasi. 4.1 Uji Coba dan Evaluasi Perangkat Lunak Orkestrasi Web Service Proses pengujian dilakukan berdasarkan alur proses proses bisnis orkestrasi web service. Berikut ini dijelaskan orkestrasi web service pada orkestrasi receiving approval automatic invoicing. Uji coba ditunjukkan pada Tabel 4. Tabel 4 Uji coba proses orkestrasi receiving approval automatic invoicing N Kegiatan Reaksi Aplikasi Status o 1 Membuka halaman Approval Aplikasi menampilkan data receiving approval

8 N o Kegiatan Reaksi Aplikasi Status No Kegiatan Reaksi Aplikasi Sta tus 2 Memilih salah satu receiving yang akan diterbitkan invoicenya. Aplikasi menampilkan data receiving sesuai pilihan pengguna 2 Memilih tab Statistics. Aplikasi menampilkan data statistik pengaksesan BPEL pada BPEL-Engine Server. 3 Mengisi informasi yang ada dan menekan tombol Create Invoicing Aplikasi akan melakukan proses orkestrasi dan mengambalikan pengguna ke halaman data receiving approval. Untuk melihat apakah proses orkestrasi berhasil atau tidak menggunakan aplikasi BPEL Monitoring Web Application, seperti ditunjukkan pada Tabel 5 Tabel 5 ujicoba melihat status hasil orkestrasi web service receiving approval automatic invoicing No Kegiatan Reaksi Aplikasi Sta tus 1 Membuka halaman BPEL Monitor Aplikasi menampilkan data BPEL beserta statusnya 4.2 Uji Coba dan Evaluasi Multi-Tenancy Single Sign On Uji coba multi-tenancy single sign-on dilakukan dengan mengakses aplikasi yang sudah di Multi-Tenancy Single Sign On kan, kali ini yang akan diakses yaitu aplikasi HRM yang sudah dikonfigurasi ulang untuk dapat menangani kasus Multi-Tenancy. Untuk uji coba aplikasi, akan diberikan skenario untuk mengetahui beberapa fungsionalitas-fungsionalitas aplikasi pada aplikasi HRM. Uji coba ini dilakukan pada proses-proses bisnis read employee data. Uji coba ini ditunjukkan pada. No Kegiatan Reaksi Aplikasi Status 1 Membuka Aplikasi menampilkan awal HRM halaman awal aplikasi HRM 2 Membuka halaman Login Aplikasi meridirect pengguna ke halaman JOSSO Gateway Application untuk melakukan autentikasi penguna terpusat. Pada URL browser terdapat informasi

9 No Kegiatan Reaksi Aplikasi Status o/signon/login.do?josso_bac k_to= 89/HRM- TestSignOn/josso_security_c heck&josso_partnerapp_id=h rmtest. Informasi itu memiliki arti bahwa pengguna sekarang sedang mengakses URL : o/signon/login.do dan akan dikembalikan ke halaman M-TestSignOn jika autentikasi berhasil No Kegiatan Reaksi Aplikasi Status 4 Melihat seluruh data pegawai Aplikasi menampilkan data pegawai sesuai informasi dari property pengguna. Data yang ditampilkan yaitu data pegawai untuk perusahaan Big ERP Manufacture 5 Melihat informasi salah satu pegawai Aplikasi menampilkan data pegawai sesuai pilihan pengguna 3 Mengisi informasi pengguna dan menekan tombol login. Informasi yang dimasukkan yaitu : User : rina@bigerp. com Password : rina Aplikasi mengarahkan kembali pengguna ke halaman M-TestSignOn Pada saat login pengguna menggunakan User : rina@bigerp.com Password : rina Maka aplikasi akan mendapatkan informasi property pengguna, yaitu : Name : Rina Rahmawati Job Title : HR Staff Branch Code : SBY Company Name : Big ERP Manufacture 6 Melakukan logout Aplikasi mengirimkan informasi pada JOSSO Gateway Application agar menghapus session pengguna. Aplikasi kemudian meridirect pengguna ke halaman awal. 5. Kesimpulan Dari hasil tahap analisis, perancangan, implementasi, dan uji coba, penulis mengambil kesimpulan sebagai berikut : 1. Aplikasi Orkestrasi Web Service telah dapat menangani otomatisasi proses pada Procure to Pay yaitu Approval Automatic Invoicing

10 Post Journal, Purchase Return Approval Automatic Invoicing Post Journal menggunakan BPEL yang kemudian dideploy pada BPEL-Engine 2. Aplikasi Multi-Tenancy Single Sign On mampu menangani autentikasi pengguna secara terpusat serta mampu menangani mekanisme pembatasan hak akses sesuai user-role pengguna. 3. Aplikasi Multi-Tenancy Single Sign On mampu menangani perubahan koneksi ke database sesuai informasi database connection yang didapat dari hasil autentikasi pengguna. 6. Daftar Pustaka [1] Adhyasa, T. (2011). Rancang Bangun Aplikasi Account Payable, Account Receivable dan Fixed Assets dengan Service Oriented Architecture. Surabaya. [2] Airlangga, N. (2011). Rancang Bangun Aplikasi Pelaksanaan Produksi Berorientasi Servis pada Perusahaan Furnitur Menggunakan Platform Java. Surabaya. [3] Albreshne, A., Fuhrer, P., & Pasqueier, J. (2009). Web Service Orchestration and Composition. [4] Chong, F., Carraro, G., & Wolter, R. (2006, June). Multi Tenant Data Architecture. Retrieved April 2011, from MSDN Microsoft: [5] Dickson, C., & Nallannagari, N. (2007). Fast and Free SSO : A Asurvey of Open Source Solutions to Single Sign On. JavaOne Conference. Behr Process Corporation. [6] Eseyin, K. (2006, Jule). Kehinde Eseyin's SAP Library. Retrieved October 16, 2010, from IT Toolbox: [7] Gumilar, I. (2011). Rancang Bangun Aplikasi General Ledger Berorientasi Service pada Platform Java. Surabaya. [8] Hasany, E. G. (2010). Rekayasa Perangkat Lunak Inventory Dan Distribusi Perusahaan Manufaktur Dengan Menggunakan Metode Service Oriented Architecture. [9] Johnson, D. (2010, June). Multi-tenant versus Single-tenant ERP a comparison. Retrieved May 2011, from ERP software at Your Service: [10] Kumar, B., Narayan, P., & Ng, T. (2010). Implementing SOA Using Java EE. Sun Microsystem. [11] Nugroho, B. A., & Putra, R. E. (2011). Model Desain BPEL untuk Komposisi Web Service dalam Open ESB. Prosiding Seminar Nasional Manajemen Teknologi XIII, 753. [12] Nursyamsi. (2009). Implementasi Single Sign On Berbasis Java. Medan: Departemen Teknik Elektro Fakultas Teknik Universitas Sumatera Utara. [13] OMG. (2009). Business Process Model and Notation (BPMN) version 1.2. Object Management Group. [14] Rahmawati, R. (2011). Rancang Bangun Aplikasi Pengelola Sumber Daya Manusia Berorientasi Servis pada Platform Java. Surabaya. [15] Rifai, A. (2011). Rancang Bangun Sistem Persediaan (Inventory) dengan Model Software as a Service Menggunakan Service Oriented Architecture. Surabaya. [16] Safuwan. (2010). Integrasi Perangkat Lunak Enterprise Resource Planning (ERP) menggunakan Metode Service Oriented Architecture. Surabaya: Jurusan Teknik Informatika Fakultas Teknologi Informasi Institut Teknologi Sepuluh Nopember. [17] SAP Order to Cash Flow- SAP SD. (2010). Retrieved October 16, 2010, from EZ SAP.com: [18] Sarno, R., & Herdiyanti, A. (2010). A Service Portfolio for an Enterprise Resource Planning. IJCSNS Journal for Computer Science and Netqork Security. [19] Toxophilist, T. O. (2008, November). The Crooked Stick. Retrieved May 2011, from Oracle Blogs: _tip_simple_web [20] Ventyana, G. (2011). Rancnag Bangun Aplikasi Cash Bank dan Sales dengan Service Oriented Architecture pada Platform Java. Surabaya. [21] White, S. A. (2006). Introduction to BPMN. IBM Software Group