When to Use the Command Line Interface Rather than the GUI in Application Release Automation

Posted on May 17, 2012 by Helen Beal

Our Intuitive GUI

We’ve spent a lot of time at MidVision making our web GUI look slick and navigate intuitively, but more and more customers are asking us if they can use the Command Line Interface (CLI) instead, or often in combination with our GUI. Whilst our initial reaction was disappointment that people didn’t want to use the GUI we’d worked so hard on, we quickly realized, that actually this makes for a stronger solution as RapidDeploy can fit into organizations’ existing work-flow engines like HP Operations Orchestration or UC4, or any custom workflow engine your organization may be using.

What Can the Command Line Interface Do?

The command line interface can do all of the configuration maintenance and code deployment operations that are possible from using the web-based Graphical User Interface (GUI).  It has comprehensive help from the command line which describes all the administration operations and their parameters when executing commands from the command line.

It is now possible to create server definitions, define projects, change deployment configuration, create a new deployment package and then run the job on the target server to deploy the new package all from the command line.  We can also define RapidDeploy jobs to run in parallel or run sequentially on the target server.  This feature is useful when you want to install a JBoss instance and then deploy an application and/or configuration on top of the new installed JBoss instance.  In this scenario you would want the installation job to complete successfully before the application and/or configuration is deployed to it.  Another example would be to have a job that creates an Oracle database instance, a user and assign some roles to the user and then a second job that creates a new schema and adds data to it using the user created in the first job.

Using JMX

The command line client server communication uses JMX and is designed to run on any remote server and as long as you specify the user credentials and the host and port that the RapidDeploy server is running on you can administer from a remote location (subject to firewall constraints).

A lot of our customers are now integrating RapidDeploy using this new CLI and are finding new ways to build up new virtual machines (VMs) from the ground up to use their workflow engines to create the machine, install the operating system and then plugging in RapidDeploy to deploy application binaries and default configuration onto those installation.  This is a great new way to quickly and reliably create new VMs and ship them to development and testing teams.

If you want to try out the RapidDeploy Command Line Interface for yourself, please request a free trial here. If you’d like to see RapidDeploy in action, you can find our youtube channel here.

Posted in Release Management | Leave a comment

7 Highlights in the New RapidDeploy 3.2 Release

Posted on May 15, 2012 by Helen Beal

We released Version 3.2 of RapidDeploy™ at the start of the month, here are some highlights of what you can find when you upgrade:

1) You can now upload packages via the browser based user interface – we’ve also made some improvements to the screen navigation and short cuts so that you can have an even better experience including the capability to create task and resource  help for user created tasks via the UI

2) Any variable written as ${VAR_NAME} will be expanded on the target server to the matching environment variable or java property set on the target server –  tokenization allows you to generecise your deployments, meaning a core task can be used across your estates.  As well as bespoke tokenization we also, by default, replace variables in the format ${XXX} with their corresponding environment variables or java.properties (where they exist)

3) Users can upload task jars (comprising in-house written tasks) into a task repository to be available across the site – we’re always making it easier for you to reuse your existing assets

4) We’re adding more capabilities for the Microsoft platforms – here we’ve included MSI Package install, PowerShell tasks

5) We’re making it easier for you to do stuff when you’re not even in the office – this time we’ve made it possible to schedule any Job e.g request, plan snapshot, discovery etc to occur at recurring intervals via a cron like job scheduler, through the UI

6) Extensibility – more and more customers are saying they want to link RapidDeploy to other orchestration tools and so we’ve rewritten the JMX interface. All major functions in RapidDeploy UI are now also supported through the command line interface

7) We’re always working on the workflow – we’ve made it possible to place a human task step between deployment requests in a plan – you can then force the plan to continue or abort after a human task timeout (CM Libs Deployment Window)

You can download release 3.2 from here or, if you’re not authorized to do that, you can request a trial version here.

Posted in News | Leave a comment

5 Ways to Supercharge Your WebSphere Deployments

Posted on May 14, 2012 by david.sayers

1) Deploy Applications and Their Configurations Together

