Sidebar

Debunking ESB (Enterprise Service Bus)

General
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

One of the major issues that CEOs face today is the responsiveness of businesses. Some 75 percent of CEOs place high priority on finding effective ways for businesses to respond more rapidly to competitive threats. According to Jim Wagner, Senior Vice President of Marketing and Licensing for Mattel, "New market ideas come in waves, so it is essential to move quickly to get first-mover advantage, even if preliminary information isn't 100 percent."

Only 10 percent of CEOs believe that their organizations have the ability to be responsive and to react to changing market conditions. A Business Performance Management survey revealed that only 11.2 percent could keep up with the business demand to change processes. Worse, 26.6 percent reported that their IT departments have significant difficulties keeping up with business changes and 9.2 percent acknowledged that they couldn't keep up at all. A report released recently from Forrester Research Inc. revealed that while 78 percent of the CEOs surveyed say that they're happy with the job performance of their CIOs, fewer than half have confidence in IT as a contributor to business success.

Management acknowledges that we must respond to continuing changing market conditions and risks. Agility has been made a high priority across organizations, yet few CEOs rated the responses to changing conditions to external forces to be very good. They recognize the need to create adaptable business processes that allow real-time responses to their customer needs. They are also aware of the power of IT and the weakness that comes from lagging behind. The idea is to have IT become more agile and to eliminate the backlog of applications so that businesses can get what they want whenever they demand it.

Despite this awareness, IT still continues to develop in isolation from other systems. This becomes time-consuming and costly. In order to deliver aggressive solutions, IT must sooner or later face integration and connectivity challenges.

Service-oriented architecture (SOA) has been touted as the key to business agility and the face of modern IT integration.

Evolution to Make IT Responsive

The desire to make IT more responsive has been going on for decades. Early initiatives involved making monolithic architectures more flexible and structured by breaking them into more-executable subroutines. Then came the idea of business objects—the pattern for three-tier architecture that recommends partitioning application functionality into business logic, access of data, and application behavior, which could change pending on the context or request. Object technologies were mostly tightly coupled, so messaging technologies were developed to loosely couple applications. Various Enterprise Application Integration (EAI) techniques were then developed to make applications even more modular. The good news is that today, with the culmination of all these architectures, we have SOA. SOA blends the best of all these concepts and promises to make the notion of applications even more flexible. It is built on the design of objects, message processing, and services, and it really paved the way for dynamically reconfigurable architectures of the future.

Are You MOM-ified?

Messaging Oriented Middleware (MOM) products are more flexible than Remote Object Invocation because they decouple services through an Intermediary Broker. But MOM lacks a service interface and is typically limited to a single transport. Functions must be written to call the messaging middleware and dictate specifically where and how messages should be delivered. Anytime function changes, the application code needs to be modified and redeployed. This method of dependency is hard to manage, change, or even keep track of. Functions linked through MOM also have implicit dependencies on the message protocol, the data format, the structures, security, and error handling.

The Role of ESB

As integration requirements rise, organizations will seek a technology platform that provides loose coupling and simple information exchange. An agile enterprise must be able to change the way it does business by adjusting processes without undertaking costly, lengthy, and risky modifications to its information system.

Can an Enterprise Service Bus (ESB) help bring agility and responsiveness? Articles about ESB often characterize it as the backbone upon which you build your SOA. ESB has become the SOA industry buzz as the new EAI. In the November 2006 issue of iTechnology Manager, I wrote an article called "FAQ on SOA" that discussed SOA's involvement in the strategic success of IT: "An ESB must eliminate the need to deal with upgrades and load balancing between instances of specific services. It is uncertain that today's ESB delivers all these capabilities." I had my doubts whether true mediation existed. Some vendors' ESBs are more enhanced EAI; some are MOM products that are proprietary in nature.

EAI Is Not ESB

Traditional EAI products were specifically designed for application integration. EAI was developed to make diverse applications in an enterprise, including your partner systems, communicate with each other. The business objectives connect seamlessly in a reliable fashion irrespective of platform and the locations of applications.

EAI performs application-to-application mapping and binding by means of "hub and spoke" architecture (see Figure 1).

