Příprava demo JavaBatch ve WebSphere Application Server 8.5.5

Demo aplikace XDCGIVT 

Na stránkách IBM je ke stažení připravena jednoduchá JavaBatch aplikace, která umožní ověřit nastavení JavaBatch - Job Scheduler ve WebSphere Application Server:

IVT Java Application

https://www.ibm.com/support/knowledgecenter/en/SSAW57_8.5.5/com.ibm.websphere.samples.doc/ae/sample_mb_ivt.html

Prvotní nastavení Job Scheduler

Prvotní nastavení Job Scheduleru není složité, ale některé kroky nejsou úplně intutivní a je potřeba věnovat v určitých chvílích větší pozornost při nastavování.

Základní nastavení se provádí z IBM Console v menu System Administration / Job Scheduler

Na následujícím obrázku je příklad nastavení funkčního Job Scheduleru:

Pokud při prvním nastavení ponecháte Data source JNDI Schema na None, měla by se podle dokumentace připravit Derby databáze a připravit datový zdroj jdbc/rlsched. To se v mém případě bohužel nestalo, tak přikládám návod na případu databáze a nastavení jdbc.

Skripty pro vytvoření databáze scheduleru jsou v adresáři /opt/IBM/WebSphere/AppServer/util/Batch

Při použití databáze Derby použijte následující příkaz:

cd /opt/IBM/WebSphere/AppServer/derby/databases

/opt/IBM/WebSphere/AppServer/java/bin/java -Djava.ext.dirs=/opt/IBM/WebSphere/AppServer/derby/lib -Dij.protocol=jdbc:derby: org.apache.derby.tools.ij /opt/IBM/WebSphere/AppServer/util/Batch/CreateLRSCHEDTablesDerby.ddl

Tento příkaz provede vytvoření nové databáze RLSCHED a nastavíte na něj datový zdroj.

Provider: Derby XA
Name: rlsched
JNDI Name: jdbc/rlsched
Database name: /opt/IBM/WebSphere/AppServer/derby/databases/RLSCHED

Instalace Java Batch sample aplikace 

Ve staženém zip souboru sample aplikace je instalační balíček XDCGIVT.ear . Tuto aplikaci nainstalujte  do aplikačního serveru.

Po instalaci restartujte aplikační server.

Mapování uživatelů

V nastavení job scheduleru vyberte Security Role to User/Group Mapping.

A nastavte role odpovídajícím uživatelům. Jedná se o role, které jsou přiděleny uživateli JavaBatch administrativní aplikace jmc, bude o ní řeč níže. Já jsem pro první otestování dal roli všem přihlášeným.

Upozornění: Pro správnou funkci jmc aplikace musí být zapnuté aplikační zabezpečení. Zkontrolujtem, zda je nastaveno:

Proveďte restart aplikační serveru.

Administrační konzole Java Batch (aplikace jmc)

Pokud nastavení proběhlo v pořádku, bude na aplikačním serveru přístupná aplikace jmc:

https://localhost:9443/jmc

Příprava sample databáze

Připravte si testovací databázi příkazem:

./java -Djava.ext.dirs=/opt/IBM/WebSphere/AppServer/derby/lib -Dij.protocol=jdbc:derby: org.apache.derby.tools.ij /<adresar rozbalenho zip>/sample_ivt/sample_ivt/IVT/scripts/CreateIVTTablesDerby.ddl

Nastavte Derby XA datový zdroj. 

Provider: Derby JDBC Provider (XA)  

Name:IVTdbxa

JNDI Nane: jdbc/IVTdbxa

Database Name: /opt/IBM/WebSphere/AppServer/derby/databases/IVTDB

Ostatní ponechte default.

Spuštění sample jobu

V souboru XDCGIVTtxt2txtxJCL.xml upravte správně cesty na existující adresář:

<prop name="inputDataStream" value="/temp/input-text.txt" />
<prop name="outputDataStream" value="/temp/output-text.txt" />

Vlastní txt soubory není potřeba vytvářet, Vyrobí je až spuštěný jop.

V administrativní aplikaci jmc zadejte volbu Submit Job a vyberte soubor XDCGIVTtxt2txtxJCL.xml:

Po spuštění jobu tlačítkem Submit byste měli vidět informaci o úspěšném spuštění jobu. Nebo také chybové hlášení a pak je potřeba v SystemOut.log serveru zjistit příčinu chyby.

Seznam proběhnutých jobů lze zobrazit volbou View Jobs:

Pokud jste se dostali až sem, gratuluji ke správnému nastavení Java Batch ve WebSphere Application Server na standalone serveru. Dalším stupňem je nastavení Java Batch v Network Deployment a použití paralel batch.

Federované repository a autenizace administrátora při nedostupném LDAP ve WebSphere Application Server

Federované repository ve WAS umožňuje kombinovat více repository uživatelů. V základním nastavení ale WAS provede přihlášení pouze v případě, že jsou všechna úložiště přístupná.
Například kombinace file based registry na lokálním disku a LDAP nám v základním nastavení funguje tak, že se ani uživatelé v lokálním úložišti (to bývají především admini) nepřihlásí.

Pokud chceme umožnit přístup administrátora vedeného v lokálním úložišti i přesto, že je nedostupný vzdálený LDAP server s bežnými uživateli, je potřeba na úrovni konfigurace WAS toto nastavit:

$AdminTask createIdMgrRealm -name ibmRealm -allowOperationIfReposDown true

Případně nastavit přes uživatelské rozhraní IBM Console:

JobManager - run wsadmin script

How to run a wsadmin script as a job using Job manager

Prepare a script to be distributed the script to the target.

Prepare the script on the JobManager side and store it into <jobmanager profile>/config/temp/JobManager directory (create the directory is does not exist)

Define Distribute File job in the job manager 

 Caution: The Source parameter has to have file:/ prefix see the picture bellow. It does not work without file prefix, I noticed that file:// does not work also on WAS version 8.5.5.8. 

If the Disribute File job finished succesfully use the Run Admin Script job:

The script output you can check in the SystemOut.log of managed deployment manager.

Starting IBM Support Asssitant on Ubuntu 12.04 64bit

During installation of IBM Support Assistant 5 I met following trouble that prevents the ISA server start.

Starting ISA by /opt/IBM/ISA/ISA5/start_isa.sh script I obtained following error message:

./start_isa.sh: 40: ./start_isa.sh: function: not found
USAGE:
  start_isa.sh [<tool_id>]
./start_isa.sh: 44: ./start_isa.sh: Syntax error: "}" unexpected

FIX is quite simple

The problem was that ./start_isa,sh use #!/bin/sh directive. Change the directive to #!/bin/bash on the first line of the ./start_isa,sh script.

Přiřazení principalName při LDAP user registry

Při konfiguraci LDAP úložiště je v nastavení pole Vlastnosti příhlášení (Login properties). Toto pole může obsahovat seznam LDAP atributů (oddělených středníkem), které mohou být použity jako login name. Obvykle to bývá uid;mail. Důležité je pořadí, do principalName se bude přiřazovat hodnota atributu, která je v seznamu jako první. V našem případě to je uid. Pokud by ale seznam byl mail;uid, pak by jako principalName byla hodnota emailu!