The simple part of WebSphere deployments is the installation of the application itself. The complexity is in the provision of the application dependencies – container configuration, data-sources, web services connections, JMS resources, etc. Use a tool that will not only allow the application to be deployed – but also determine the what configuration dependencies are required and create them if they do not already exist.

2) Control the Source Control, Build and Release Environment Configuration in Your WebSphere Deployments

Configurations for target environments should be stored in a version control system. A Development Manager that did not use source control for the application code would be asked: “How do you know who has made change during your WebSphere deployments? How do you know the differences introduced over time? How can you roll back failed change? How can you audit what has happened / ensure compliance?”

As an Infrastructure or Operations Manager you should ask yourself the same questions about your WebSphere deployments – if you do not stored configuration for your middleware in source control, audit who is making changes to it, and release those changes using a versioned deployment process. This trend of version control, build and release configuration change is new in the market but will become more widely adopted as vendors such as MidVision promote it and the market sees and realizes the benefits.

3) Manage Any Configuration Drift in Your WebSphere Deployments

Configuration drift is the ability to detect unauthorized / unaudited change in your WebSphere deployments. RapidDeploy does this by connecting to the deployment manager via JMX and generating a snapshot of the ENTIRE cell configuration and storing this on the framework server. We can schedule snapshots to happen – for example every week – and alert on change that has been made manually on our target servers. This is a “Belt and Braces” approach: point 2 above is the belt (controlling how, how and what can be done on a target) and the ability to determine if anyone has bypassed this process is the braces! If you are doing a vendor review – ask if they have this feature. We believe we are only one of a few vendors that can do this – and we can do it across not only application servers (WebSphere, WebLogic, JBoss, TomCat, etc.) but also databases like Oracle and messaging / interoperability infrastructure like WebSphere MQ, Message Broker and DataPower.

4) Let Your Staff Serve Themselves

Allow your consumers (developers, release / project managers, etc.) to perform certain actions – like install applications, restart application servers or even make some basic pre-define change (like change logging levels, point to a different database, etc.), in the earlier environments on the path to production. If a WAS admin releases a new EAR file when asked to by a Release Manager – why not let the Release Manager do it himself? A requirement to “bridge the DevOps gap” is to have a consistent set of tools used for development and operations environments – simply with different users / access / security requirements defined for each.

5) Don’t Build It When You Can Buy It

I am not saying you should buy RapidDeploy – although I can recommend it ; -) – but you should evaluate a tool for application release automation if you have more than 20 or 30 servers / environments to manage. A development team that does not use tools for build, dependency management, code coverage, etc. (tools like Maven2, Jenkins, RTC or TFS, etc.) is living in the dark ages. Whilst this is not a prevalent view yet – writing your own scripts to manage your infrastructure will be thought of this way soon. Quite simply – there are tools that are available to do the heavy lifting for you. If you think your middleware environments are different to other organizations therefore you need bespoke scripting, how do I put this politely… You’re wrong! ; -) Of course you have some minor differences that need to be catered for – but on the whole whether you are working with WebSphere, JBoss, TomCat, WebLogic, .Net or anything else you are carrying out simple configuration and deployment actions that there are tools available to manage.

See RapidDeploy Managing Configuration Drift in WebSphere Deployments

You can download a free trial of RapidDeploy for WebSphere Deployments here.

Posted in Composite Deployment, Configuration, DevOps, Middleware, Release Management | Leave a comment

The Role of the Infrastructure Developer in DevOps

Posted on May 11, 2012 by david.sayers

I was at IBM Impact in Las Vegas last week and at the many sessions on DevOps there was some discussion about the concept of an infrastructure developer. I believe the role of the infrastructure developer is an interface between the development and operations teams – taking the application components and requirements from development and translating them into automation patterns. Rather than simply documenting what is required by applications in the runtime / operations environments – this is instead ”coded” in a scripting or automation framework of your choice. These automation templates are meant in essence to be self documenting – and can be taken by operations teams to implement the environments on the “path to production”.

Infrastructure as Code

