Oracle Fusion Middleware Enterprise Deployment Guide 11g vs 12c

Pada tahun 2013, saya mulai mengaplikasikan Oracle Enterprise Deployment Guide [1][2][3][4] untuk beberapa produk Oracle Fusion Middleware 11g di salah satu perusahaan telekomunikasi di Indonesia dan di salah satu badan pemerintahan DKI Jakarta. Pada saat itu saya berkesempatan mengimplementasikan topologi high availability yang direkomendasikan Oracle untuk kali pertamanya pada produk Oracle SOA Suite, Oracle WebCenter Suite, dan Oracle Access Management. Cukup berat pertama kali mempelajarinya karena jumlah halaman yang mencapai ratusan dan navigasi khas Oracle yang "lompat-lompat", namun kondisi obsessive compulsive disorder (OCD) yang saya miliki membuat saya terus ingin berusaha mempelajari setiap halaman dari guide tersebut dan mencoba untuk mengimplementasikannya dengan benar. Ketika salah satu dokumentasi sudah dipahami, ternyata dokumentasi untuk produk yang lain tidak jauh berbeda polanya sehingga dapat lebih cepat dipahami.

Kurang lebih 3 tahun telah berlalu, dan kali ini saya diberi kesempatan lagi untuk mengimplementasikan high availability architecture pada produk Oracle SOA Suite dan Oracle WebCenter Suite namun kali ini di rilisnya yang terbaru yaitu rilis 12c di salah satu instansi pemerintah yang besar. Kebetulan dokumentasi untuk rilis 12c juga sudah terbit bersamaan dengan jalannya project. Walaupun ada juga seperti WebCenter Portal yang statusnya masih beta dokumentasinya. Tidak seperti 3 tahun  yang lalu, kali ini saya merasa lebih mudah untuk mempelajari dokumentasinya. Saya melihat ada beberapa perkembangan dari sisi teknologi dan konvensi direktori yang digunakan. Berikut ini beberapa perbedaan yang cukup signifikan yang saya amati di antara kedua rilis, yang akan saya coba jelaskan detilnya di paragraf-paragraf selanjutnya:

1. Directory conventions
2. Coherence configuration
3. Web Tier standalone domain
4. Simplified RCU
5. Server groups
6. Virtual IP
7. Per ost NodeManager
8. WSM Policy Manager cluster

Directory Conventions

Baik rilis 11g maupun rilis 12c, Oracle menerapkan pemisahan antara ASERVER_HOME dengan MSERVER_HOME. Namun pada rilis 11g konvensi direktori yang diberlakukan cukup kompleks dan membingungkan terutama untuk implementor yang baru pertama kali mengimplementasikan topologi high availability. Pada 11g lokasi konfigurasi domain untuk AdminServer (ASERVER_HOME) berada di:

 /u01/app/oracle/admin/domain_name/aserver/domain_name

Di sini ada 2 kali pengulangan nama domain yang sangat membingungkan. Sedangkan untuk konfigurasi domain untuk Managed Server (MSERVER_HOME) berada di:

/u02/app/oracle/admin/domain_name/mserver/domain_name

Jika dibandingkan dengan konvensi pada rilis 12c, lokasi direktori menjadi lebih mudah dan singkat, yaitu ASERVER_HOME menjadi:

/u01/oracle/config/domains/domain_name

dan MSERVER_HOME menjadi:

/u02/oracle/config/domains/domain_name 

Selain itu konvensi untuk lokasi lainnya pada rilis 12c secara umum lebih mudah dan lebih logis untuk diimplemementasikan.

Coherence Configuration

Pada rilis 11g, deployment SOA Composite terkadang sangat bergantung pada benar tidaknya konfigurasi Coherence yang perlu dilakukan pada server startup argument menggunakan tangosol.coherence.wka<n>. Argumen tersebut perlu ditambahkan di setiap Managed Server yang termasuk di dalam SOA cluster. Pada rilis 12c, ketika initial domain creation secara otomatis akan terbuat sebuah defaultCoherenceCluster yang akan menangani hal ini. Sehingga tidak diperlukan lagi penambahan argumen Tangosol seperti dulu.

Web Tier Role and Standalone Domain

Pada rilis 11g, saya dulu sempat mempertanyakan sebetulnya fungsi dari Web Tier (Oracle HTTP Server) ini apa selain untuk mengakomodasi Single Sign-On (SSO) solution dari Oracle Access Management. Ternyata di dokumentasi rilis 12c lebih dijelaskan fungsi dasar dari Web Tier ini apa dan bagaimana opsional-nya untuk mendeploy-nya di high availability topology. Menurut saya Web Tier ini tetap diperlukan untuk reverse proxy dan mempermudah deployment ketika nantinya akan diintegrasikan dengan load balancer, karena cukup 1 rule saja yang perlu didaftarkan ke load balancer yaitu ke Web Tier.

Selain itu pada rilis 12c ini, memungkinkan untuk memisahkan deployment dari Web Tier menjadi domain yang terpisah dari WebLogic Domain yang menjadi target reverse proxy. Keuntungan dari pendekatan ini adalah kita dapat menempatkan konfigurasi Web Tier di mesin yang terpisah menjauhi application tier dan bisa digunakan untuk me-reverse proxy lebih dari 1 WebLogic Domain.

Simplified RCU

Repository Creation Utility pada rilis 11g merupakan komponen yang di-download secara terpisah dari installer yang lainnya. Namun pada rilis 12c merupakan kesatuan dari produk yang akan diinstall. Misalnya ketika akan meng-install Oracle SOA Suite, maka RCU-nya yang diperlukan sudah termasuk di dalam folder soa. Pendekatan ini memudahkan komponen yang harus di-download dan juga memudahkan proses instalasi. Selain itu ketika akan membuat skema database, RCU 12c membuat sebuah skema khusus yang berisi metadata RCU, biasanya memiliki sufiks STB. Skema STB ini memiliki peran untuk menyimpan informasi skema-skema lainnya yang memiliki prefiks yang sama. Sehingga ketika proses pembuatan database Middleware tidak perlu lagi sysadmin mengetikkan satu per satu prefiks dan password-nya seperti pada rilis 11g.