http://www.mcpressonline.com/articles/images/2002/Debunking%20ESBV6--04230700.jpg

Figure 1: EAI performs application-to-application mapping and binding by means of "hub and spoke" architecture. (Click figures to enlarge.)

Hub/spoke architecture uses a centralized broker (hub) and adapters (spokes) that connect applications to the hub. The spoke connects to an application and converts application data format to a format that the hub understands and vice versa. The hub, on the other hand, brokers all messages and takes care of transforming content and translating the incoming message into a format the destination system understands. Within the hub are activities for validation, routing, and asynchronous delivery of messages. In short, EAI architecture is based upon a central operation: the hub. Most EAI products come with an administration console to monitor and track the workings of the hub.

It is often too costly and impractical to staff projects with IT professionals deeply knowledgeable in an EAI product. EAI is often proprietary, and semantic details are required. During deployment, scaling EAI architecture to accept additional duties requires extensive resources within your enterprise.

As a result of tumultuous discussion in the integration market caused by the advent of ESB, EAI vendors started creating their own versions of "bus" technology.

http://www.mcpressonline.com/articles/images/2002/Debunking%20ESBV6--04230701.jpg

Figure 2: EAI vendors created their own versions of "bus" technology.

The EAI version of bus technology uses a central messaging backbone (their bus) for message propagation. Applications publish messages to the bus using adapters. The key difference between hub/spoke and bus topology is that, for the bus architecture, the integration engine that performs message transformation and routing is distributed in the application adapters. The bus architecture requires an application adapter to run on the same platform as the original applications.

Will the True ESB Please Rise?

The true ESB provides the same functionality as the EAI version of the bus. It provides connectivity and routes messages based on rules and message transformation. The difference here is that true ESB capabilities are SOA-based.

http://www.mcpressonline.com/articles/images/2002/Debunking%20ESBV6--04230702.jpg

Figure 3: The true ESB provides the same functionality as the EAI version of the bus.

The EAI version of the bus also considers itself as a messaging backbone; however, the technology still depends on adapters to publish application messages. True ESB does the protocol conversion, message transformation, routing, and message delivery to and from various services and applications without the help of an adapter.

A true sense of an ESB can be summed up in one word: agility. You can add a service at a drop of a dime without having to rebuild your application systems. Think of a merger scenario in which companies want to move consolidated divisions quickly and remove redundant systems. Services decoupled from one company should be able to merge into an existing bus with minimum impact to business. In these instances, any ESB can be agile. I guess it all depends on your topology of what an ESB must have.

http://www.mcpressonline.com/articles/images/2002/Debunking%20ESBV6--04230703.jpg

Figure 4: Compare EAI hubs, EAI buses, and ESB.

Connectivity

Each of these bus approaches has set out to follow the principles of SOA. SOA advocates reusing existing assets to create new services. The EAI version of the bus uses connectivity and adapters to ensure that legacy applications can be connected to the ESB. This solves many of the integration issues, but does it make it SOA?

The most common way for the System i to process messages over a transport is by using MQSeries. One of the few things to consider when selecting an ESB is how easy is it to connect to such transport. Some ESBs can easily achieve this using their Java Messaging Service (JMS) integration. Service end-points can be easily exposed on the ESB to allow clients to contact systems using a variety of transports, MQ included.

The use of these standard transports ensures that integration issues are addressed, thus reducing the cost of reuse of these services. We need to enable existing systems to be reused; the quickest method is simply exposing the existing interfaces to these systems as Web services. The payloads on these services are usually text-based and typically consist of fixed-width fields. They are normally expressed in XML to achieve interoperability, an SOA standard. Transformation may occur at times on these payloads. Don't be fooled by the early ESB adopters who chose to develop their integration using servlets that process XML documents. While these provide the benefit of XML and HTTP transport, they still lack the features required by SOA. Exposing them as Web services provides the missing feature and standardizes the protocol envelope (SOAP). Your ESB acts as a buffer in front of your Web service to protect it from issues relating to exposure to new clients.

The trick early adopters used was using XML parsers that support only certain XML name spaces. They rely on particular prefix or proprietary name spaces, which may lead to interoperability. This transformation ensures that only XML messages that are understood are received.