This concept introduces another new term – “Infrastructure as Code”. These are automation patterns or some type of automation mechanism - be it a framework, scripts, etc. packaged into a release package in a similar way that developers have traditionally packaged application components into JARs, WARs and EARs. This package of “infrastructure as code” can be built, versioned, released in a very similar way to application versions – and is bringing the best practices from the development world to infrastructure management. This approach is something we have been promoting at MidVision for a long time and are very happy to see its more widespread adoption in the market.

DevOps Contentions for Infrastructure Developers

There are a couple of areas of contention in the debate that is emerging around DevOps. The first is “What are the tools of choice for the Infrastructure Developer?” There is one school of thought that it is tools like Puppet, Chef, etc. which are powerful scripting frameworks that allow highly skilled developers or engineers to create automation patterns and templates. The other – which is the one we believe in at MidVision and the basis on which we have designed our RapidDeploy application release automation solution – is that almost all of the routine tasks that need to be carried out can be catered for by a visual orchestration capability with access to a pallet of pre-defined tasks. Be that stop a service; create a WAS cluster; an MQ Queue Manager or Queue; unzip a file; amend a document using xpath; etc, etc. - these are the type of things that most people are automating – and tools like RapidDeploy (as well as others in this space) provide the ability to orchestrate these automations without the requirement for any scripting at all.

Deployment Automation Tools for Infrastructure Developers

Tools like Maven and Jenkins have revolutionized the application build processes and require only configuration – no longer do people write build scripts to create applications. The same is happening in the deployment automation space – the tools are not yet as advanced nor mature as their build counterparts – but they are a lot more efficient and robust than the scripting alternatives and are progressing fast.

Another question is: “In which department does the Infrastructure Developer (or I guess they could also be called a DevOps Engineering, Designer, etc) – work?” In some organizations which have a dedicated architecture and engineering function this may be clear – in others the debate may be whether the development team write the “infrastructure as code” automation and provide these to operations / IT departments in the same way they do the business applications. Or whether it is Operations who would “own” the automation. Of course to bridge the DevOps gap we need to use the same mechanism to provision, manage, deploy, etc. across all environment from Development to Production – so this should reside in one of the Dev or Ops departments not both. My personal opinion and I believe what will prevail – is that this will and must be owned by operations.

Infrastructure Developers can download a free trial of RapidDeploy here.

You can see RapidDeploy in Action here.

Posted in DevOps, Middleware, Release Management | Leave a comment

su – command inside a loop

Posted on April 3, 2012 by richard.bettison

If you have a script that runs su commands from inside a loop, you might find that the loop terminates silently before all of the iterations are complete.

cat $file | while read theline
do
        ... Get the user and the script ...

        echo "su - $user -c " $script
        su - $user -c "$script"         

        ... Do soome post processing ...  

done

In this case try changing the above su command to this:

  su - $user -c "$script" < /dev/null

Posted in Code, Unix And Shell | Leave a comment

The Golden Configuration: Right First Time, Every Time

Posted on February 3, 2012 by kuli

The Current Landscape

Most organizations do not have the concept of a golden configuration and middleware technologies are managed and deployed in an uncontrolled manner. During the development lifecycle from dev to prod different teams are involved. Also, different people may deploy technologies in different ways and have their own scripts. Worryingly, enterprise infrastructure is not deployed with the same rigor and discipline as code is: people deploy different templates and patterns for the same things, or worse still, they may manually make configuration changes to different environments via GUI clicks.

The Consequences

All the above means that management of complex Enterprise Infrastructure in a medium to large enterprise is fraught with difficulties; no-one has a single view of what is happening and there is no consistency between one environment to the next.  The result?  Your organization requires a huge number of resources, deployments are slow and onerous, lack of consistency leads to errors and this leads to unacceptable levels of risk when deploying into your critical production environments.

A Solution – Introducing the Golden Configuration

Changing this situation can be challenging: it requires process reorganization and technology can help.  A single suite of Application Release Automation technologies (ARA) such as RapidDeploy™ can help.

One way of ensuring consistency is to use the concept of starting from a Golden Configuration which all environments are built on. This can either be built from scratch, or one can take existing infrastructure, and use it as the basis to move forward. In the case of established infrastructure, RapidDeploy™ can be used to easily reach out to a given environment and import a snapshot of the artefacts and configuration.

