All,
Good questions, and let me try to add some clarification, because believe me, I know it is somewhat confusing right now. And I know I'll be repeating myself from my earlier post in places, but trying to provide a complete answer.
First, @hirschel, as was stated, the App Connect Designer is not a replacement for the App Connect Toolkit. The App Connect Toolkit, as was stated, is the successor to the IIB Developer Toolkit. It is the Eclipse-based full blown development toolkit that allows you to build powerful and if needed complex integration applications, services, and APIs. The Toolkit still includes built-in adapters for SAP, Peoplesoft, JD Edwards, and Siebel.
The Designer is strictly used today on our App Connect Professional on Cloud offering. This is where we have 100+ intelligent SaaS and cloud CONNECTORs. There are connectors for Salesforce and the various Salesforce offerings, ServiceNow, Marketo, etc., etc. A very long and growing list of connectors. There are also a growing list of "technology" connectors there, such as an HTTP connector, allowing you to make HTTP or REST calls anywhere REST can be used but we do not yet offer a specialized connector. There is also an SFTP connector, for example, as well as one for IBM MessageHub (our cloud based messaging offering built on Kafka). Our specialized connectors, as I mention, are intelligent. They handle all of the security, connection handling, and common error handling -- meaning the developer does not have to code for any of this. Literally you give the connector your userid/password, and select what type of action, for example a "Create" or "Update", etc., and Designer does the rest.
So Designer can be really used by two groups of people. The Citizen Integrator, that both I and @Jeff mentioned -- this is most likely a person that does not do integration development for a job -- they are likely embedded in a line of business, and have some basic integration needs. For example, a person working in the marketing department, and wants to do something related to a planned new marketing campaign. Maybe they use Marketo and MailChimp. And maybe this person has their own Google Sheets spreadsheet where the person has been collecting and organizing information for the campaign. So maybe now this person needs to integrate between all three of these applications, pulling information from one and driving it into the other two, with some minor mapping requirements in between. Designer is created and in fact designed to allow this non integration specialist to perform this integration themselves -- without having to ask the central IT department to get involved (which face it, for something like this may never happen). So again, allowing the "Citizen Integrator" to completely do their own integration work when it makes sense, and where the integration solution is probably not something that affects the entire enterprise, but a department. Designer is quite capable today, with support for some looping, IF-THEN logic, and the ability to do things like just invoke a JSON parser when needed. Its capabilities continue to grow.
Additionally, Designer can be used in COMBINATION with the ACE Toolkit, when you need to build a truly hybrid integration solution, involving on premise systems and SaaS/cloud based systems. For example, let's say you want to integrate between Salesforce in the cloud and SAP on premise. A true integration specialist, in this case, may want to use both tools. They could design a solution such that they start with a flow in the Designer. This flow starts with the Salesforce connector to pull the right data from Salesforce, based upon the trigger -- for example, each time a new Contact is added in Salesforce, this Designer based flow executes. The flow receives the new contact object. Then the flow might invoke a Callable Flow. This Callable Flow is built in the ACE Toolkit, and it then receives this contact object and does some mapping and then updates SAP with the information. The Callable Flow might do other things, if necessary, and might then return to the Designer flow with some additional information out of SAP. Now the Designer flow gets this information back from the Callable Flow, and uses the Salesforce connector again to update that specific contact record with the additional information from SAP. Once created, the Callable Flow can be discovered in the Designer making this very easy to build. So in this scenario, the integration developer might build all this himself. Using each tool to do what it does best!
However, that same Callable Flow, now offers advantages. It is a self-contained specialized flow, that does some work in SAP, and which is built by the integration team. So the integration team can control access to SAP in this way, but still allow this Callable Flow now to be used by the Citizen Integrator! Obviously, Citizen Integrators will sometimes need access to data that lives in the back end on premise systems of record. This is a powerful way to provide them that access. The Citizen Integrator needs to know nothing about the backend system, does NOT need their own access, and in fact, you probably do not want them having their own direct access to the backend -- again for security and control reasons. SO using Callable Flows, built in the ACE Toolkit, controlled by the central IT integration team, can then be used by Citizen Integrators to build that "last mile" of the integration, where you are finally connecting a SaaS solution together with that backend system.
So as far as the Designer goes, as you can see it has multiple uses and multiple users that can benefit from it.
And just to address the last tool that is still there, the App Connect Studio. This is the old Cast Iron Studio. It is still there and used to build mediations that run specifically and ONLY on the App Connect Professional (Cast Iron) runtime. So what are we doing with these various runtimes? Where are we going?
First, let me encourage everyone to listen to the recordings of the two part IBM Middleware User Community session that covered App Connect Enterprise, done by Amy McCormick in Offering Management and Ben Thompson, the Lead Architect for ACE/IIB.
So there are three integration runtimes out there (not including API Connect in the mix, because it is a separate tool used with any of these three integration runtimes to add the critical API management layer to an overall integration infrastructure):
- the App Connect Professional (Cast Iron) runtime -- used on premise and included with a license of App Connect Enterprise, with the Studio for development -- or this can be deployed to a cloud
- the App Connect Enterprise runtime -- this is the runtime we used to call IBM Integration Bus (more on this below), and uses the ACE Toolkit for development -- you can run this in premise, on any cloud, or use the App Connect Enterprise on Cloud service
- the App Connect Professional on Cloud runtime, which uses Designer for development
So again, with so many things named "App Connect", I understand the confusion. So again, let's clarify.
The old Cast Iron runtime, or its new name of App Connect Professional, is provided as an OVA file, so you can deploy this runtime on premise, or as mentioned, you could run this in an image on cloud. IBM offers an option to run this in the IBM Cloud. The Cast Iron runtime is essentially stablized. We are taking the ideas from Cast Iron forward, into the Designer, but not the code. So anything built to run on this runtime, continues to run only on this runtime.
The App Connect Professional on Cloud runtime, or more commonly referred to as just Designer to keep it separate from the Studio based runtime described above, is only available on IBM Cloud today. App Connect Professional on Cloud is a separate IBM Cloud service that can be subscribed to, to offer the complete capabilities I mentioned earlier, where you could have Citizen Integrators completely building their own solutions.
There is also a App Connect Enterprise on Cloud service. When you open up this service, it looks just like the App Connect Professional on Cloud service, and uses the same interface. The additional capability here is you can deploy a BAR file (so this is the successor to the IIB on Cloud service). In the ACE on Cloud service, you have the Designer, allowing you to build and run anything flow you can in the Designer interface, as well as the ability to use the (desktop based) ACE Toolkit to create an integration solution and then push and deploy that BAR file to be executed on the ACE on Cloud service. So basically you get all our integration capabilities here, except Studio.
Last, if you have App Connect Enterprise on premise, you have the ACE runtime and ACE Toolkit to do your on premise work, you also get the App Connect Professional Studio and runtime OVA file (again, what was Cast Iron) if you have the desire to use it for simpler integration work, and finally, you get entitlement to a special plan to use the App Connect on Cloud service and Designer to build the hybrid types of integrations I described earlier. This plan gives you permission to use Designer to create flows that in one direction or another interact with your on premise ACE runtime. This might be a solution that starts in Designer with a connector, and then uses Callable Flows to push the data to ACE on premise. Or it might be a solution that starts in the ACE on premise runtime but then needs to use a connector that is only available on the App Connect Designer, so the ACE Toolkit offers both a node and a pattern to help you easily build this type of solution by making a "Call" to the Designer to use the connector. Or as in my earlier example, a Designer flow may need data from your on premise system and uses a Callable Flow to do that. So in other words, what this special plan does not allow or provide entitlement for, is building that self contained Designer flow that ONLY uses Designer capabilities. That would require separate entitlements.
Last, let me address the ACE runtime a little more specifically. So as you can see, first, the Cast Iron runtime is being left as is. Again, we are certainly taking the ideas from it and its Studio forward as we continue to build out more and more capabilities in the Designer. The Designer has its own purposes, and will probably never be the single integration development tool. If you look at the complete set of capabilities and the raw power a developer has in the ACE Toolkit, which has been build up over 18 plus years, it is unlikely that we ever try to do all of that in the web based Designer. Each tool has its own purpose, and for the most part, its own set of users. However, as mentioned, the Designer is growing quite quickly, getting more connectors and more capabilities all the time.
The ACE Toolkit and runtime continue to grow too, however. You do see, when I describe the ACE on Cloud service, a single runtime basically that can execute both a Designer flow or an ACE solution packaged of course in a BAR file. So what might happen with our on premise solution we will all have to see where Offering Management and labs take this. Today, the ACE v11 on premise runtime has had a lot of new engineering down to it. This is to make the v11 ACE runtime very lightweight, with a single process and a "unzip and go" capability. This is designed so that you can make easy use of containers for deployment, such as in Docker, and manage these containers with a tool such as Kubernetes. You can do this yourself, or use a powerful pre-built solution like IBM Cloud Private. Anyway, the ACE runtime is much smaller and compact, and again, can be deployed without a Node, meaning you can just deploy an Integration Server. The idea is that you can easily now "embed" the Integration Server right in your containers right along side the applications that need the integration capabilities. You can treat the container as a wholly self-contained module that you can start up as many as you need, and restart one whenever one fails. And of course use something like Kubernetes to manage those aspects for you. So this means you don't need to setup and worry about HA solutions, the container itself is a managed unit that you restart -- or rebuild when you have a new version of the application or of the ACE runtime. You don't maintain, you rebuild. This is commonly referred to as treating your tools as cattle instead of pets. You can read more about that in developerWorks too.
Hope this helps clear where we are right now.
Executive IBM Cloud Middleware Connectivity & Integration Solution Architect
Member of the IBM Academy of Technology
North American IBM MQ Appliance Technical Leader
Open Group Certified Distinguished IT Specialist
IBM Certified SOA Solution Designer
IBM Certified Specialist/Solutions Expert - WebSphere MQ V6/V7
IBM Certified System Administrator/Solution Designer - WebSphere Message Broker V6/V7/V8
IBM Certified Solution Designer/System Administrator - IBM Integration Bus V9.0&a