Server Groups

Salah satu aspek yang paling kompleks ketika mengkonfigurasi high availability topology adalah pada bagian custom deployment target, misalnya ketika ingin memisahkan WSM pada cluster tersendiri. Pada 12c proses tersebut menjadi dimudahkan dengan adanya fitur Server Groups. Di mana Server Groups ini merupakan deployment set yang dapat di-deploy secara kesatuan dan merepresentasikan sebuah fungsi. Pendekatan ini dapat mengurangi tingkat error yang dilakukan ketika memilih deployment yang akan ditargetkan.

Virtual IP

Virtual IP digunakan untuk mem-failover sebuah proses seperti misalnya proses AdminServer dari node yang aktif ke node yang pasif karena kegagalan node aktif. Selain itu virtual IP pada rilis 11g juga dimanfaatkan untuk proses whole server migration yang bisa dilakukan oleh Oracle SOA server. Sehingga WLS_SOA1 misalnya dapat sepenuhnya pindah ke SOAHOST2, ketika SOAHOST1 gagal. Sehingga pada suatu ketika SOAHOST2 berisi WLS_SOA1 dan WLS_SOA2.

Pada rilis 12c virtual IP yang diperlukan hanya untuk AdminServer, karena Oracle SOA Suite 12c sudah mendukung fitur Automatic Service Migration, di mana yang dipindahkan adalah pada level service-nya. Sehingga migrasi penuh WebLogic Managed Server dari SOAHOST1 ke SOAHOST2 tidak diperlukan.

Per Host Node Manager

Pada rilis 11g, tidak secara detil dijelaskan bagaimana sebenarnya konfigurasi yang benar untuk NodeManager. Penempatan direktori dan perintah yang digunakan juga masih tidak jelas. Hingga akhirnya waktu itu saya mencari-cari cara sendiri untuk mempermudah proses startup dan shutdown dari NodeManager dari berbagai sumber hingga menghasilkan how to versi saya yang saya sempat share di [5].

Pada rilis 12c, walaupun masih belum jelas seperti yang saya harapkan. Namun setidaknya sudah terlihat bahwa ada 2 alternatif konfigurasi yaitu per domain NodeManager atau per host NodeManager. Masing-masing alternatif dijelaskan keuntungan dan kekurangannya, namun masih disarankan untuk membuat per host NodeManager.

WSM Policy Manager Cluster

Sejak rilis 11g saya sudah mempertanyakan alasan sebetulnya kenapa WSM Policy Manager dipisahkan ke 1 cluster khusus, yaitu WSM-PM_Cluster. Saya sempat mempertanyakan juga ke Oracle Support mengenai hal ini, namun jawaban yang mereka berikan tidak memuaskan. Pada rilis 12c dijelaskan secara lebih detil bahwa dengan alasan kinerja secara keseluruhan lebih baik jika WSM Policy Manager dipisahkan deployment-nya ke cluster khusus.


Demikian sedikit ulasan saya mengenai dokumentasi Oracle. Semoga bermanfaat.


Daftar referensi:
[1] Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite
[2] Fusion Middleware Enterprise Deployment Guide for Oracle WebCenter Portal
[3] Fusion Middleware Enterprise Deployment Guide for Oracle WebCenter Content
[4] Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management
[5] Simplified NodeManager Setup

PopUp List Of View in AngularJs

Membuat Popup atau pada angularjs menyebutnya Modal, memang menjadi daya tarik sendiri selain untuk mempercantik pada tampilan tapi juga dapat menyesuaikan kebutuhan, sehingga tidak harus selalu membuka page baru untuk data yang sifatnya tidak terlalu banyak. Blog kali ini akan membahas tentang Popup List Of View, dimana Popup tersebut akan menampilkan list data Provinsi dan data Kab / Kota yang berada di Provinsi tersebut.

Seperti membuat modal pada umumnya, di mulai dari file HTML

di mana kita membuat form input yang di sertai button untuk memanggil fungsi pada controller yang akan menampilkan modal dengan list dari provinsi. Pada form input kab / kota, di bagian ng-click kita juga mengirimkan id dari provinsi supaya ketika kita memilih provinsi tersebut, kita dapat melihat kab / kota yang ada dalam provinsi tersebut.

Lihat kembali HTML, ng-click dari provinsi akan memanggil function cariNama3 dan di kab / kota akan memanggil function cariNama4. Ada sedikit perbedaan dari 2 function tersebut, yaitu pada data yang akan di kirim ke controller modal. Di dalam 2 function tersebut ada yang namanya modalParam. ModalParam fungsi nya untuk menampung data yang di kirim dari file HTML tadi dan akan di kirimkan ke controller modal sebagai parameter untuk mengambil data dari backend.
Bingung ya..??? Begini kira - kira flow nya

Nah saatnya ke controller modal,

di sini parameter id prov yang di kirim dari controller view (function kab / kota ) di kenali sebagai seacrh_idProv dalam function lovKab. 2 Function di atas lah yang bertugas mengambil data dari backend. Berikut penampakan dari modal provinsi dan kab / kota

Selesai sudah membuat modal provinsi dan kab / kota, semoga blog ini bermanfaat dan selamat mencoba dan menerapkan pada kasus - kasus berikutnya. :D

Optimal Memory Partitioning with Linux Explicit Huge Pages

Salah satu tantangan yang saya rasakan ketika membuat sebuah platform virtualisasi adalah bagaimana secara efektif platform tersebut dapat mengalokasikan memori untuk virtual machine secara fleksibel dan handal. Seringkali ketika kita tidak memikirkan hal tersebut, memori yang tersedia di hypervisor tidak selalu sepenuhnya tersedia secara efektif. Ketika memori diperlukan untuk menghidupkan sebuah virtual machine, bisa jadi memori yang tersedia sudah dipegang oleh mekanisme Linux Page Cache atau proses di hypervisor yang lain. Sehingga memori yang bebas digunakan oleh virtual machine sulit untuk diperoleh angka persisnya berapa. Terkadang kita tidak menyadari bahwa sebetulnya memori yang bebas itu sudah menipis sehingga ketika menghidupkan virtual machine tambahan, hypervisor harus melakukan swapping sehingga kinerja keseluruhan menjadi turun.