Once we have this snapshot, it is beneficial to externalize out the environment specific configuration, leaving a set of environment neutral artefacts: we can refer to this as modelling, which would require the input of various teams (e.g. design, development, operations).  The combination of a single set of artefacts for a given project and multiple configurations for each environment are combined to form a single package which can be deployed across the development lifecycle in a consistent and error free manner:

The advantage now is that we can use our deployment technology to ensure that we always deploy to all our environments the same way.  The artefacts remain the same, but the externalized configuration for each specific environment changes.  By using a Golden Configuration throughout the deployment lifecycle we ensure that we are always consistent.

In the diagram below,  we see how our Golden Configuration can be used to easily clone new environments. All new environments for a given project would be cloned the same way, from the same core set of artefacts:

Once we get to production, we would expect our deployment package for a given project to consist of a single set of neutral artefacts combined with multiple configurations for all our environments.

Our packages could be technology specific or contain composite technologies.  For WMQ we would have a single set of mqsc definitions, and our configuration would contain the various attributes we would like to change e.g. sender channel connection names, maximum message lengths, queue depths etc.  For WMB we would have a single set of BAR files and we would then have configuration to specify properties of BAR files to override, configurable services etc.

In conclusion, we can see how the combination of technology and some careful analysis up-front can yield enormous benefits, allowing an organization to manage and scale hugely complex and heterogeneous technologies across the enterprise quickly, accurately and efficiently.

You can request a free trial of RapidDeploy to help you create a golden configuration here.

You can see RapidDeploy in Action Here

Posted in Configuration, Release Management | Tagged , , | Leave a comment

Big Bang or Incremental Migration Towards Automation – People, Process, Tools

Posted on February 2, 2012 by robvanstone

You’ve Made Your Choice – Automation

  • No more ad-hoc management of your middleware and database technologies – you’re getting automation
  • Reduced number of technologies doing the same thing in different ways – you’re consolidating
  • Reduced number of Single Points of Failure, allow your “Heroes” to focus on the bigger picture – you’re increasing productivity

You have decided to achieve one or more of the above goals within your enterprise and you have identified a tool which promises to deliver the technical functionality required to manage your environments consistently, systematically and efficiently.  (By the way RapidDeploy™ is the ideal tool to install, configure and deploy code to WebSphere Application Server, WeSsphere MQ, WebSphere Message Broker, JBoss application server, WebLogic, TomCat and many more).

The technology within an enterprise is only part of the picture.  Your concerns may very well be; how do I actually use it? how can I fit it into our organization? how can I fit my organization around it?

We have clients asking us these very questions and fortunately for us (and them!) we have the answers.  RapidDeploy™ is built around these very realities.  It is truly an enterprise product that can scale to fit your organization.  Role base access, separation of duties engineered from the ground up.

The reality is that in most large organizations a “big bang” approach is unrealistic.  It can be done, and proper planning (which should be done in any case) will pay dividends, but this sort of thing can be built over time.  Plan your strategy, then take action.

Pick a team, any team

RapidDeploy™  is ideally suited to supporting separation of responsibilities (which is very much becoming a regulatory mandate across most industries).  If you want to start small perhaps look at those teams that are spending the most time maintaining the configuration of your Application Servers and other middleware across hundreds of heterogeneous environments.  Most of that time is ensuring the correct files are copied to the correct locations and the correct commands are being run against the appropriate technologies.

The people doing these tasks are highly intelligent individuals often overwhelmed by the mundane and time consuming activity of moving files around or filling in spreadsheets or both.  We have discussed at length in previous posts about the automation of this aspect and ensuring it is done the same way for every level within your route to live, but how do you make this work in practice and on a large scale?

Simple, Role based access and separation of duties which we implement with our user and group processes – for example in the case of Websphere Message Broker (WMB), we could create the group WMB Configuration Team.  We can associate that group with the WMB Configure Projects that exist.  Projects in this context are defined sets of tasks that have been written to automate the deployment of message broker configuration (e.g. creation of message brokers, execution groups, update of broker properties etc).  We could have more than one such group for different teams (for example a production team and a pre-production team).