Flavors of ESB

I recently attended the ESB-CON III Webinar. It was difficult to sit and listen to a lot of self-promotion and corporate chess moves during these four hours. In the past months, I have been evaluating three ESBs from leading vendors that are known to integrate with the System i. This seminar gave me more insight to other vendors. Here are the common key points I got from the vendors:

  • Support numerous end-points—Customers can choose from a wide variety of end-points. The ESB must easily flow transaction requests and coordinate between end-points. The end-points must participate in the transaction.
  • The ESB is more than just brokering a message—An ESB should include messaging, composition, management, and routing. Quality of service is the key.
  • The ESB needs to support different types of protocols and standards—An ESB must be able to broker many protocols and support all open standards, not just Web services.
  • The ESB must be easily configurable even without compatibility—An ESB must be able to change through metadata, allowing easy change without impacting business users.
  • The ESB must increase agility and maintainability—An ESB makes it faster to integrate in an open and more operable fashion. Business rules are part of your architecture. You can encode rules in your application, but deployment will be hard. Rules engines must reside outside the application and must be easily modified without modifying your application.
  • The ESB must be reliable—Many integration projects require a high level of uptime, and ESB must guarantee transaction delivery.

IBM, BEA, Progress Software, and Oracle provided samples of their best practices and actual experiences on ESB integration. I was not entirely sold by all the hoopla presented by the vendors, but I did get new views and answers as to where ESB products are today. I discovered there are three major types of players:

  • Startup ESB vendors—Cape Clear and PolarLake are vendors that entered the integration market by providing ESB solutions.
  • Integration vendors—These vendors evolved from EAI markets like TIBCO, iWay, Vitria, and WebMethods. There is no "standalone" ESB solution, but more provide ESB features as part of their suites. Other vendors, such as Progress Software and Fiorano, have a history in the JMS architecture, while IONA had CORBA middleware space.
  • Platform vendors—These vendors come from the application or enterprise application arena and now have integration solutions in their product line. Vendors include IBM, BEA, Oracle, Microsoft, SAP, Sun, and Software AG.

The current offerings of most ESBs have features like connection (support of Web services and SOA protocols), mediation (transformation, mapping, repository, registry), and change management (policy, SDLC, security, monitor).

Not to confuse everyone, but "the new kids on the block" just emerged. Open-source enterprise vendors like LogicBlaze and Mule are added to the mix to provide their ESB solutions.

Proof of Concept

The System i is a remarkable server that plays very well in the SOA space. Many leading companies use it across highly competitive markets like finance, healthcare, manufacturing and distribution, and retail. Companies are seeking new ways to generate enterprise agility from their current infrastructure. Small to medium-size companies might see an ESB at the end of their horizon, but larger-scale companies with disparate systems, including the System i, may find the ESB to be the key solution in preventing disjointed information silos throughout the enterprise. If your company is in the process of undertaking SOA or ready to adopt SOA in a more gradual manner, it is a good idea to have an ESB as a long-term strategy.

Implement a proof-of-concept (POC) before running with the bus. It is important to choose the POC to expose your existing infrastructure. Do not choose a POC that is extremely hard to explain and takes six months to undertake. Something tangible can be done within six to eight weeks.

Here are some key POC points to consider:

  • SOA standards—Make sure the ESB supports Web services created from RPG programs or prototypes created from service programs. Make sure that the Web service can be consumed by another disparate system or a user interface using a Web browser created from JSP or ASP. The underlying architecture uses the ESB as your middleware to communicate. Use your existing protocols. Do not test MQ if your enterprise does not currently support it.
  • Provider and consumer of service—Your RPG program must also be able to consume a service created from your other servers.
  • Variety of end-points—Connect to multiple service end-points (maybe one service to the System i and another to a System z or p). This allows you to process multiple business services within a single pipeline. This proves the ESB orchestration by taking part of business services based on rules and conditions as you exposed them. The mere fact that you can mix and match any of these business services proves the VETO (Validate, Enrich, Transform, Operate) pattern. The VETO pattern ensures that consistent data is routed throughout your ESB.

