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

Rancang Bangun Orkestrasi Web Service serta Implementasi Single Sign On pada Enterprise Resource Planning 1,2,3

Riyanarto Sarno1, Ahmad Dzulfikar Adi Putra2, Dwi Sunaryono3 Jurusan Teknik Informatika, Fakultas Teknologi Informasi, Institut Teknologi Sepuluh Nopember Kampus ITS Sukolilo Surabaya, 60111, Indonesia 1 [email protected], [email protected], [email protected]

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

(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 (Receiving 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)

2.1.2 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.

2.2 Arsitektur Perangkat Lunak

2.2.2 Arsitektur Multi-Tenancy Single Sign On

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 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.

2.2.1 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.

Gateway Server Authentication Scheme Agent Server

JOSSO Gateway (Identity Provider)

Assert identity (SOAP)

JOSSO Agent

Create Security Context IDENTITY

CREDENTIAL

SESSION

STORE

STORE

STORE

Security Infrastructure Access Persistence Delegate Authentication Request

Persistence

DATABASE MYSQL / ORACLE / JAVA DB

Partner Application X

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] 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.

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

Force. Sedangkan pada aplikasi multi-tenancy single sign on untuk ujicobanya ada satuaktor yaitu HR Staff. uc Stakeholder diagram

Accountable

W arehouse Staff

Responsible

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 6.

2.4 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

Pada business service workflow diagram, Procure to Pay didetailkan lagi menjadi business service workflow diagram untuk proses : • Receiving Approval Automatic Invoicing • Purchase Return Approval Automatic Invoicing

ui Inv entory Receiv ing List

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 Receiving Approval Automatic Invoicing.

pagination

Receiv ing Detail ID Receiving

ID Receiving

Date Receiving

Date Receivi ng

ID Purchase Order

ID Purchase Order

Receiving Amount

Recei ving Amount Approve

Gambar 9 Rancangan antarmuka untuk melakukan orkestrasi receiving approval automatic invoicing

Gambar 8 Business Service workflow diagram orkestrasi Receiving 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.

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 Receiving Approval Automatic Invoicing Domain Inventor y

Account Payable

Business Process Purchasi ng

Account Payable Invoicing

Web Service Providing Receivin g

AP Service

Method

Description

Provide Updating Receiving Status Provide Receiving Data Provide Receiving Detail Data

Mengupdate status suatu receiving

Create Purchase Invoice Create Purchase DP Invoice Update Purchase Invoice Status

Menyediakan informasi suatu Receiving Menyediakan informasi detail barang yang ada pada tiap receiving Membuat Purchase Invoice Membuat Purchase Down Payment Invoice Mengupdate status suatu purchase invoice

Domain

Business Process

Web Service

Tabel 3 WSDL yang digunakan dalam orkestrasi receiving approval automatic invoicing

Method

Description

Update Purchase Invoice DP Status Post Automatic Journal

Mengupdate status suatu Purchase DP Invoice Mengepost suatu transaksi ke journal

Provider Orkestrasi Receiving Approval

Tahap implementasi merupakan tahap pengimplementasian hal-hal yang telah didesain pada bab Analisis dan Desain.

Orkestrasi Post Journal

General Ledger

Manage Journal

Post Journal

.

3. Implementasi

Orkestrasi Purchase Invoicing

Web Service http://10.151.31.56:9080/I nventoryCASAService1/re ceivingApprovalCasaPort ?wsdl http://10.151.31.56:9080/ AccountPayableCASASer vice1/invoicingCasaPort? wsdl http://10.151.31.56:9080/ GLPostJournalCASAServi ce1/postJournalCasaPort? wsdl

Operation ProvideReceivingApproval

CreatePurchaseInvoiceTran saction

PostAutomaticJournalFrom TransactionForOrkes

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 Receiving Apprvoal ini nantinya digunakan untuk proses Receiving Approval Automatic Invoicing. Tabel 2 Web Service yang digunakan dalam proses orkestrasi receiving approval Domain Inventory

Web Service http://10.151.31.3:1234/In ventoryWS/ProvidingRecei vingService?WSDL

http://10.151.31.3:1234/In ventoryWS/ProvidingSupp liersService?WSDL http://10.151.31.3:1234/In ventoryWS/ProvidingPurc haseOrderService?wsdl

Operation ProvideUpdatingReceivin gStatus ProvideReceivingDTO ProvideReceivingDetail Data ProvideSupplierDataDTO

ProvidePurchaseOrderDat aById

Sedangkan Tabel 3 menunjukkan WSDL yang digunakan dalam proses orkestrasi receiving approval automatic invoicing.

Method-method pada application service layer mengconsume hasil orchestration of orchastrated, Gambar 10 merupakan representasi dari suatu class pada application service layer. BPMN Inv entory

Receiv ingASL + + +

provideReceivingApproval(ProvideUpdatingReceivingStatus) : ProvideUpdatingReceivingStatusResponse provideReceivingData(String) : List readReceiving(String) : List receivingApprovalOrchestration(String, int, String) : String ReceivingASL()

