Thursday, 24 July 2014

How to run IBM Integration Bus v9 on SoftLayer Servers

This from my IBM Hursley colleague, Simon Holdsworth: -

In this article I will describe the steps I took to get IBM Integration Bus Version 9 installed and running on SoftLayer servers.  You might want to do this as part of establishing an off-premise cloud environment that includes integration capability, or for managing a pool of integration servers for development and testing.

This article shows how to set up a SoftLayer-hosted server and install and run software on it - in this case IBM Integration Bus - either through a traditional product install, or by using a Hypervisor Edition.  You can get everything working without leaving your desk, plugging in a cable or hitting a switch.

How to automate IBM Integration Bus deployments using IBM UrbanCode Deploy and Chef

 How to automate IBM Integration Bus deployments using IBM UrbanCode Deploy and Chef 

IBM UrbanCode Deploy orchestrates and automates the deployment of applications, middleware configurations, and database changes into development, test, and production environments. You can use IBM UrbanCode Deploy with IBM Integration Bus to automate the deployment of integration applications and configure the resources they depend on. You can also use IBM UrbanCode Deploy to automate the installation and configuration of the IBM Integration Bus runtime.

IBM UrbanCode Deploy - automating application deployments through your environments

IBM UrbanCode Deploy

IBM UrbanCode Deploy is a tool for automating application deployments through your environments. It is designed to facilitate rapid feedback and continuous delivery in agile development while providing the audit trails, versioning and approvals needed in production.

UrbanCode Deploy provides

• Automated, consistent deployments and rollbacks of applications
• Orchestration of changes across servers, tiers and components
• Configuration and security differences across environments
• Clear visibility: what is deployed where and who changed what
• Integrated with middleware, provisioning and service virtualization

IBM PureApplication System - Using IPAS to Isolate Virtualized Environments

Demonstrating workload isolation in IBM PureApplication System

Learn how to create two or more application runtime environments in IBM® PureApplication™ System that are highly isolated from each other so that the workloads in one environment cannot interfere with those in another. This article shows how to create them and demonstrates that they are indeed isolated.


Managing application runtime environments in IBM PureApplication System

In IBM® PureApplication™ System, deployers install applications into runtime environments that administrators define by using cloud groups and environment profiles. As an administrator setting up a PureApplication System, what are the cloud groups and environment profiles that you will need to consider and create?

Wednesday, 23 July 2014

Faster disaster recovery in IBM Business Process Manager

Faster disaster recovery in IBM Business Process Manager

Implementing a multiple data center approach to improve recovery time

This article describes an infrastructure topology for IBM® Business Process Manager that includes elements that reside in distinct data centers that may be geographically separated from each other. Such a topology can be useful in achieving disaster recovery objectives in certain circumstances, especially when recovery times faster those offered by traditional approaches are desired. Additionally, the strategy described in this paper uses Oracle®'s Data Base File System (DBFS) to enable the database manager to control replication of the WebSphere® transaction and compensation logs, as well as traditional IBM BPM database content. This content is part of the IBM Business Process Management Journal.

Network File System (NFS) Recommendations for WebSphere Application Server to AVOID DATA LOSS

This article details some known issues with the Network File System (NFS) implementations that affect the reliability of data stored on such file systems by the WebSphere Application Server transaction, activity and compenstation services and the Service Integration Bus filestore. When reliability is compromised file corruption is possible. In most cases this results in DATA LOSS. It also makes recommendations for configuring both NFS and WebSphere Application Server based on known configuration problems and customer experiences.

Or, of course, you can store the tranlogs in a relational database table, subject to WAS or upwards.

Using the global cache in WebSphere Message Broker

Using the global cache in WebSphere Message Broker

The new global cache feature in WebSphere Message Broker V8.0.0.1 enables you to store and reference data in an embedded memory cache or an external WebSphere eXtreme Scale grid. This article shows you how to implement a global cache to store and access reference data for use by message flows.


Most enterprise IT solutions have a requirement for reference data that is accessed frequently during operations. Until recently, this reference data resided in either a file or a database and was accessed through queries. However, querying a file or database consumes time and must be done repeatedly, resulting in a substantial performance hit. To overcome this problem, applications started keeping reference data in a cache in memory, which greatly reduces the time needed to access the data.

IBM® WebSphere® Message Broker V8.0.0.1 (hereafter called Message Broker) provides various ways to manage the cache. You can use shared variables in ESQL to store the data in memory. But shared variables are private to a message flow and cannot be shared across message flows or execution groups, which can lead to duplication of stored data across different flows, and higher memory requirements to store the data.

Alternately, you can load static data into an execution group's JVM heap, so that the data can be shared by multiple flows deployed in an execution group. With this method however, the use of the data is confined to that execution group.

The new global cache feature in Message Broker enables a message broker application to store its reference data in an embedded or external WebSphere eXtreme Scale grid. In an embedded global cache, access to reference data is spread across multiple execution groups that host the eXtreme Scale container servers. The data can be accessed by all execution groups, even if they do not participate in hosting the container servers. This article shows you how to maintain and access static data in a global cache using Java routines from ESQL or Message Broker Mapping nodes.