Having these proof points might be sufficient to initially jumpstart your POC. Evaluate the multiple vendors that I listed earlier. Make sure the vendor ESB has integrated with a System i and other systems in your enterprise. Your POC must be well-scripted. Compare apples to apples when scoring your POC. Some vendors will add functionality to juice up their showcase. Do not bite on the bait. I recommend developing a scorecard and listing all the proof points, showing different evaluators (business users, software implementers, and ITG). Include on the scorecard the POC lifecycle: implementation, design, development, testing, deployment, and execution. You may add monitoring and management if you have time. The last but probably most important piece of the POC is this: Do not let the vendor drive the POC. Don't let the vendor create this on its site and come back with a finished component. Have the vendors come in and illustrate their ESBs. The vendors are not going to create your WSDL for you, so come prepared with all the Web services already created in your systems.

If you are ready to take on the bus, follow the simple rules I have illustrated. Don't fall into the trap of a vendor's opinion on how the ESB process should work. Match your real-world needs and processes to the vendor's ESB. Always remember that the initial role of an ESB is to leverage your existing application.

Alex Nubla works as the Enterprise Architect for Health Net. He used to write technical articles for Powerbuilder magazine, Midrange Computing magazine, and iSeries News magazine (even way back in News 3/x days). Alex lives in Southern California now, after relocating from Charlotte, North Carolina, where he worked for Bank of America as the V.P. in charge of technical support for System i. 

Alex Nubla
Alex Nubla is a subject matter expert specializing in Service-Oriented Architecture (SOA). He has served in a variety of technical and business roles across a broad range of industries, including banking, finance, supply chain, and healthcare to name a few. Alex' current post is as a SOA Strategic Lead and a Director for Health Net Inc.  Email. alex.x.nubla@healthnet.com.
BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