As well as restricting access to Projects to certain groups we can also do this against targets (i.e. Servers).  This means that even though different teams may be executing the same Projects, your development deployment teams could be restricted from being able to deliver to your Production environment.  Separation in this manner has the advantage that you don’t create a bottle neck for development work by giving your production configuration and admin teams this responsibility with their already significant commitments.

Separate groups can eventually be created for those that will deploy code, install binaries and any other deployment activity you have in mind.  Once created the process is just standard user management to ensure the correct people are members of the correct groups.

Develop and Follow your Process

I am not saying that all this just falls out of the box, it does take planning, and so it should.  We are not playing here, this is managing very important environments on a large scale.  Something that we have considered through every stage of development of RapidDeploy™ .  The advantage of starting with a smaller team means you have more flexibility as you develop your processes.  Less people are impacted as you iron out the kinks.

Incremental migration means that the scale of your organization needn’t daunt you. Attack it piece by piece.  RapidDeploy™  is ready for it, and so is MidVision.  We are keen to help you on your way.

Check out our demo projects and quick start guides.  We are more than happy to work through them with you as you develop your understanding.  Head to Support > RapidDeploy 3.0 > Documentation to view our quick start guides for a wide range of technologies.  Then contact us either directly or through our forums to explore how these demos can scale to fit entire organisations.

Posted in Configuration, DevOps, Users and Groups - Role based access | Tagged , , | Leave a comment

From G to C: What’s New in Oracle WebLogic Server 12c?

Posted on January 20, 2012 by Helen Beal

Oracle’s new release in December 2011 of its web application server, WebLogic, has seen a suffix change from G – for ‘grid’ to C – for ‘cloud’, thus, as industry analysts Ovum have said, “declaring that the dominant theme for the next generation of Oracle Fusion Middleware will be support for the cloud”. Oracle themselves say that this is the most significant release of WebLogic Server to date, as it is the first release of WebLogic Server that is compliant with Java Enterprise Edition 6 (JEE6), catching up with IBM WebSphere and also overtaking it with support for JSE7. The most important goal of the Java EE 6 platform is to simplify development by providing a common foundation for the various kinds of components in the Java EE platform. Developers benefit from productivity improvements with more annotations and less XML configuration, more Plain Old Java Objects (POJOs), and simplified packaging.

Changes have been made to the administration console to support JEE6 around, deployment, the application and SCA containers, split source and application and module naming. Support for managing EJB modules that are directly inside of Web application archive (WAR) files via the Administration Console has also been added removing the need to produce archives to store the Web and EJB components and combine them together in an enterprise application archive (EAR) file (a function of EJB3.1).

There’s also a new Maven plugin with enhanced functionality to install, start and stop servers, create domains, execute WLST scripts, and compile and deploy applications from within your Maven environment – useful if this is the only application server you are running, although a full application release automation tool will be more powerful if you have a heterogenous environment or a substantial number of application releases to manage and audit.

There are lots of updates to the EJBs, JDBC data sources, resource adapters and web services, mainly to bring them up to speed with JEE6, now that Oracle has taken and stabilized Java from Sun and breathed new life into the industry standard. But it’s the cloud capability that’s key: the now second generation Oracle Virtual Assembly Builder (OVAB) has been upgraded. OVAB, like IBM Workload Deployer (Cloudburst) allows WebLogic instances or containers to be provisioned to what Oracle refers to as “virtual appliances”- that is, deployment to an environment where resources are pooled, such as a grid or private cloud.

In 12c OVAB has automated a number of previously manual steps as well as exposing its provisioning capabilities as services that are callable from Oracle Enterprise Manager and deployable on Oracle Exalogic-optimized private cloud machines. New, related features in Oracle Enterprise Manager add metering and chargeback functionality – useful for managing private clouds. The new release also adds load-balancing integration with the Oracle Exalogic platform, supporting elasticity and reducing processing bottlenecks. A new feature, Traffic Manager, integrates directly with Exalogic’s Traffic Director facility, routing and load balancing throughput on its high-speed Infiniband backplane. This capability may become available on non-Oracle platforms in the future.