Hypervisor pun sebetulnya juga membutuhkan resource komputasi yang cukup untuk melakukan aktivitasnya. Sebuah hypervisor berkapasitas 128 GB memori, tentu bukan berarti kita dapat menghidupkan 16 virtual machine berkapasitas 8 GB. Kita harus memikirkan juga untuk menyisakan sebagian memori dari 128 GB tersebut khusus untuk dikonsumsi oleh hyperivisor. Pendekatan yang dilakukan oleh cloud provider besar seperti Google Cloud Platform dan Microsoft Azure, adalah dengan menyediakan paket-paket sizing virtual machine yang sedikit dikurangi kapasitas memorinya dari kapasitas yang umum. 

Skema Sizing Microsoft Azure

Pada skema Microsoft Azure di atas, terlihat bahwa untuk setiap tipe virtual machine yang ditawarkan besar kapasitas memori adalah sedikit di bawah angka standar dari deret eksponensial 2 (1 GB, 2 GB, 4 GB, 8 GB, 16 GB, 32 GB, 64 GB, 128 GB). Semakin besar memori yang akan dialokasikan ke sebuah virtual machine, semakin besar pula selisihnya dengan angka umum.

Skema Sizing Google Cloud Platform

Skema yang serupa ternyata juga terlihat pada skema ukuran virtual machine yang disediakan di Google Cloud Platform. Walaupun tidak seagresif pengalokasian pada Microsoft Azure, Google Cloud Platform juga terlihat menyediakan sebagian memori yang seharusnya dialokasikan mengikuti deret eksponensial 2.

Kedua contoh tersebut dapat diaplikasikan pada cloud provider besar seperti Microsoft Azure dan Google Cloud Platform karena jumlah hypervisor node yang mereka miliki juga sangat banyak. Namun bagaimana pada kasus topologi yang sederhana. Misalnya saja pada server development di Nostratech, bernama Arjuna, yang hanya memiliki kapasitas memori 96 GB. Pengalokasian seperti model tersebut selain cukup menyulitkan dalam perhitungan, dalam jumlah virtual machine yang banyak juga akan sangat banyak memori yang tidak termanfaatkan dengan baik.

Sebagai latar belakang, Arjuna merupakan development platform di Nostratech yang saya rancang dengan menggunakan teknologi Linux KVM sebagai hypervisor dan OpenZFS sebagai storage management layer-nya. Kedua teknologi tersebut bisa dikatakan banyak menggunakan memori sehingga saya merasa cukup tertantang ketika merancang Arjuna. Saya tidak pernah suka dengan swap space, karena menurut saya ketika sudah terjadi swapping proses apapun juga akan menjadi lambat dan tidak efektif lagi. Sehingga saya tidak mengalokasikan swap space sama sekali pada Arjuna. Berikut adalah pembagian memori yang saya lakukan pada Arjuna:

Pada skema tersebut terlihat dengan jelas pembagian 96 GB memori ke masing-masing pemetaannya. Linux Page Cache merupakan mekanisme caching pada Linux dan untuk mengaturnya membutuhkan parameter yang cukup kompleks dan tidak secara eksplisit terlihat berapa penggunakan maksimumnya. Untuk itulah pendekatan yang saya lakukan terbalik. Saya merancang untuk mengalokasikan 8 GB untuk OpenZFS ARC caching, dan 80 GB untuk virtual machine. Sehingga sisa 8 GB dapat secara bebas dimanfaatkan oleh Linux Page Cache. Namun bagaimana saya dapat menjamin saya dapat mengalokasikan 80 GB untuk virtual machine? Di sinilah saya memanfaatkan teknologi explicit huge pages pada Linux.

Linux mengakses memori dalam bentuk satuan kecil yang bernama pages. Besaran asli dari pages adalah sekitar 4 kB. Huge pages [1][2] merupakan terobosan selanjutnya yang memungkinkan besaran dari pages ditingkatkan menjadi 2 MB hingga 1 GB. Sehingga pengalokasian memori dapat lebih efektif karena jumlah call yang diperlukan menjadi lebih sedikit untuk jumlah pengalokasian memori yang sama.

Linux memiliki 2 tipe huge pages, transparent huge pages dan explicit huge pages. Perbedaan dari keduanya adalah pada transparent huge pages kernel Linux sendiri yang melakukan pengaturan proses apa dan menggunakan page size yang mana yang tepat. Sedangkan pada explicit huge pages sejak dari awal boot, kernel sudah melakukan alokasi partisi memori sehingga menjamin keseinambungan dari memori yang dialokasikan. Arjuna menggunakan explicit huge pages, sehingga setiap kali boot Arjuna memiliki pemetaan memori seperti gambar sebelumnya.

Untuk konfigurasi yang perlu dilakukan adalah cukup dengan menambahkan kernel boot parameter berikut ini:

transparent_hugepage=never default_hugepagesz=2M hugepagesz=2M hugepages=40960

Sedangkan untuk melihat berapa sisa kapasitas memori dari partisi explicit huge pages dapat menggunakan perintah berikut ini:

grep Huge /proc/meminfo

Agar Linux KVM dapat memanfaatkan partisi memori huge pages tersebut, perlu disisipkan sedikit konfigurasi pada QEMU command line-nya:

-mem-path /dev/hugepages

Jika menggunakan libvirt XML, maka perlu menambahkan:

<memoryBacking>
<hugepages/>
</memoryBacking>

Selamat mencoba!

[1] https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt

[2] https://wiki.debian.org/Hugepages

Springboot + Java Robot

Pada kesempatan sebelumnya saya pernah membahas mengenai java.awt.Robot di artikel ini.
Dan saat itu saya menganggap bahwa ini library menarik, karena bisa melakukan/menggantikan input dari keyboard dan mouse. 

Pada dasarnya java robot ini memang ditujukan untuk automation seperti yang di jelaskan pada java doc:

This class is used to generate native system input events for the purposes of test automation, self-running demos, and other applications where control of the mouse and keyboard is needed. The primary purpose of Robot is to facilitate automated testing of Java platform implementations.