Gambar 10 Application Service Layer untuk Receiving 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: ReceivingASL selectedreceiving: ReceivingDTO userauth: UserAuthenticationSSO

+ + + + + +

approveReceiving() : String getAllReceiving() : List getSelectedreceiving() : ReceivingDTO isApproved() : boolean ReceivingManageBean() setSelectedreceiving(ReceivingDTO) : void

Gambar 11 Presentation Logic untuk Receiving Approval Automatic Invoicing

File xhtml pada presentation layer memanggil manage bean. File xhtml yang dirender pada browser menggunakan library Primefaces dalam mengembangkan

user experience yang menarik. Contoh tampilan halaman receiving approval ditunjukkan pada Gambar 12.

<protocol:ws-service-locator endpoint="10.151.31.56:8083" />

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”

Gambar 12 Implementasi halaman Orkestrasi Receiving 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 :
Konfigurasi JOSSO Agent yaitu pada file jossoagent-config.xml dilakukan konfigurasi agar gateway mengarah ke Gateway sever sebagai berikut: http://10.151.31.56:8083/j osso/signon/login.do http://10.151.31.56:8083/ josso/signon/logout.do

public-resources

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 o 1

Kegiatan

Reaksi Aplikasi

Status

Membuka halaman Receiving Approval

Aplikasi menampilkan data receiving approval

OK

N o

Kegiatan

Reaksi Aplikasi

Status

2

Memilih salah satu receiving yang akan diterbitkan invoicenya.

Aplikasi menampilkan data receiving sesuai pilihan pengguna

OK

3

Mengisi informasi yang ada dan menekan tombol “Create Invoicing”

Aplikasi akan melakukan proses orkestrasi dan mengambalikan pengguna ke halaman data receiving approval.

No

Kegiatan

Reaksi Aplikasi

Sta tus

2

Memilih tab Statistics.

Aplikasi menampilkan data statistik pengaksesan BPEL pada BPEL-Engine Server.

OK

OK

4.2 Uji Coba dan Evaluasi Multi-Tenancy Single Sign On

Untuk melihat apakah proses orkestrasi berhasil atau tidak menggunakan aplikasi BPEL Monitoring Web Application, seperti ditunjukkan pada Tabel 5

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 1

Kegiatan Membuka awal HRM

Reaksi Aplikasi Aplikasi menampilkan halaman awal aplikasi HRM

Status OK

2

Membuka halaman Login

Aplikasi meridirect pengguna ke halaman JOSSO Gateway Application untuk melakukan autentikasi penguna terpusat. Pada URL browser terdapat informasi

OK

Tabel 5 ujicoba melihat status hasil orkestrasi web service receiving approval automatic invoicing No

Kegiatan

Reaksi Aplikasi

1

Membuka halaman BPEL Monitor

Aplikasi menampilkan data BPEL beserta statusnya

Sta tus OK

No

3

Kegiatan

Mengisi informasi pengguna dan menekan tombol login. Informasi yang dimasukkan yaitu : User : rina@bigerp. com Password : rina

Reaksi Aplikasi http://10.151.31.56:8083/joss o/signon/login.do?josso_bac k_to=http://10.151.31.56:80 89/HRMTestSignOn/josso_security_c heck&josso_partnerapp_id=h rmtest. Informasi itu memiliki arti bahwa pengguna sekarang sedang mengakses URL : http://10.151.31.56:8083/joss o/signon/login.do dan akan dikembalikan ke halaman http://10.151.31.56:8089/HR M-TestSignOn jika autentikasi berhasil

Aplikasi mengarahkan kembali pengguna ke halaman http://10.151.31.56:8089/HR M-TestSignOn Pada saat login pengguna menggunakan User : [email protected] 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

Status

No 4

Kegiatan Melihat seluruh data pegawai

Reaksi Aplikasi Aplikasi menampilkan data pegawai sesuai informasi dari property pengguna. Data yang ditampilkan yaitu data pegawai untuk perusahaan Big ERP Manufacture

Status OK

5

Melihat informasi salah satu pegawai

Aplikasi menampilkan data pegawai sesuai pilihan pengguna

OK

6

Melakukan logout

Aplikasi mengirimkan informasi pada JOSSO Gateway Application agar menghapus session pengguna. Aplikasi kemudian meridirect pengguna ke halaman awal.

OK

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 Receiving Approval Automatic Invoicing

2.

3.

Post Journal, Purchase Return Approval Automatic Invoicing Post Journal menggunakan BPEL yang kemudian dideploy pada BPEL-Engine Aplikasi Multi-Tenancy Single Sign On mampu menangani autentikasi pengguna secara terpusat serta mampu menangani mekanisme pembatasan hak akses sesuai user-role pengguna. 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: http://msdn.microsoft.com/enus/library/aa479086.aspx [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: http://it.toolbox.com/blogs/saplibrary/the-procure-to-pay-cycle-10574 [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: http://erpcloudnews.com/2010/06/multi-tenantversus-single-tenant-erp-a-comparison/ [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: http://ezsap.com/sap-order-to-cash-flow-sapsd.html [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: http://blogs.oracle.com/toxophily/entry/open_esb _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