You can read the full Release Notes for Oracle WebLogic Server 12c here or if you’d like to see some of the new features in action and discuss how they could benefit your business, you might like to join our webcast on the 9th February 2012. You can book your place here.

Posted in Middleware | Leave a comment

What’s New in IBM WebSphere Message Broker 8.0?

Posted on January 11, 2012 by Helen Beal

WebSphere® Message Broker V8.0 delivers further enhancements to productivity and ease in developing and managing enterprise service bus (ESB) deployments, complementing its industry-leading performance and scalability.
New in V8.0:

  • Comprehensive support for Microsoft™ .NET environments
  • New Data Format Description Language (DFDL) standards-based parser for text and binary data
  • New Graphical Data Mapper for transforming XML, text, and binary data
  • Enhanced auditing of data with new edit, record, and replay functionality complemented by comprehensive graphical tooling
  • Direct connectivity and productivity aids for integrating with IBM® Sterling Connect: Direct
  • New Hypervisor Edition for IBM AIX®
  • Tiered pricing model, including new Express® Edition
  • Support for Web Services Reliable Messaging (WS-RM)

Comprehensive Support for Microsoft™ .NET Environments
Now you can access your .NET applications and assemblies from your message flows and write your message flow logic using C# or VB.NET or any .NET 4.0 CLR-supported language, using Visual Studio.

The Toolkit has a new .NET Pattern and project wizards for Visual Studio.

New DFDL Standards-Based Parser
A new Data Format Description Language (DFDL) enables any text or binary data to be understood within the message model. Message Broker’s “MRM” capability has supported this for some time but now it also supports this new industry standard too. There’s a new mapper:

and also a set of utilities for testing message models inside the Toolkit so developers can now confirm that the model matches the test data without having to perform a full model->deploy->test-at-runtime cycle.

Simplified Development Experience
There are several enhancements to the development experience in V8.0, but one to note in particular is what’s known as “Apps and Libs”. Message flows may be grouped into a unit called an Application which can be deployed, stopped and started as a whole. With Libraries, there are also truly re-usable assets like .esql files, or sub-flows, which can be deployed and updated separately, and invoked dynamically at runtime. This is a key change in the way that the Broker works; previously, sub-flows were compiled into the main flow and changing one required redeployment of all flows using it. They are now dynamically linked when needed, so they can be more easily deployed and replaced.

Web Administration
Delivered in version 8 is a first stage in making the Broker more easy to administer from a lightweight client – a web browser. Whilst power users and existing administrators can continue to use the Message Broker Explorer GUI, there is now an easy way to enable an optional web interface for basic administration tasks. Continuing the theme of simplicity the product has followed for a while, no additional moving parts (app or web servers) are required! Version 8.0 provides read-only views of running Applications and access to the log – more capabilities will be rolled into this interface in the future.

Enhanced Audit of In-Flight Data with New Edit, Record, and Replay Capability
The ability to understand and monitor the data flowing across corporate networks is becoming an imperative for many organizations. With the increase in regulatory requirements many large organizations are implementing more extensive audit capabilities for data in their network to capture data as part of a system of record.

Additionally, with operational costs under more scrutiny, and users expecting ever faster turnaround times, the ability to quickly identify and correct erroneous data to prevent downstream processing problems, and lost or delayed orders, can translate into improved efficiency and customer satisfaction.

The edit, record, and replay capabilities in WebSphere Message Broker V8.0 provide new and powerful browser based tooling which allows suitably authorized users and administrators to view, edit, record, and replay data flowing through the broker from all sources, including messaging, web services, and Enterprise Information Systems.

Secure role-based access for end users, auditors, and administrators ensures that users can only view in-transit data of relevance to them, and administrators can control access to restricted data through the use of predefined filters, including masking of sensitive data within a payload.

Using configurable filters, users can search for specific data using a number of different criteria, including transaction type and ID, as well as payload information. Once found, the data of interest may be stored unchanged for audit purposes in any of the WebSphere Message Broker supported applications or databases. Alternatively, users may choose to edit the data to correct errors before reprocessing via existing WebSphere Message Broker flows.