Untuk input mouse menggunakan java.awt.event.InputEvent yang sudah dibahas pada post sebelum nya. Sedangkan untuk input keyboard menggunakan java.awt.event.KeyEvent. Pada kali ini yg akan kita gunakan adalah input keyboard, berikut contohnya:

 
try {
    Robot robot = new Robot();

    // untuk melakukan aksi menekan tombol enter 
    robot.keyPress(KeyEvent.VK_ENTER);
    // untuk melakukan aksi melepas tombol enter
    robot.keyRelease(KeyEvent.VK_ENTER);

    // untuk melakukan aksi menekan tombol tab 
    robot.keyPress(KeyEvent.VK_TAB);
    // untuk melakukan aksi melepas tombol tab
    robot.keyRelease(KeyEvent.VK_TAB);

} catch (AWTException e) {
    e.printStackTrace();
}
 

Springboot & Headless Mode

Dan ternyata java Robot ini bisa di kombinasikan dengan Springboot. Library ini ternyata bisa digunakan/running dalam springboot yang merupakan sebuah application server dengan menambahkan sedikit code, yaitu konfigurasi system headless. Beberapa library java secara default berasumsi bahwa UI atau Display Monitor dan juga keyboard terpasang. Application server tidak memiliki UI atau Display Monitor yang terpasang, dan ini disebut mode Headless.

Tetapi karena Springboot merupakan sebuah standalone yang bisa juga kita running pada laptop/PC, jadi bisa kita mengeset mode Headless ini menjadi false. Berikut baris code tambahan untuk melakukan setting mode headless :

 
System.setProperty("java.awt.headless", "false");
 

Implementasi

Jadi ide kali ini bertujuan akhir untuk bisa menginput aksi tombol arrow ke kanan dan kiri keyboard.
Sehingga bisa membantu kita saat melakukan presentasi dan berposisi jauh dari laptop.

Untuk spring boot yang digunakan adalah gs-rest-service bisa di dapatkan dari github springboot rest.
Buatlah sebuah API baru seperti berikut:

 
@RequestMapping("/right")
public void right(){
    try {
        System.setProperty("java.awt.headless", "false");

        Robot robot = new Robot();
        robot.keyPress(KeyEvent.VK_RIGHT);
        robot.keyRelease(KeyEvent.VK_RIGHT);
    } catch (AWTException e) {
        e.printStackTrace();
    }
}
 

Setelah kita running springboot tersebut dan mengakses API yang baru saja kita buat, maka laptop/komputer akan mendapatkan aksi tombol arrow ke kanan.

 
http://localhost:8080/right
 

API ini bisa di call melalui perangkat lain yang satu jaringan dengan laptop ini. Misalnya laptop lain yang terkonek pada Access Point/WiFi yang sama, atau perangkat mobile yang bisa mengakses url API tersebut.

Kita tinggal mengemasnya menjadi sebuah aplikasi mobile yang memudahkan pengguna untuk mengakses method-method baru yang kita buat. Dimana di dalam method-method baru itu mungkin berisi logic dari sebuah kombinasi aktivitas keyboard dan mouse yang sudah kita tentukan sendiri.

Integrasi Monit dan Slack

Setelah saya berhasil memantau aplikasi Java menggunakan Monit, saya ingin mencoba mengintegrasikan alert dari monit dengan Slack. Apa itu Slack ?

Slack

Menurut saya Slack merupakan wadah chatting yang kekinian, sedang digandrungi di kalangan IT, karena memiliki fitur integrasi dengan banyak platform. Salah satu contohnya yang ada di blog kali ini. :)

Integrasi Monit dan Slack

Sekilas tentang Monit dan yang sudah saya terapkan bisa dibaca disini.
Langsung saja, berikut langkah-langkah untuk mengintegrasikan Monit dengan Slack :

1. Pastikan sudah memiliki akun di slack.com, bila belum ada buat terlebih dahulu.
2. Login ke xxx.slack.com, xxx -> nama tim anda
3. Buka menu Apps & Integrations

4. Cari Incoming Webhooks, dan tekan Add Configuration

5. Pilih atau buat tujuan channel yang akan menerima pemberitahuan dari Monit, dan tekan Save Settings
6. Kemudian, buat file slack_notifications.sh yang isinya :

#!/bin/sh
/usr/bin/curl \
    -X POST \
    -s \
    --data-urlencode "payload={ \
        \"channel\": \"#channel\", \
        \"username\": \"nama user\", \
        \"pretext\": \"nama app | $MONIT_DATE\", \
        \"color\": \"danger\", \
        \"icon_emoji\": \":ghost:\", \
        \"text\": \"$MONIT_SERVICE - $MONIT_DESCRIPTION\" \
    }" \
    https://hooks.slack.com/services/XXXYYYZZZ/AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHHII

isi https://hooks.slack.com/services/XXXYYYZZZ/AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHHII dengan isian dari Webhook URL.
7. Kemudian ganti event alert dari blog ini dengan exec "/etc/monit/slack_notifications.sh", jangan lupa men-set executable untuk script tersebut.

if cpu > 50% for 5 cycles then exec "/etc/monit/slack_notifications.sh"
if totalmem > 256 MB for 5 cycles then exec "/etc/monit/slack_notifications.sh"
if children > 2 then exec "/etc/monit/slack_notifications.sh"

8. Restart Monit untuk mengaktifkan konfigurasi tersebut

Berikut contoh notifikasi yang diterima pada Slack channel :

Kesimpulan

Dengan adanya integrasi ini, kami bisa lebih cepat mendapatkan informasi keadaan terkini dari server dan dapat segera mengambil tindakan yang diperlukan. Terima kasih dan Semoga bermanfaat! :)

Sumber

• https://www.jverdeyen.be/devops/monit-slack-notifications

Cara Merubah Layout Pada Webcenter Portal

Pada kesempatan ini saya ingin berbagi cara untuk merubah tampilan layout pada suatu page tertentu di webcenter portal.

