Posts tagged XML
Ditch mainframe-style costs and complexity — gain new levels of flexibility and control

Why continue to do “business as usual” using unsecured FTP sites or an expensive monolithic system to connect remote store locations to your corporate systems, when you can have mainframe-style benefits without the administration and governance headaches?

You can mitigate risks, improve agility, and derive more value from your existing IT assets with a single solution for managed file transfer (MFT). By moving from point-to-point connections and integrations to a unified platform, you can:

  • Eliminate processing latency by automating business processes and file transfers — including EDI — in a stable, secure, and easy-to-manage environment.
  • ƒCentralize IT support with a single dashboard for all facets of administration, configuration, monitoring and analysis of file-transfer activities and applications.
  • Manage business protocols, file transfer protocols, messaging, encryption policies and web services — all in one place.
  • ƒUse naming conventions that dramatically reduce customization workloads when implementing new data flows, including non-standard data types and ad hoc file transfers (including email with unstructured file attachments).
  • ƒStreamline integration with all remote operations. Axway’s integration products support industry standards (such as AS2) by processing data from any source in any format — including all variants of XML and EDI.

The right integration products will enable you to send data on to recipient applications (order processing, invoicing/collections, warehousing and inventory management, for example) with the data structure and transport mode they require, and the precision timing they expect.

Learn more here.

 

 

Times Up! — Deciding What to Do As Standard Maintenance Ends with DataPower

We’re now at the end of standard maintenance on several DataPower SOA appliances. And that probably means most companies who haven’t yet upgraded are buying extended support, because you don’t just replace appliances for important applications — you test and deploy over many months so that you don’t put the business at risk. If you’re in this situation, use the next 1-2 years wisely to rightsize DataPower, and break the vicious spending cycle.

When it comes to appliances, many companies buy excess capacity up front to support several years of growth. Often it’s because they don’t want to be forced to do an early upgrade or add-on purchase. Most are convinced they will use the extra capacity for other projects. And this is the vicious cycle. Companies end up putting applications on DataPower that just don’t belong there. DataPower is great as an XSLT acceleration engine, but that’s mostly it, and that “data power” comes at a big cost. Don’t keep loading up DataPower. Start to evaluate which applications don’t belong there, and start to implement your rightsizing program now. Then, buy the right size of DataPower for what’s left.

Reevaluate all new projects and see what can be moved to another platform before you put it on DataPower. Any integration across a firewall or across divisions can probably be done using an API gateway. The right API gateway will have native wire-speed integration with DataPower that makes it easy to add it to a DataPower deployment, migrate workloads, or add functionality to other deployments.

Finally, build out your roadmap for migrating existing functionality that can or should be run on other platforms, either during release cycles for the applications or as part of a larger initiative. Some of the more common reasons for moving to an API gateway are:

  • A move to virtualization or an outsourcing strategy. DataPower isn’t designed to run on a third-party virtualized infrastructure such as VMware or Amazon AWS.
  • A need to support cloud and mobility. DataPower supports XML. It’s not good at supporting the new world of JSON and REST.
  • Productivity. DataPower requires developers to code in XSLT. A modern API gateway is a highly graphical environment, where developers configure, not code.
  • Native support for Java or JavaScript. DataPower doesn’t support either.
  • Antivirus protection and security concerns. DataPower requires an ICAP connection to add anti-virus protection, which adds an extra network “hop” and a delayed response. The right API gateway supports antivirus in-process and a host of security measures for hardening access from outside the firewall.
  • Identity bridging. DataPower does not directly support bridging OAuth, Oracle Identity Management, CA SiteMinder, or even Tivoli as well as a quality API gateway that delivers federated identity management and single sign-on (SSO) across the old and new channels.

So build your roadmap now. Start by identifying the strengths and weaknesses of DataPower and evaluate each application it supports. Get advice from others who have used API gateways with DataPower. Use some of the money that had once been earmarked for extended support — and extra capacity — to work on new projects that make a difference to the business.