RESOURCE CENTER

  • WHITE PAPERS

  • WEBCAST

  • TRIAL SOFTWARE

  • White Paper: Node.js for Enterprise IBM i Modernization

    SB Profound WP 5539

    If your business is thinking about modernizing your legacy IBM i (also known as AS/400 or iSeries) applications, you will want to read this white paper first!

    Download this paper and learn how Node.js can ensure that you:
    - Modernize on-time and budget - no more lengthy, costly, disruptive app rewrites!
    - Retain your IBM i systems of record
    - Find and hire new development talent
    - Integrate new Node.js applications with your existing RPG, Java, .Net, and PHP apps
    - Extend your IBM i capabilties to include Watson API, Cloud, and Internet of Things


    Read Node.js for Enterprise IBM i Modernization Now!

     

  • Profound Logic Solution Guide

    SB Profound WP 5539More than ever, there is a demand for IT to deliver innovation.
    Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects.
    The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the companyare not aligned with the current IT environment.

    Get your copy of this important guide today!

     

  • 2022 IBM i Marketplace Survey Results

    Fortra2022 marks the eighth edition of the IBM i Marketplace Survey Results. Each year, Fortra captures data on how businesses use the IBM i platform and the IT and cybersecurity initiatives it supports.

    Over the years, this survey has become a true industry benchmark, revealing to readers the trends that are shaping and driving the market and providing insight into what the future may bring for this technology.

  • Brunswick bowls a perfect 300 with LANSA!

    FortraBrunswick is the leader in bowling products, services, and industry expertise for the development and renovation of new and existing bowling centers and mixed-use recreation facilities across the entertainment industry. However, the lifeblood of Brunswick’s capital equipment business was running on a 15-year-old software application written in Visual Basic 6 (VB6) with a SQL Server back-end. The application was at the end of its life and needed to be replaced.
    With the help of Visual LANSA, they found an easy-to-use, long-term platform that enabled their team to collaborate, innovate, and integrate with existing systems and databases within a single platform.
    Read the case study to learn how they achieved success and increased the speed of development by 30% with Visual LANSA.

     

  • Progressive Web Apps: Create a Universal Experience Across All Devices

    LANSAProgressive Web Apps allow you to reach anyone, anywhere, and on any device with a single unified codebase. This means that your applications—regardless of browser, device, or platform—instantly become more reliable and consistent. They are the present and future of application development, and more and more businesses are catching on.
    Download this whitepaper and learn:

    • How PWAs support fast application development and streamline DevOps
    • How to give your business a competitive edge using PWAs
    • What makes progressive web apps so versatile, both online and offline

     

     

  • The Power of Coding in a Low-Code Solution

    LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed.
    Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

    • Discover the benefits of Low-code's quick application creation
    • Understand the differences in model-based and language-based Low-Code platforms
    • Explore the strengths of LANSA's Low-Code Solution to Low-Code’s biggest drawbacks

     

     

  • Why Migrate When You Can Modernize?

    LANSABusiness users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
    In this white paper, you’ll learn how to think of these issues as opportunities rather than problems. We’ll explore motivations to migrate or modernize, their risks and considerations you should be aware of before embarking on a (migration or modernization) project.
    Lastly, we’ll discuss how modernizing IBM i applications with optimized business workflows, integration with other technologies and new mobile and web user interfaces will enable IT – and the business – to experience time-added value and much more.

     

  • UPDATED: Developer Kit: Making a Business Case for Modernization and Beyond

    Profound Logic Software, Inc.Having trouble getting management approval for modernization projects? The problem may be you're not speaking enough "business" to them.

    This Developer Kit provides you study-backed data and a ready-to-use business case template to help get your very next development project approved!

  • What to Do When Your AS/400 Talent Retires

    FortraIT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators is small.

    This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:

    • Why IBM i skills depletion is a top concern
    • How leading organizations are coping
    • Where automation will make the biggest impact

     

  • Node.js on IBM i Webinar Series Pt. 2: Setting Up Your Development Tools

    Profound Logic Software, Inc.Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. In Part 2, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Attend this webinar to learn:

    • Different tools to develop Node.js applications on IBM i
    • Debugging Node.js
    • The basics of Git and tools to help those new to it
    • Using NodeRun.com as a pre-built development environment

     

     

  • Expert Tips for IBM i Security: Beyond the Basics

    SB PowerTech WC GenericIn this session, IBM i security expert Robin Tatam provides a quick recap of IBM i security basics and guides you through some advanced cybersecurity techniques that can help you take data protection to the next level. Robin will cover:

    • Reducing the risk posed by special authorities
    • Establishing object-level security
    • Overseeing user actions and data access

    Don't miss this chance to take your knowledge of IBM i security beyond the basics.

     

     

  • 5 IBM i Security Quick Wins

    SB PowerTech WC GenericIn today’s threat landscape, upper management is laser-focused on cybersecurity. You need to make progress in securing your systems—and make it fast.
    There’s no shortage of actions you could take, but what tactics will actually deliver the results you need? And how can you find a security strategy that fits your budget and time constraints?
    Join top IBM i security expert Robin Tatam as he outlines the five fastest and most impactful changes you can make to strengthen IBM i security this year.
    Your system didn’t become unsecure overnight and you won’t be able to turn it around overnight either. But quick wins are possible with IBM i security, and Robin Tatam will show you how to achieve them.

  • Security Bulletin: Malware Infection Discovered on IBM i Server!

    SB PowerTech WC GenericMalicious programs can bring entire businesses to their knees—and IBM i shops are not immune. It’s critical to grasp the true impact malware can have on IBM i and the network that connects to it. Attend this webinar to gain a thorough understanding of the relationships between:

    • Viruses, native objects, and the integrated file system (IFS)
    • Power Systems and Windows-based viruses and malware
    • PC-based anti-virus scanning versus native IBM i scanning

    There are a number of ways you can minimize your exposure to viruses. IBM i security expert Sandi Moore explains the facts, including how to ensure you're fully protected and compliant with regulations such as PCI.

     

     

  • Encryption on IBM i Simplified

    SB PowerTech WC GenericDB2 Field Procedures (FieldProcs) were introduced in IBM i 7.1 and have greatly simplified encryption, often without requiring any application changes. Now you can quickly encrypt sensitive data on the IBM i including PII, PCI, PHI data in your physical files and tables.
    Watch this webinar to learn how you can quickly implement encryption on the IBM i. During the webinar, security expert Robin Tatam will show you how to:

    • Use Field Procedures to automate encryption and decryption
    • Restrict and mask field level access by user or group
    • Meet compliance requirements with effective key management and audit trails

     

  • Lessons Learned from IBM i Cyber Attacks

    SB PowerTech WC GenericDespite the many options IBM has provided to protect your systems and data, many organizations still struggle to apply appropriate security controls.
    In this webinar, you'll get insight into how the criminals accessed these systems, the fallout from these attacks, and how the incidents could have been avoided by following security best practices.

    • Learn which security gaps cyber criminals love most
    • Find out how other IBM i organizations have fallen victim
    • Get the details on policies and processes you can implement to protect your organization, even when staff works from home

    You will learn the steps you can take to avoid the mistakes made in these examples, as well as other inadequate and misconfigured settings that put businesses at risk.

     

     

  • The Power of Coding in a Low-Code Solution

    SB PowerTech WC GenericWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed.
    Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

    • Discover the benefits of Low-code's quick application creation
    • Understand the differences in model-based and language-based Low-Code platforms
    • Explore the strengths of LANSA's Low-Code Solution to Low-Code’s biggest drawbacks

     

     

  • Node Webinar Series Pt. 1: The World of Node.js on IBM i

    SB Profound WC GenericHave you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.
    Part 1 will teach you what Node.js is, why it's a great option for IBM i shops, and how to take advantage of the ecosystem surrounding Node.
    In addition to background information, our Director of Product Development Scott Klement will demonstrate applications that take advantage of the Node Package Manager (npm).
    Watch Now.

  • The Biggest Mistakes in IBM i Security

    SB Profound WC Generic The Biggest Mistakes in IBM i Security
    Here’s the harsh reality: cybersecurity pros have to get their jobs right every single day, while an attacker only has to succeed once to do incredible damage.
    Whether that’s thousands of exposed records, millions of dollars in fines and legal fees, or diminished share value, it’s easy to judge organizations that fall victim. IBM i enjoys an enviable reputation for security, but no system is impervious to mistakes.
    Join this webinar to learn about the biggest errors made when securing a Power Systems server.
    This knowledge is critical for ensuring integrity of your application data and preventing you from becoming the next Equifax. It’s also essential for complying with all formal regulations, including SOX, PCI, GDPR, and HIPAA
    Watch Now.

  • Comply in 5! Well, actually UNDER 5 minutes!!

    SB CYBRA PPL 5382

    TRY the one package that solves all your document design and printing challenges on all your platforms.

    Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product.

    Request your trial now!

  • Backup and Recovery on IBM i: Your Strategy for the Unexpected

    FortraRobot automates the routine tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
    - Simplified backup procedures
    - Easy data encryption
    - Save media management
    - Guided restoration
    - Seamless product integration
    Make sure your data survives when catastrophe hits. Try the Robot Backup and Recovery Solution FREE for 30 days.

  • Manage IBM i Messages by Exception with Robot

    SB HelpSystems SC 5413Managing messages on your IBM i can be more than a full-time job if you have to do it manually. How can you be sure you won’t miss important system events?
    Automate your message center with the Robot Message Management Solution. Key features include:
    - Automated message management
    - Tailored notifications and automatic escalation
    - System-wide control of your IBM i partitions
    - Two-way system notifications from your mobile device
    - Seamless product integration
    Try the Robot Message Management Solution FREE for 30 days.

  • Easiest Way to Save Money? Stop Printing IBM i Reports

    FortraRobot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing.
    Manage your reports with the Robot Report Management Solution. Key features include:

    - Automated report distribution
    - View online without delay
    - Browser interface to make notes
    - Custom retention capabilities
    - Seamless product integration
    Rerun another report? Never again. Try the Robot Report Management Solution FREE for 30 days.

  • Hassle-Free IBM i Operations around the Clock

    SB HelpSystems SC 5413For over 30 years, Robot has been a leader in systems management for IBM i.
    Manage your job schedule with the Robot Job Scheduling Solution. Key features include:
    - Automated batch, interactive, and cross-platform scheduling
    - Event-driven dependency processing
    - Centralized monitoring and reporting
    - Audit log and ready-to-use reports
    - Seamless product integration
    Scale your software, not your staff. Try the Robot Job Scheduling Solution FREE for 30 days.