1. Pertama tama masuk ke menu administer portal yang sudah kalian buat
   
   
   
   
   
   
   
   
2. kemudian pada bagian Edit Portal, kalian pilih page mana yang ingin kalian edit layout nya.
   
   Jika sudah klik edit page pada bagian atas kanan
   
3. Klik change layout
   
4. Pilih layout yang akan kalian gunakan
   
   
   
   
   
5. Save

Layout yang bisa dipakai itu sangat banyak, tidak terbatas dari apa yang sudah di sediakan saja, namun kita jg bisa membuat sendiri layout seperti apa yang ingin kita inginkan.

Selamat mencoba !

Multi upload file dan delete problem

Upload file merupakan salah satu tag html yang sudah ada cukup lama dalam dunia percodingan web. Sedangkan multi upload sendiri merupakan tag yang muncul pada html5. Lalu apa masalah yang Saya alami kali ini? :D

Saya memiliki fitur upload foto dalam jumlah banyak dengan menggunakan angular sebagai otaknya dan memiliki kemampuan menghapus foto yang tidak diinginkan dari list. Cukup mudah di aplikasikan bukan?

Demi mempercepat pengerjaan, Saya menggunakan dasar directive angular dari sini. Tinggal mempersiapkan cara untuk menghapusnya saja. Pada dasarnya directive tersebut akan mengisi $scope.files dengan kumpulan object file yang kita pilih. Saya hanya perlu menghilangkan object yang ingin di hapus dari array $scope.files.

Berikut potongan code yang digunakan untuk menghapus foto dari list :

$scope.deleteFromListUpload = function(dataForDelete){
    var index = $scope.files.indexOf(dataForDelete);    $scope.files.splice(index, 1);};

Sedangkan fungsi deleteFromListUpload akan di panggil dari html :

<table class="table">
     <thead>
        <td width="90%" class="text-center">Nama Foto</td>
        <td width="10%"></td>
     </thead>
     <tr ng-repeat="fotoForUpload in files">
        <td>
           <input type="text" class="form-control" ng-model="fotoForUpload.name" 
             ng-value="fotoForUpload.name">
        </td>
        <td>
          <button type="button" class="btn btn-default" 
            ng-click="deleteFromListUpload(fotoForUpload)">
            <i class="fa fa-times" aria-hidden="true"></i>
          </button>
        </td>
     </tr>
</table>

Berikut tampilan halaman hasilnya :

Multi Upload

Setelah Data Terhapus

Fungsi hapus berhasil berfungsi dengan baik, hanya saja terlihat pada keterangan sebelah button mengenai jumlah file yang di pilih tidak berubah. Hal ini merupakan atribut yang dimiliki oleh tag input type file milik html5. Keterangan akan memberikan data mengenai berapa file yang terakhir dipilih oleh user / nama file yang dipilih apabila hanya 1 file yang dipilih.
Setelah mencari tahu bagaimana cara merubah tulisan tersebut dan hasilnya nihil. Maka saya berpikir bagaimana apabila saya menghilangkan saja tulisan itu agar client tidak merasa terganggu. Sayangnya secara default benda tersebut sudah ada dan tidak ada ditemukan tanda- tanda untuk menghilangkannya. Hingga saya teringat sebuah tag <label for="multiInput">Input</label>.

Yang akan dilakukan adalah : 

1.  Menambahkan label untuk input type file 
2.  Menghide input type

Yap sesimple itu. . .

Berikut adalah potongan code html setelah di beri trik : 

<input name="upload" id="multiFiles" type="file" ng-file-model="files" 
   multiple class="hidden" >
<label class="btn btn-default" for="multiFiles">Pilih Foto</label>

class="hidden" merupakan class milik Bootstrap yang saya gunakan untuk menghide input type. Setelah menambahkan code tersebut, hasilnya menjadi seperti ini :

Dengan demikian sudah tidak terlihat ada keterangan yang tidak mencerminkan data yang sebenarnya. Dan untuk mempercantik Saya menambahkan keterangan tambahan jumlah file yang dipilih dengan memanfaatkan data binding angular seperti berikut :

<input name="upload" id="multiFiles" type="file" ng-file-model="files" 
   multiple class="hidden" >
<label class="btn btn-default" for="multiFiles">Pilih Foto</label> 
File Terpilih : {{ files.length }}

 

Hasilnya jumlah yang tampil akan selalu sesuai dengan jumlah data yang ada..
Demikian adalah trik yang saya lakukan untuk menutupi kinerja keterangan tag yang tidak sesuai keinginan (Saya).
Sekian dulu dari saya kali ini. Semoga dapat membantu bagi yang memiliki perasaan yang sama terhadap fitur tag input tersebut.
Happy Coding~ :D

Tips and Trick Skinning Webcenter Portal

Pada kesempatan ini saya ingin membagikan pengalaman saya ketika mengerjakan Skinning Webcenter Portal 12c. Pada dasarnya ada 2 pedekatan untuk skinning webcenter portal yang saya tau. 

• Pertama menggunakan page template yang sudah disediakan secara default oleh Oracle. 
• Kedua dengan membuat page template sendiri. 

Apa sih yang dimaksud dengan page template? Page template itu bisa di bilang seperti skeleton website yang ada pada umum nya yang biasa ada di index.html. Disini page template yang bisa dibuat bukan hanya mencakup header & footer pada website kebanyakan, namun hingga style keseluruhan webcenter portal itu sendiri.  

Pada awalnya saya mencoba membuat page template sendiri, semula semuanya berjalan mulus, hingga tiba saat bagian integrasi dengan webcenter content, Css page template yang saya gunakan ternyata konflik dengan css bawaan webcenter, yang menyebabkan tampilan komponen yang akan di integrasikan menjadi jelek. Ketika itu saya mempunyai 2 pilihan, yang pertama adalah memodifikasi komponent adf yang akan di integrasikan, atau membuat ulang menggunakan page template bawaan, dan hanya memodifikasi page page tertentu saja sesuai dengan keinginan saya. Akhirnya saya memutuskan untuk mengambil pilihan ke 2. Kenapa saya mengambil opsi ke dua?

