Hello and thank you to everyone who watched our webinar. We had a lot of really good questions in the session - far too many to get through in the time we had. We've collated all of the questions into one thread and with the help of the labs, we are able to post the answers here. Let us know if you have any further questions.
Q) Can you even make use of the different colors when you encapsulate the Nodes within subflows to configure default values or error handling?
This question was raised during the meeting, so we may have lost a little context ... but let's make an educated guess :) As discussed in the meeting, ACE 12 provides a much improved flow development experience with new tutorials, reshaped and rebranded nodes, and a new palette search facility. These enhancements apply to nodes in message flows and subflows. The message flow node palette splits nodes between "Connectors" (defining flow interactions with external apps and services) and "Toolbox" (actions executed within the flow such as routing or transformation) - and uses colours in the Toolbox to help classify the nodes and make them easier to find.
Q) ACE 12 still doesn't support OAS3.0 for API hosting. This is now standard all your competitors ESBs. What the roadmap for OAS3.0/OAuth?
Q) Record & Replay functionality in ACE 12 still requires dependency of MQ Server deploying on same server as ACE?
As you may be aware, it has been our long term strategic intention to make it easier to independently configure and scale MQ queue managers and ACE integration servers. With this in mind, where possible we have defined ACE to use MQ client connections when communicating with a queue manager. This statement applies for all kinds of reasons - not just MQ message flow nodes in flows. For example, since ACEv11.0.0.7 we have provided a remote default queue manager option in the server.conf.yaml to make it easier to use a remote queue manager when operating ACE in containers. This applies to many situations such as the collector, timer and sequence nodes but does not yet cover Replay. Given this, we are keen to allow Record and Replay (specifically the Replay part!) to enable the use of a remote queue manager using a client connection. This remains a future enhancement suggestion which we hope to add to our near term roadmap.
Q) What is the main drive for releasing a major version (V12) and not incorporate the changes into V11. We took in lot of pain to move from IIB to ACE V11 FP12 and another migration would mean lot of testing , performance bench marking and so on?
We understand that adoption of major new releases of software can be expensive for customers. For this reason, we have tried to separate these major releases to be every 2-3 years rather than the more historically typical 1-2 years. At the same time since IIBv10 in 2015 we have adopted an agile development methodology with quarterly fix pack releases containing new functions but on the same existing major engineering release. This strategy has been warmly received by the majority of our users. ACE v12 provides some major advantages which warrant the use of a major version bump - for example, the unit testing framework and REST API enhancements. It should also be noted that with each release we aim to reduce the migration effort required - ACEv12 and ACEv11 are architecturally much more closely aligned than IIBv10 and ACEv11. In the case of moving to v12 we also firmly believe that the unit testing enhancements will provide a strong reason from a ROI point of view which justify users upgrading their estate.
Q) What has changed in the runtime component between ACE v11 & V12?
ACEv11 and ACEv12 are architecturally very similar to one another, so whilst there have been many valuable features added, the main product externals such as the server.conf.yaml file have remained the same. For administrators of the product, the biggest change in v12 is the introduction of the ibmint command which will help when building CI/CD pipelines (more on this topic below). For developers of the product, the biggest changes in v12 are the new unit testing framework (and the associated new message assembly editor available in the Toolkit) and REST API enhancements. To help first time users of the product, there have also been big improvements in the branding of the Toolkit development experience and the built-in product tutorials gallery (which now has over 100 examples).
Q) Will the newly created functionalities (like JSON validator) be available for V11 in the coming fix packs?
IBM is always open to enhancement requests, but it is unlikely that this example will be back-ported to ACEv11.
Q) Whats the best way of upgrading from v11 to v12?
Like all successful migrations, we recommend you begin by evaluating the new product features and how they will impact you. The product documentation is a great first place to start for this task.
In terms of the method of upgrade, both ACEv11 and ACEv12 provide a command named "mqsiextractcomponents" which operates on a zipped backup of an existing integration node, and lets you create a new integration node, or allows selective extraction of one or more integration servers. This is a great way of preserving any environment configurations you may have created for the previous version of the product, and also a great way of starting to break up large integration nodes into separate containerised independent integration servers if you are considering such a wider architectural change. On this topic, we also have the built in Transformation Advisor capabilities which help suggest changes you might want to make to your flows as you begin adopting containers.
Of course, there may be wider higher level aspects to your question such as moving to a cloud provider, changing your operating system platform, or building a new DevOps pipeline ... all of which are possible, but probably best left for a deeper conversation!
Q) Can the policies be edited/updated from GUI ?
The ACEv11 and ACEv12 Toolkit both provide an editor for creating and updating policies. Policies are defined in policy projects, which can then be deployed to the runtime in a BAR file, or if you prefer they can be copied to an overrides directory directly on the runtime file system where they will be used in preference to anything deployed through the BAR file mechanism. Most policy types can also be redeployed without requiring the restart of an integration server.
Q) is all fix version of v10 is going out of support in April 2022 or will it be just the base version?
When IBM announced end of support for a major engineering release, it applies regardless of the fix pack version which you may currently have installed... so yes, all fix versions will end their standard support in April 2022.
Q) From a System Administrator (System Programmer) view, which are the main differences between IBM ACE Version 11.0.0.13 and IBM ACE Version 12 ? (Memory management, CPU requirements, WebUI, etc.)
ACEv11.0.0.13 and ACEv12.0.1.0 are very similar in these regards - both product versions utilise the same level of administrative API (which underpins communications by our commands, Toolkit and Web UI) so it is unlikely system administrators will perceive any large changes in this area. From a performance point of view, IBM has not yet published public performance reports for ACEv12.0.1.0 but the performance profile of the two vehicles referred to will be very similar. One very small change, which is highlighted on migration relates to the encryption algorithm used for identities defined using the mqsiwebuseradmin command.
Q) What is you still have independent resources migrated from MessageBroker v7 running on IIB v10?
Independent resources (defined inside integration projects) can still be compiled into a BAR file and deployed on IIBv10, ACEv11 and ACEv12. However, IBM would prefer all users to adopt Applications/Integration Services/REST APIs/Libraries/Shared Libraries instead of Integration Projects. These "newer" resource types have actually been available with the product for over 10 years now and provide the user several advantages in being able to isolate deployed artifacts from one another when deployed to an integration server. In both ACEv11 and ACEv12, if you deploy a BAR file containing independent resources, then these contents are place in the "default application" part of the integration server. This change has helped us keep our administrative actions consistent across resource types, whilst also preserving support for these older artifact types to help provide our users the time they need in order to prioritise the upgrade to resource types referred to above.
Q) Where can we get the latest version of ACE for POC's?
You can download the latest Developer Edition of the ACE product from here:
This version limits its message flows to perform no faster than 1 message / second, but provides the full product functionality for assessment. If your POC also centres on performance then please contact your IBM representative and we'll be happy to assist with an alternative installation mechanism.
Q) Can I download ACE 12 ?
Yes, entitled users can download ACE 12.0.1.0 from fix pack central. You can also download the developer edition of the product (for evaluation purposes) from a public web page (see above). Downloading is straightforward, and only needs you to choose Linux, MacOS, or Windows as your target platform, provide some details about your interest, and agree to the license. To download now, click Download.
Q) Is there any update to the DFDL Parser to the latest DFDL Standard ?
There are no major DFDL changes to report between ACE 11.0.0.13 and ACE 12.0.1.0 If there are specific DFDL enhancements you have in mind then as ever, IBM would love to hear about your suggestions through the standard enhancement process!
Q) Is Java CMP API depreciated in v12 ? If yes, then what has been provided to access runtime components?
As you may be aware, the Java CMP API refers to the "Configuration Manager Proxy" API of the product, which was a hangover from very old versions of the product which contained a "configuration manager" component. This API is not part of ACE11 nor is it part of ACE12, however, many of the API's capabilities have been carried forward with these later product versions. Both ACE11 and ACE12 provide a publically documented (in conformation to OpenAPI v3) REST API. This administrative REST API can be utilised remotely over HTTP (or HTTP/S) or locally using a Unix Domain Socket / Windows Named Pipes connection. The same administrative API is also accessible from Java clients, so any external java program which previously used the CMP API should be updated to use the new REST Admin API. You may be interested that ACE provides a built-in product tutorial named "Using the Java IBM Integration API - Strategic classes" (in a Toolkit go to Help menu > Tutorials Gallery) which describes how to use the com.ibm.integration.admin.proxy.* classes in a Java application to discover details about what's deployed to an integration server.
Q) What will replace the deprecated Java API?
Please see the answer above.
Q) Anything changes on User Defined nodes?
User Defined nodes (Java, C and subflow variants) have been carried forward as a feature from earlier ACE versions, and they have not changed architecturally between ACE 11 and ACE 12. There were a few smaller changes made compared to earlier product versions in the area of classloading. Please let IBM know through the usual channels if you are struggling with anything in this area.
Q) What do you mean by MQ Decoupling? Can you explain a little more
Historically versions of the software product prior to IIBv10 had a hard dependency on the definition of a local queue manager to support an integration node. IIBv10 softened this stance making a queue manager optional for some use cases. Furthermore, with ACEv11 many of our users have adopted (or are moving towards) container based architectures where there are benefits to being able to independently scale MQ and ACE by hosting queue managers and integration servers inside separate containers. Over time therefore, it has been our product strategy to analyse all usage of MQ by ACE and where possible enable the use of client connections to a remote queue manager - eg the event-driven architecture nodes used to require a local MQ server but now this can be completed with remote MQ connectivity.
If you're interested in learning more about how ACE and MQ can be deployed, managed, scaled and upgraded in isolation with reducing cross-dependencies then take a look at the IBM RedBook '
Q) IF we are using HTTP Request nodes are these going to have to change going from v10 to v11?
The HTTPRequest node implementation is very much equivalent between IIBv10 and ACEv11 (unlike the architectural changes for the HTTPInput node and HTTP Listeners which did change between those specific releases). Looking further forward to v12, it should be noted that the HTTPConnector and HTTPSConnector polices were deprecated in 11.0.0.5 and have now been removed entirely in 12.0.1.0. The resource manager settings should be used instead. Existing HTTPConnector and HTTPSConnector policies will not be loaded and cannot be extracted using mqsiextractcomponents.
Q) Does the test automation require an external database?
The new unit testing framework has no dependency on an external database and does not introduce a need for any new product pre-requisites. Of course, amongst many other things you can also use the new framework to mock external dependencies of message flows, of which databases are one example.
Q) Are there any plans to introduce Salesforce B2C Commerce connector in IBM ACE v12 toolkit for on-prem build and deploy?
We are always interested in adding to the range of connectors available in the ACE Toolkit. We have specific roadmap plans to extend the connector range from the Designer authoring tool into the ACE Toolkit in future. If you're interested in learning more about these aspects we recommend joining the App Connect Early Experience Program where confidential information can be shared under the required NDA.
Q) Can you deploy ACE 12 to Rancher?
You can deploy ACEv12 as a container runtime using the independent integration server. The container can be deployed by a container management system i.e. Rancher
Q) Is there now a new command to build a bar file from an ACE project which also applies an override file?
Q) We run ACE 11.0.0.10-r3 (CP4I on Openshift on Azure) in production and have noticed that for most message flows, the integration server pod needs atleast 500m CPU to startup while the actual usage thereafter is less than 50m, this leads to wastage and high licensing costs, is this something you are planning to fix/look at in the near future?
We are always interested in the CPU usage of the product in all its variants (both containers and on-premises). Relating to the specific example in your question, we are particularly interested in the comparison of CPU allocation in containers relating to requirements for fast container start-time compared to "steady state" operations once the container is up and running. Whilst no guarantees can be made on specific timelines, this topic is regularly discussed in our Early Experience Program and remains on our radar for future development.
Q) In an ACE roadmap call some months ago we were told you were on to developing a smaller docker image for ACE which runs based on the type of message flow project therefore having a lower footprint and faster containers, is this coming anytime soon?
We are always interested in making the ACE container image smaller for users who are challenged by its current size. As you referred to, there is public collateral which demonstrates some of our ideas in this area, which is available in the following github repo:
We continue to work on this, and over time you are likely to see greater componentization of the ACE runtime, and more flexibility in building images of varying size and function.
Q) What type of connectors can be injected? Do you have any examples?
We believe this question related to the topic of unit testing. The logical message tree structure which passes between message flow nodes in a flow can be recorded regardless of the original transport over which it was sent to the flow ... in this sense regardless of the "connector" or "input node", unit testing can be used to record data and the unit testing framework can then be used to test those flows. Given this, one of the important use cases of unit testing is the ability to test message flows in development environments where you may not have access to the actual endpoint systems.
Q) Is there a published checklist for clients looking to upgrade to V12?
Q) I'm also interested in ibmint cmd. Can I use it instead of previous "generation" of cmd?
Long term, it is our strategic intention to add more and more capability to the "ibmint" command which we believe to be more user-friendly given its "verb first" approach than some of the product's older mqsi* commands. However, currently we have focussed the ibmint commands on specific pipeline tasks, so for now the new command should not be considered as a "like for like" replacement. The new command has several advantages, such as not requiring eclipse to run in headless mode for tasks like BAR creation and message set compilation ... and the ability to chain together multiple build tasks such as packaging and overriding ... and if you prefer, the avoidance of a BAR file by going direct from a "source" version control system to a "server" runtime directory. More details on the command are available here: https://www.ibm.com/docs/en/app-connect/12.0?topic=commands-ibmint
For existing users, note that ACE 12 still contains the full set of ACE11 commands, which will remain part of the product for the entirety of ACE12 and most likely beyond as well ... so there is no need to migrate any existing scripts which you may have developed.
Q) Hi ACE v12 will support ITX ? if so which version it will support
Whilst no guarantees can be made about future versions and capabilities, it is highly likely that a supported combination will come along in a similar timeframe to previous new major engineering releases.
Q) Could you provide that list of links from the 2nd to last slide in the resource list?
Q) I'm using the iSeries integration custom node and I was wondering that since it works in ACE 11 if it can be also used in ACE 12?
ACE 11 and ACE 12 are very similar to one another in regard to user defined nodes, so it is highly likely that these nodes will work in exactly the same way. That said, if you raise an issue against the github repo where these nodes are now maintained, then we will be able to provide a more formal response: https://github.com/ot4i/ace-iseries ------------------------------
Aiden Gallagher
------------------------------
Original Message:
Sent: Tue July 06, 2021 02:50 PM
From: Jess Leitsch
Subject: IBM App Connect Enterprise V.12 – What's new & Why should I care?
This session will provide an overview of App Connect Enterprise V.12, the latest evolution of IBM's Integration technology.
We will discuss the value that ACE can provide to your business, also focusing on the benefits that existing customers to gain from upgrading.
Please join @Aiden Gallagher and @Ulas Cubuk in this on demand webinar.
Share any of your questions below and register to watch here.
Thanks,
------------------------------
Jess Leitsch
IBM Community Manager
------------------------------