Direct connectivity to IBM Sterling Connect: Direct
Many organizations have chosen IBM Sterling Connect: Direct for processing file based data, both within their business and in communicating with business partners. In order to support connectivity between these file based networks and messaging, or other enterprise applications, WebSphere Message Broker V8.0 introduces new integrated nodes and developer aids for connecting to IBM Sterling Connect: Direct.

By utilizing WebSphere Message Broker as the bridge, clients not only can take advantage of the broad range of connectivity, routing, and transformation capabilities offered by WebSphere Message Broker, but can gain end-to-end visibility of file and message traffic across the business network.

WebSphere Message Broker V8.0 provides common transformation patterns on the toolkit palette for rapid integration between the file and messaging based networks. Common patterns, such as conversion of a batch of records to or from WebSphere MQ messages, are provided out-of-the box to support rapid development of flows.

Reliable communication with Web Services Reliable Messaging
As companies expand their use of web services and XML communications, provision of reliability is increasingly important in both internal and business-to-business scenarios. For certain services, delivery of SOAP messages needs to be assured, without duplication, and when connections or endpoints are temporarily unavailable.

WebSphere Message Broker V8.0 allows WS-RM to be configured on a Message Broker flow. This is an administrative task that does not affect the flow design. An enhanced policy set editor allows customization of WS-RM behavior, including whether message order within a sequence should be maintained.

Richer, yet easier to use
IBM has been strongly focused on “consumability” (translation for non-IBM-speakers = UX) for a number of years now. WMB continues to add capabilities that make it a richer, stronger integration platform, but also smooths out rough edges seen in earlier releases and is ever easier to use. There’s even a drive to reduce the jargon and make the Broker logs more easy to understand, with new Activity Logging which aims to explain what a flow is doing in plain language (“GET message queue X”, “Update DB table Z”, and so on).

Our certified WebSphere Message Broker administrators and developers at MidVision have been working with V8.0 since it was in beta development and are ideally placed to help you understand how this technology can help you do business faster, whether you are new to the platform or thinking of an upgrade from an earlier version. Join our webcast on the 2nd February 2012 and listen to the updates in detail and see V8.0 in action!

Posted in Integration | Tagged , , , , , | Leave a comment

What’s the Truth? IBM WebSphere MQ Deployments

Posted on December 16, 2011 by robvanstone

Java guys and other application developers have been doing it for years (decades!) – writing code, storing it in a Source Code Management tool, building it and deploying it through their “route to live”.

WebSphere MQ Deployments are a bit of a halfway house.  Often viewed as infrastructure, but heavily relied upon by code, the configuration and maintenance is usually a hybrid of MQSC scripts and GUI interaction.

Don’t get me wrong, there are many of us out there that are stalwart, file based, scripted deployment evangelists and apply exactly the same rigor we might to application code to WebSphere MQ – but it does remove some of that awesome flexibility that MQ provides. It also requires a programming head to manage your MQ source and be able to deploy it securely, consistently and repeatedly to your environments.

MidVision’s RapidDeploy™ neatly takes care of your WebSphere MQ Deployments but what about the point of truth? You already have an MQ environment that you have evolved by a combination of GUI updates and baseline source controlled scripts, but what is the point of truth?

Bluntly speaking?  Your production service.  If you have no reliable source that accurately describes what should exist in production, then your source IS production.  A little scary right?  No problem!  You can bring all this back under control (and improve the rigor surrounding how you make changes to your environments) with RapidDeploy™.

Snapshot your production environment.  Create a template from this snapshot and parameterize all of the items that vary between environments (in your route to live).  You can now clone this snapshot and create Environments within RapidDeploy™ that exactly represent your production environment.

The MQ infrastructure can then be pushed onto real servers so that your test environments are exact representations of Production (just as you want them to be).  In addition, all of this configuration can now be in your Source Control system which RapidDeploy™ will happily integrate with.

This is the only point at which I would recommend the top down approach.  Once this has been done normal business can be resumed and you can progress changes intended for production from Development up through the stack to Production by deploying using RapidDeploy™.

Find out more about RapidDeploy™, check out our forum pages or contact us

Posted in Configuration, MQSC Commands, Release Management | Tagged , , , , , , | Leave a comment