Pertama dikarenakan deadline project yang mepet yang menyebabkan saya tidak bisa RND pada bagian komponen bawaan webcenter, yang pastinya akan menghabiskan waktu lama. Kedua, sepertinya lebih mudah untuk memodifikasi page yang sudah kita desain sendiri dibanding memodifikasi apa yang sudah dibuat oleh orang lain. Kira kira itu 2 pertimbangan saya kenapa saya mengambil opsi ke dua.

Untuk membantu teman teman memutuskan pendekatan mana yang akan diambil, saya akan mencoba untuk membuatkan case case sehingga teman teman tidak perlu mengalami apa yang sudah saya alami :)

• Page template bawaan. Sebaiknya teman teman memilih menggunakan ini jika portal yang ingin kalian buat itu banyak integrasinya dengan komponen, seperti webcenter content, bpm workspace, disccussion forum dll. Dikarenakan jika banyak integrasi kalian akan kewalahan untuk memodif template itu ketika komponen yang baru di pasang ternyata tampilan nya sedikit aneh.
• Page template custom. Sebaiknya teman teman memilih menggunakan ini jika portal yang ingin kalian buat itu tidak banyak integrasi aplikasi, sebab tampilan nya bisa dibilang akan jauh lebih bagus dibanding dengan template bawaan.

Sekian share dari saya, semoga ini membantu !

Mengapa React ?

Baru beberapa bulan ini saya belajar React so saya bukan expert :D. Dan pada blog ini saya akan membahas kenapa sih harus pake React & hal apa saja yang perlu Anda ketahui jika Anda ingin menggunakan React.

Apa itu React ?

• Sederhana, React itu Library untuk bikin User Interface. React ga punya Model dan Controller hanya View
• Component Based

Kenapa pake React ?

• Karena Virtual DOM. Jadi sebelum render ke actual DOM, react melakukan proses rendering di Virtual DOM dan hanya mengubah/update  component yang mengalami perubahan sehingga lebih effisien dan meningkatkan performance. Karena pada saat me-render DOM dibutuhkan kalkulasi CSS & bind action dan ini memakan waktu. Tapi ini akan bekerja dengan baik apabila kita meng-implementasikan dengan benar (baca: https://facebook.github.io/react/docs/thinking-in-react.html)
• Isomorphic, yaa react bisa jalan di server & client side denga code yang sama. Jadi aplikasi bisa jalan secara server side rendering.
  
• Lean Once, Write Anywhere: React Native

Hal - hal apa yang seharusnya anda ketahui sebelum belajar React ?

• ECMAScript 6, javascript rasa java :D. Berikut contoh jika menggunakan ES6.
  

• Babel adalah ECMAScript 6 ke ECMAScript 5 compiler. Memungkinkan fitur -  fitur ES6 dalam development lalu di-compule ke ES5 untuk penggunan production. 
• Flux atau Redux Architecture, yaa React hanya UI library jadi kalian membutuh arsitektur untuk komunikasi setiap component.
• Gulp sebagai javascript task runner.
• Bundling and minifying libraries and stylesheets.
• Refreshing your browser when you save a file.
• Quickly running unit tests
• Running code analysis
• Less/Sass to CSS compilation
• Copying modified files to an output directory
• Selain Gulp kalian bisa menggunakan Webpack untuk fungsionaliti yang lebih advanced.

Kesimpulan:

• React itu Javascript centric, cocok bagi yang mau belajar javascript :D
• Karena dia component based & menaruh html ke dalam javascript menjadi tantangan sendiri untuk mendesign aplikasi kita :D
• Reactive Programming :)

Jika kalian ingin belajar react kalian bisa cari starter kit di http://andrewhfarmer.com/starter-project/ atau react-es6-skeleton-reflux

Sumber:

https://camjackson.net/post/9-things-every-reactjs-beginner-should-know

https://toddmotto.com/react-create-class-versus-component/

Firebase Auth bersama React - Reflux

Halo, pada kali saya akan membahas tenang firebase authentication untuk website dan kita akan integrasikan ke ReactJS dengan Reflux sebagai Functional Programming Architecture adaptasi dari Flux.

Authentication adalah bagian penting dari setiap aplikasi SaaS, dan melakukan otentikasi pada Single App Page menambahkan beberapa kompleksitas tersendiri. Di sini saya akan membahas bagaiman aplikasi bisa terintegrasi dengan firebase Authentication, berikut gambaran umum alur authentication-nya:

ReactComponents

• Setiap component akan listen AuthStore jika membutuhkan akses API yang membutuhkan otorisasi. Ini diperlukan karena fireabase Auth berjalan secara Async untuk menghindari getToken() === null.
  

AuthActions

• AuthActions list of Actions cara kerjanya sesuai standard Reflux-Actions

AuthStores

• AuthStore berfungsi untuk berkomunikasi ke Firebase SDK. 
  
  
  

Kesimpulan

1. Dengan pendekatan ini aplikasi kita jadi mudah di maintain dan lebih agile jika ada perubahan UI. Dan tidak perlu implementasi Firebase.Auth disetiap React komponen. Ingat React itu Library for Building User Interface bukan untuk maintain state auth :D (baca: https://en.wikipedia.org/wiki/Single_responsibility_principle)  
2. Mostly Firebase SDK berjalan secara async ini menjadi sulit di maintain dan diprediksi dengan React Lifecycle. Jadi dibutuhkan data flow seperti ini :D
3. Apakah Reflux Architecture terbaik untuk React & Firebase ? Menurut saya tidak, saya tetap mengalami kesulitan dalam maintain state aplikasi. please use Redux for better apps & performance.

Lesson Learn #2 : menjadi software engineer

Disclaimer : ini adalah pendapat pribadi penulis, penulis bukan expert engineer, masih junior dan butuh banyak masukan *pray*

Permasalahan

• Engineer yang baru bergabung dengan tim, meski sangat pintar, namun kadang tidak bisa mengimbangi tim nya. Hal ini bukan melulu hal yang buruk, permasalahan-permasalahan yang terjadi misalnya
• Tempat yang baru cukup santai, namun bertanggung jawab, dimana bisa work from home (WFH) kapan saja asal deliver. Si anak baru belum terbiasa dengan hal ini, karena mungkin butuh diskusi langsung, pair programming untuk bisa familiar dengan codebase yang ada.
• Tempat yang baru sangat fleksibel dan realistis dengan apa yang harus di achieve di tiap sprint, si anak terlalu pintar dan memikirkan semua hal, sehingga achivement nya hanya setengah dari apa yang ada.
• Tempat yang baru tidak peduli dengan anak baru atau anak lama, ketika ada yang masuk silahkan tenggelam atau berenang (dengan inisiatif sendiri).

Uraian di atas merupakan sedikit dari banyak permasalahan-permasalahan yang terjadi dalam dunia software engineering. Kali ini saya akan membahas dari satu sisi, yaitu sudut pandang engineer baru.

Saya belum lama-lama banget berkecimpung di dunia software engineering, namun pernah bekerja di beberapa perusahaan dengan latar belakang yang berbeda membuat saya banyak mengambil hikmah, dan membuat saya bersyukur dipertemukan dengan orang-orang hebat di masing-masing perusahaan tersebut sampai dengan saya yang sekarang. *maaf jadi melow :(

Attitude, habit, and culture come first before code quality

Attitude

Why? Menurut saya ini tidak hanya tentang menjadi seorang engineer, namun menjadi seorang manusia.

Di atas langit masih ada langit, apa yang kita tanam pasti akan kita tuai nanti (malah jd berpepatah ria :D). Sebagai seorang manusia, apalagi engineer di dunia IT yang perkembangan nya nggak akan ada habisnya jelas, pepatan diatas langit masih ada langit, pas banget buat saya, yang serba pas-pas an dan cupu untuk masalah teknologi yang kekinian.

Hubungan nya dengan attitude jelas, yang pertama kita harus bisa menerima feedback apa pun, ketika mereka memberikan kritik, marah, apapun, itu berarti masih ada kepedulian terhadap kita. They want us to run together with them, so they give us feedback and we can run faster with them.

Yang ke dua, do as best as I can (ada hubungan nya sama pepatah apa yang kita tanam, pasti akan kita tuai nanti :D). YOLO lah alias you only live once, jangan sampe menyesal karena kita nggak berusaha semaksimal mungkin sampe titik darah penghabisan. Sebagai engineer, ketika malas sudah merajai (ibarat nya googling aja males) please just leave. Kasar nya, perusahaan sudah membayar untuk bekerja 8 jam sehari, jika tiap hari cuma ngeluh, males-males an, facebookan, youtube an, nge-game, banyak alasan, ke laut aja dah.

Kenapa saya bilang ke laut aja, karena di perusahaan manapun dengan metal produktifitas yang rendah, pasti tidak akan bertahan lama juga (kecuali di perusahaan-perusahaan yang habit nya memang demikian).

Mental ini, jelas akan menghambat tim, sebagai seorang engineer, ekspektasi nya adalah dia bisa menyelesaikan masalah yang ada, namun jika berusaha saja dia tidak mau :( bisa jadi blocker buat tim, masih berjalan ketika tim sudah berlari.

Saran saya jika memang menemukan sebuah permasalahan yang pelik, jangan langsung bertanya ini bagaimana solved nya? (karena jelas yang ditanya juga belum tentu tahu jawaban nya, sesama engineer :|) namun dicari dulu, dicoba, kalau memang sudah dicoba dan masih tidak bisa, baru di diskusikan, ya DISKUSI, bukan minta jawaban :)

Sebenernya attitude ini luas banget, namun ini menurut saya paling penting jelas selain menjunjung kode etik engineer :)

Habit

Saya menyadari ini penting waktu menghadiri workshop ThoughtWorks di Binus beberapa tahun lalu, disitu mereka menceritakan how they work, menjadi lebih baik, menemukan proses bekerja yang lebih efektif adalah keseharian mereka.

Disitu juga saya pertama kali memahami tentang agile dan scrum. Implementasi agile di setiap tempat mungkin berbeda-beda, disini saya akan menceritakan pengalaman saya dengan tim saya yang sekarang.

Baru 3 bulan terakhir (semenjak 1 tahun tim dibentuk) kami menemukan ritme kerja yang lebih baik dan lebih produktif (meski belum sempurna dan masih banyak kekurangan sana sini). Dan ketika kami melakukan obrolan kecil (yang mungkin bisa dibilang evaluasi) ada beberapa hal mengapa hal ini bisa kami capai. Mungkin beberapa hal yang akan saya jelaskan di bawah ini sudah biasa dilakukan :D, namun ini hal baru bagi tim kami hehehe ^^v

Kami selalu melakukan diskusi di awal sprint apa yang akan akan kami lakukan setelah sprint planning. Diskusi teknikal dan pembagian task untuk masing-masing. Disini kami sudah tahu apa yang akan harus dilakukan, jika masih belum jelas, maka diskusi akan terus berlanjut :D atau kami break untuk memikirkan nya, dan membahas nya kembali esok hari (ini lebih sering sik hahhahaa)

Dalam proses development, kesulitan pasti ada, karena kita berhubungan dengan teknologi yang baru, namun kita tahu porsi masing-masing, dan kami ada di level yang sama (semuanya juga masih belajar :D) google, try, and discuss :)

Pull request, karena engineer juga tidak luput dari khilaf, bisa belajar dari code engineer lain, dan mendapat feedback yang membangun. Secara pribadi saya merasakan manfaatnya, bisa mempercepat learning curve, ketika ada code yang salah atau tidak efektif, maka engineer lain akan mengomentari dan memberikan feedback, saya akan bertanya kenapa dan akan berlanjut dengan diskusi, ilmu baru dari hanya sebaris code :)

Tim kami belum mempunyai QA, namun masing-masing dari kami tahu bahwa test itu penting, penting banget. Kami sadar akan hal tersebut dan memastikan code yang kami deploy sudah well tested. Plus, kami melakukan regression bersama-sama sebelum naik production, meski belum sempat melakukan test-test yang lain T_T

Meski kadang kami melakukan WFH, namun kami punya pengertian yang sama bahwa WFH means work from home, yang artinya selama jam kerja harus bisa dihubungi via slack atau apapun, dan tidak boleh menjadikan blocker buat tim.

Kesimpulan nya adalah menurut saya agile itu habit, kebiasaan, lebih bagaimana kita bekerja, dan berubah menjadi lebih baik setiap harinya. Bagaimana kita tahu apa tanggung jawab kita, dan apa yang harus dilakukan, untuk menjadi lebih baik untuk tim dan pribadi :)

Tanpa scrum master pun kita bisa :D

Engineering culture

Engineering culture disini ada hubungan nya dengan poin-poin yang sudah saya sebutkan di atas, attitude dan habit. Pull request and pair programming is a must. Pull request selain bisa meng-improve code kita, juga membiasakan dengan habit git flow, bahwa ketika bekerja dengan banyak engineer harus memikirkan engineer yang lain, jangan sampai code yang kita push menjadi blocker dan mengganggu engineer yang lain. Pair programming bisa sangat membantu engineer yang baru bergabung untuk mempercepat familiar dengan codebase yang ada.

Saya termasuk orang yang tidak mendukung lembur (saya pernah lembur btw). Beberapa engineer mungkin bependapat bahwa kalau nggak lembur nggak asik, bekerja di hari libur adalah hal biasa. Buat saya ketika kita harus lembur, it means there’s something wrong. Entah dengan estimasi yang salah, atau engineer nya tidah bekerja dengan produktif di waktu yang dijadwalkan, atau ada hal-hal yang lupa dikomunikasikan dan baru diketahui pada proses development.

Lembur membuat engineer kelelahan yang tidak wajar bahkan burn out, di situasi yang seperti ini, engineer bekerja dengan kurang maksimal. Jadi daripada lembur, kita harus mekakukan estimasi dengan baik, dan mengkomunikasikan segala permasalahan di awal sprint, dan tentu saja bekerja dengan produktif.

Salah satu keuntungan sprint yang pendek adalah kita bisa melakukan iterasi dengan cepat, meng evaluasi nya, dan menentukan apa yang harus dilakukan selanjutnya dengan melihat evaluasi sprint sebelum nya.

Point penting yang perlu saya garis bawahi adalah, diskusi teknikal setelah sprint planning, pull request, pair programming, dan bekerja produktif :)

Code quality is a must

Sebagai engineer jelas code quality is a must. Visi nya adalah bahwa kita menulis code bukan untuk mesin, namun untuk engineer lain (yang mungkin akan melanjutkan code kita) *kata-kata ini adalah kutipan, namun saya lupa darimana :|

sumber

Kesimpulan

Dari permasalahan-permasalahan diatas dapat disimpulkan bahwa sebagai engineer baru

• Harus explore sendiri ketika memang tidak ada support, tidak sungkan bertanya, meminta waktu untuk diskusi, karena tim adalah yang nomor satu :)
• Idealist itu penting namun realistis itu harus, solusinya saat sprint planning harus di sampaikan ideliasme nya, sehingga apa yang di achieve memang itulah yang diharapkan.
• engineer come to solved problems, so don’t make any other problems :)

Thank you :)
#ilearnnewthingseveryday

Buku yang harus dibaca ^^v :

Clean Code Book

The Effective Engineer Book

Configuring Actionable Human Workflow Notification In Oracle SOA Suite 12.2.1.1.0

Pada kesempatan kali ini saya akan menjelaskan cara agar bisa melakukan action (approve/reject) melalui email menggunakan jdeveloper. Namun ada beberapa hal yang perlu diperhatikan, yaitu sebagai berikut :

1. Pastikan service messaging pada Enterprise Manager sudah dapat digunakan untuk send notification. (Testing Send Notification). Jika masih gagal bisa mengikuti langkah dibawah.
2. Actionable notification hanya dapat digunakan pada jdev version 11.1.1.5.0 ke atas.

Langkah - langkah untuk konfigurasi email notifikasi pada Oracle Enterprise Manager 12c, sebagai berikut :
1. Setelah login EM akan masuk ke halaman Home.

2. Pilih Target Navigation seperti gambar dibawah ini yang iconnya berada pada sebelah kiri atas.
    Pilih User Messaging Service ==> usermessagingdriver-email.

3. Pilih panah bawah seperti tampilan dibawah ini. Pilih Email Driver Properties.

4. Akan muncul tampilan seperti dibawah ini. Klik Create

5. Isi sebagai berikut :

     Name : nama kofigurasi

Driver-Specific Configuration 

E-mail Receiving Protocol  : tipe protokol (POP3/IMAP)

Outgoing Mail Server : hostname/ipaddress outgoing mailserver

Outgoing Mail Server Port : port outgoing mailserver

Default From Address : default email pengirim outgoing

Outgoing Username : username outgoing

Outgoing Password : password username outgoing

Incoming Mail Server : hostname/ipaddress incoming mailserver

Incoming Mail Server Port : port incoming mailserver

Incoming Mail IDs : default email untuk incoming

Incoming User IDs : username incoming

Incoming Passwords : password dari user id incoming

6. Klik Save

7. Ke soa > soa-infra(soa_server1), klik kanan  SOA Administration > workflow properties.

8. Pilih Notification Mode = Email. Isi from address, actionable address dan reply to address.
    Klik Apply.

Untuk actionable (approve/reject) melalui email dapat mengikuti langkah dibawah ini :
1. Buka Jdeveloper, yang saya gunakan saat ini adalah Jdeveloper 12.2.1.1.0.
2. Pilih Human Task yang akan diaktifkan fitur ini

3. Pilih Notification. Akan ada 3 Task status default.
    - Assign : notifikasi ketika proses dimulai (berisi notifikasi untuk melakukan approve/reject suatu   proses).
   - Complete : notifikasi akan dikirim jika proses tersebut selesai dilakukan
   - Error : notifikasi akan dikirim jika ada suatu proses yang gagal

4. Pilih tab Advanced seperti gambar dibawah ini. Pada point ini adalah yang paling penting.
    Kalian dapat melakukan checklist untuk :
 
    Make notification actionable : untuk approve / reject melalui email notifikasi
    Send task attachments with email notification : untuk mengirim attachment pada notifikasi

Sekian dari saya semoga bermanfaat. :)