Introducing Red Hat Fuse 7

one thing I want to mention is that given the time limit we just did recently internally within Red Hat a training session that was like just an overview really of a few seven and it took us three days and so we're gonna do that in 45 minutes today so you can imagine that we're not going to do at the same level of detail I'm higher and I discussed this and we decided that it was better to paint the high level picture right and give everybody some context for what this releasing compasses and hit on a few things that we know people gonna ask about like fabric b1 migration and some of the key features we're not gonna obviously in this timeframe get into really hardcore detail I'm around the rest of the afternoon so when I get off the stage if you want to talk you have specific questions that aren't covered in the presentation I'm happy to answer them Hiram's it easy going guy I think you'll be around too right so all right let's get started okay so my name is Keith Abba I am the product manager for fuse I'm sure you know that's hi I'm Karina alright so I want to paint a little context here about what's driving this release alright and so I think it really helps you know before we get into features just understand kind of how the market the enterprise architecture market enterprise IT market itself is evolving and how integration is is being forced to evolve along with it so when we look at sort of the classic approaches the integration that have been around for 20 25 years probably longer we have the infamous point-to-point integration right so point-to-point is super fun because you get to do exactly what you need to connect to systems and that integration will never work with any other systems and anytime either those systems changes it breaks right but it is custom so a major challenge here that people encountered is hey how do we actually scale these things and evolve because we have all these teams now that are mild that are managing and maintaining all these snowflake integrations and that led to the invention of EA I and II SBS so that's more of a hub-and-spoke or bus architecture and the idea is that your integrations are no longer coupled to specific systems right but they are all coupled to a bus and what that produced a challenge that produced is that generally you have a single team owning that bus and that can become sort of a backlog right it can be a situation where everything you're doing every application you're develop developing is oriented around the ESB it has to go through the ESB team so it came a you know real especially recently a real point of friction in IT but still a very very valid architecture it just has some some challenges associated with it and then finally business b2b so whether this is EDI or file transfer or whatever the idea is you have two organizations that are separate and they're effectively doing point-to-point integration across organizational boundaries if you've ever done this type of thing before it's got all the nastiness of p2p but then you add on top of that the fact that you have to exchange PDF documents for data mapping and authentication details there's a ton of human involvement here these things are super easy to break they're very difficult to set up and they're like impossible to tear down and evolve so it's it's it's pretty nasty business so sort of as like an evolution from here we start to see some reaction to that probably we're like within the last maybe seven ish years and sort of a new wave of integration is coming out right and the first is more along this idea of ownership of your complete stack is you have people doing rails a half so they're writing some Python and they say hey I'm just interacting with an API right I'm just writing a file whatever and there's there's libraries and functions to do that so I'm just going to do it right and that definitely works right but what ends up happening there is they've got a little bit of code and it interacts with all these like a database and a file and PII and next thing you know you have more integration logic than business logic in your app and this becomes a problem because now you think you have this very small app but the surface area of that app and has all these tentacles that reach out to other systems that as soon as they change you have to change your app so it's almost like a like an entangled model if I like to call it another problem we see a lot is that as people move from their existing systems or brownfield systems to Greenfield systems they want everything to be pristine and nice like this is your opportunity to do it right you're writing this application for the first time right you don't want to mess it up like you did last time like that's how I feel anyway and so you're like okay we're gonna do this one right but when you do that none of your data or existing legacy systems come with you into that new architecture so you actually have this kind of shadow of brownfield over your nice pristine green field and so how are you gonna protect yourself from that and so then we've developed some strategies like you normally do a proxy or facade you wrap these old systems in a delegate basically through an API and then you just talk all API is in your internal architecture so the challenge there is being able to keep those pristine greenfield services but still maintain connectivity to the to the brownfield stuff micro services is all the rage everybody's new micro services or something they call micro services even in pure greenfield micro services you're talking about if you're doing domain driven design all these micro services have their own idea of data right they're not sharing they all so you have a customer or like let's say an order processing application and that application is a micro services based application and consists of 10 micro services well you likely have 10 different versions of order right because every individual micro services defines it a little bit differently so now you have data transformation as you traverse those bound accounted context right now you have connectivity to talk to all those brownfield systems outside you have intelligent routing to do maybe a single API gateway facade to a mobile client right so there even though you're doing micro services there's still a lot integration in there you got to consider that and then finally api's so next to micro services or the API revolution is is the big I don't say fad but kind of revolutionary thing going on right now and the idea that I think there's a there's a couple reasons for that one is that most people find micro-services to be very hard so instead of doing CQRS and change data capture and maybe event-driven type of contracts which are very hard to get right they start doing api's because everybody's comfortable and familiar with a basic call return paradigm right where you're passing documents around restful api is most most languages have very easy ways to interact with them there's standard definitions like swagger so we're seeing a lot of API development even in kind of micro service type of applications we're also seeing at a ton in replacing b2b so basically now instead of talking FTP or EDI companies are saying I'm not only going to use this for document exchange but it's actually gonna be my presence to my customers on the web basically right I'm gonna expose this API someone's gonna write a mobile app for me and now I'm actually starting to connect with my own consumers and realizing this vision of digital transformation right doing top-line growth through IT so finally the last thing I want to hit here is that it's a couple of trends that are sort of emerging right now that we're starting to see more and more so in the prior slide most people have done even micro service has done a bit of that or maybe modular monoliths but we look at sort of what's evolving just right on the cusp of what morgan most organizations are struggling with the first is automation so most organizations are exploring some form of automation now and they're focusing on applications first and those application teams are really liking the fact that they can maybe deploy on containers and have automation to actually have a smooth deployment pipeline all the way through to production or just shorter production but the integration comes not moving with them and so those teams now are being held back by the integration function and they're just ditching it right they're just saying okay well we're moving without you will write the integration logic inside our app sort of like I said on the prior slide so a key thing here is the ability to have integration logic that is also eligible for automation that can also be pushed through the same pipelines either with the itself or separately but fully automated the second aspect is cloud native deployment and what I mean by that a lot of people throw that term around what I mean by that is that when you're doing integration on a container platform that it's not just lift and shifting and running it on a JVM and it has no awareness of its environment it needs to be natively integrated with things like liveness and readiness probes it needs to be able to do secret and config map injection all the things that make that immutable architecture are great you actually have to have intelligence and the images that underlie your application to integrate with it okay and then finally huge trend we see is around this concept of self-service for developers that are just running like on a container platform so they don't want to install but they're still going to write code and they want to deploy on it but then we see it along users that don't want to write code so you have people that adopts a software like a Salesforce and that sweet workday and service now and this type of thing they get a taste for not having to deal with central IT anymore they can just buy software that's already installed already provisioned someone else manages it and they just get it work in a business level right these same users are realizing that when they adopt Salesforce there's data on-premise that they have to get to even if they're fully on the cloud and they're doing like Salesforce and NetSuite let's say Salesforce and NetSuite don't share data right they're their own data Lakes and so now they have an integration problem they're not going to go write code to solve that integration problem they left that problem behind right they're not gonna go to central IT to solve that problem either they want to use more of an iPads type solution to do it so now a question you know I've gone through all these details and and the real question is like which one of these apply to you and if you're like most organizations it's all of them right it's like you know you have some app running in a broom closet somewhere right that's doing p2p stuff that everybody's afraid to touch and then you have some teams that are on the absolute leading edge like investigating iPad solutions maybe looking to acquire you know and kick the tires with the POC with an iPad solution and so you run the entire gamut what you need how organizations will have to cope with this is they can't do this individually they have to have a plan and a strategy to deal with all this complexity and to move in the right direction red hats the pain aided approach for this is called agile integration and agile integration boils down to three things flexibility scalability and reusability flexibility is integration function so putting integration where you need it to talk to those systems to align with microservices type of principles wherever you need the integration function putting it there instead of having to build your architecture around your centralized integration function automation continuous delivery scalability that's all coming through a container platform so you want to be able to say what runs in dev runs the same and test runs the same and prod right and you want an ability to automate that and then scale it up and down once it gets there and then finally if you're agreeing that api's are gonna be the language that most of your business services speak to one another then you have to start to think about how am I going to engage with the users are these api's how am I going to track usage how am I going to handle security how am I gonna handle QoS how am I going to get data out of how these are being used which api's are possible which aren't together these three things allow you to deal with the complexity we just talked about all these evolving architectures that are coming at you viewed through the lens of agile integration you can actually have like a strategy that will make that manageable okay so for the rest of the today that's kind of the backdrop for the rest of today I want to zoom in on one of those pillars which is distributed integration and so that's fuse in our stack when we talk about distributed integration it's really two dimensions the first dimension that I mentioned in the last slide is putting integration wherever you need it if you want an ESB and you want integration at the center of your architecture you can do it if you want to embed integration in your application you can do it if you want to write micro services and use an integration container to tie them together you can do it if you want to put integration capabilities directly in your micro services you can do it the key thing is that wherever you need integration we can size it meda but the other element is not just where integration is used but who's doing it so fuse has always been super popular with developers and can will continue to be it's very very flexible we want to be able to start catering to the user that doesn't want write code so it used the same power of fusing the covers but enabling users that don't want to write code to solve these integration problems to leverage fuse to do so so based on that when few seven comes out and I'll say when at the end of the slide just so make sure every sticks around the there's three gonna be three distributions of views so this is a single product single product with three distributions so each one of these distributions caters to a specific segment of that market and how you're going to align your architecture to it solve certain integration problems so few standalone is just running fuse on a single JVM this is the fuse you know and love today views on openshift will replace fabric v1 and that's how you do scale out fuse with few seven and we're going to talk about all these in detail higher ms so i'm not gonna go into a lot detail now and then finally the third thing so few stand-alone and fuse on openshift already exist today so those just get better right fuse online brand new so this is our ipad style offering that we host for you that runs on openshift online or that you can run on OCP yourself alright so with that out of the way we're gonna get into the individual individual pieces so just kicking it off all if you don't mind I'll kick it off and hand it off to you alright okay so we're gonna follow a pattern we're going to talk about each distribution and then say when you should use it right because there's a lot there and we get a lot of feedback from customers that say like oh there's so much great stuff in fuse but I don't know what I should use like do I use this or use that trying to get better about being opinionated and helping you make those decisions so when it comes to standalone when when you use standalone if you're a developer that's writing Kamel based applications that are just gonna run in a single JVM stand-alones for you it gives you a tremendous amount of control and how you configure that environment so all the configuration the lifecycle you can just you can slim it down you can do whatever you want with it right at that point you're an expert in the fuse technology and you're doing whatever you need to do it also supports the concept of maybe hosting multiple applications in a single JVM so you maybe you have ten different applications that should have a similar life cycle now I want to live in the same a VM then you can do that too and you can use this in any way you can run it embedded you can have standalone things on EAP or carafe or whatever in this case though when you're using standalone any provisioning or centralized management any clustering is going to be outside of the domain of stand-alone okay that's gonna be open shift for us so in the case of standalone if you want to you know put your own load balancer in front if you want to use a broker to kind of scale things out you can do that but that's that's something that you would supply standalone is just running on a single JVM okay so let me hand it over to you hire oh my gosh I haven't even got to do this I haven't a spotlight everybody super impressive can you guys hear me ok now ok so the first one time I want to cover here you support three runtimes graph each EAP and spring boot right crafts are basically our traditional runtime that I think most customers have been using for a while 3/6 came out with EA key and spring boots brand new now with carafe we've done a major upgrade it goes from 2/6 to craft for so it's a drastic update they're the real strengths of perhaps sometimes people ask so which one should I use and I'm my answer is you should use the runtime that year your developers are most comfortable with right if your developers understand those gr they're like oh it's GI it's got a very powerful class load or isolation system between the modules you deploy it also has a very dynamic way of starting and stopping services then you should continue using crap or look into it if you're undecided right it can also generate small put footprint servers right I think that that's kind of new now for a few seven I think traditionally customers have always used crafting way where you download our big distro if you install it it's like you know almost GIGN size kind of thing because we include all the dependencies for all our components and we have lots of components right so now with Raph you can basically just run a build it creates a small specialized craft server that just only has to the libraries that you need to run your application fuse on the AP we are updating to EP 7.1 this is for you know all those hard core Java EE developers out there that want to use CDI and and use the the management that ye if he comes with in terms of XA management and data sources and things like that fuse and camel installs itself as a subsystem a module system inside of EAP which means that your application Wars are skinny Wars they don't include any other camera libraries you know which then causes that updates and upgrades of camel is transparent to your application users so for example you could take an application built against fuse EAP six right six three without recompiling it you could deploy it into a few few seventy AP and that's pretty much it that you shouldn't have to change anything because it's a skinny more okay so fuse on spring boot we started supporting spring boot in our fist line fist too low we're now bringing it so that you can learn to stand alone outside of overshift so we only previously supported running it inside of openshift a lot of people like spring boot you do is simplicity it's got a really a flexible configuration system where you can embed application configuration inside your application you can override it via files outside of the application employment the environment variables or system properties right and in the fact that I use this Aflac fast path for some people it's it's a it's a pus it simplifies things like testing at times so it really depends so like if you're a big spring shop maybe this is the route you should take okay so some highlights so this applies to basically all the run times we've updating them all to like the latest version of components that are available for example we're gonna be shipping with cable to 21 and compared to our sixth view product we have over 35 new connectors that are available covering a wide range of different types of technologies like IO T's size API stuff and also lots of components that work better for microcircuit style deployments things like SIPC in his tricks so you can do tracing of API calls between components and stuff we updated the hotteok management console that fuse hardening it's got a total you are refresh it's not using the same pattern fly UI widgets so it looks more like well it's aligned with the looking field the rest of the right hat products and also we we have connector parity across the runtimes now previously a few 6:3 the AP has a smaller set of connectors which cost it cost people to automatically say well i'm gonna i'm already deploying a crap this I want the most choices in terms of connectors but that's not the case anymore now all the connectors are available on all the runtimes so that shouldn't be a deciding factor for you anymore and yeah we're gonna be supporting JDK 8 in few seven we're starting to look into we've already been looking into supporting JDK 11 and we'll figure out exactly which part of the 7x line of release this will release at in another interesting thing you might have noticed in the previous slides in the diagrams basically Maryana see undertow basically learn a dinosaur transaction manager and now that's the same one across all the runtimes whether you're on a ap graph for spring booth it's gonna be the same library inversion so we're standardizing weekly a transaction management our web container and of course our services framework alright so here's a small collection of like all the new components and features that we've been adding to q7 that you know covers it it covers like all these different types ideas like in cloud you we we added support for pub/sub and assurance dauphin we actually have way more but just one you know it's it's always a big selection somebody nadia so ago I wanted this alright it's finally there right but we just continue this and this and camel community always continues to grow and add more components and systems they support so this will of course keep growing ISO fusing overshift did you want to do this live no that's my that's right alright so views on fish it basically takes standalone and changes it in a way so it's cloud native right so that it integrates some of the rest of openshift nicely we do things like give you tooling like fabricate maven plugins so that your Java developers can continue use the tools that they like using to do Java the moment to work with openshift in a seamless way so when you run integrations in openshift you you got to deal with the fact that you're building immutable images we've gotta have a nice way to configure the inject configuration that's environment specific to those integrations and and work with the rest of the features of the of ownership when you do choose to use openshift it means you get automatic scale out of your integrations management you get common way of managing them the centralized logging so just out of curiosity who what if who here has their their company's either already adopted or is considering adopting a container platform slides for you like we saw with fuses been releasing fuse on open shifts maybe close to three years I think so it's fairly fairly mature at this point I will have a lot of experience with customers doing so we're starting to see a lot of patterns emerge around stumbling blocks things that work things that don't process so I just want to highlight a few of those I won't go into like tremendous detail but the order ends around really four categories so the first is around development it's critical that when you adopt a container platform it and you could probably say these apply to any workload but we just find it with integration so I don't think these are a particularly specific integration that's you need a tool chain that drives the entire workflow so basically creating the app package in the app building the image right deploying it to the container platform that all needs to be handled from the developer tool chain so that you can get the agility at development time you need right it's it's critical that you focus on the application code and your business logic your integration logic and not building images building images is is your it's adding no value right so one thing we see a lot of is when people start down the path of building their own images and they get so entangled and how to keep up with security which we'll talk about a sec and a bunch of other things where their life is so much easier once they just adopt our standards our standard images and then finally in terms of you know going back to that point about agility the automation angle is key so you must build that in from the very beginning the concept of that yet what you want in this container platform is the ability to automate deployment right so getting that pipeline going either and you can do that in a couple different ways if you already have a CI system you just want to wire fuse for example into that you can use our tooling to do it if you actually want open to provide a complete CV environment for you out-of-the-box it can do that too but you must plan for that going in the beginning second thing is management so it's very common when you're gonna go to a container platform that you're gonna start blowing up your apps and you're gonna you know take an app that used to be one monolith and it's gonna be five 10 15 individual services whether you call them micro services or not in that case monitoring and management and tracking these things gets more difficult so you need things like centralized logging you need centralized collection of metrics you need the ability to drill down into individual containers and see what's inside of them right so you have to say like not only might be viewing this as a container like what's its CPU load what how much memory is it using and this type of thing you need to go in and you need to say hey this is a this is an app that connects an API to a database where am I in the process like where I had a failure can I go debug that route and say where is it at right and getting the metrics and the deep kind of domain-specific metrics that's absolutely critical that you need that capability and it's something that we see customers run across when they run on a container platform without the hooks and the instrumentation so be very careful about that put an operational standpoint one thing you will really want to do is once you get on the container platform and not just have a peer integration platform of course but run all your workloads there and build your operational excellence for all types of workloads and so again it's very important for the containers that you produce to have things like liveness probes and readiness probes so that they can be scaled up they can be scaled down if a failure is detected doing like a health check and health probes on your containers these are the critical things if they're not there you're rolling your own images you're running on another platform like it's hide from openshift for example and now you own that responsibility so it's not an impossible problem to solve but it's additional responsibility and then finally security I would say this is almost the number one issue with most folks that we talk to is keeping up a security so you have to remember that when you run a containerized workload containerized integration that you're not only supporting your code but you're supporting the fuze code and the JVM and the OS right so any patches that need to happen will give you the patch from a few standpoint but if you're rolling your own container you go apply that right and then you have to maintain you know plug into the CVD database for the JDK and for the OS so this is I've talked to a number of customers where this becomes an issue like the the level of management that they require to keep up with this so definitely just have a plan if you decide to manage on your own okay but have a plan for how you're gonna do it if you decide to go with openshift in our official containers then we do it all for you which is nice so just to come what some stuff to keep in mind there so some quick highlights so a lot of people are familiar with fabric v1 in few 6:3 basically we're using openshift to replace all that functionality right it handles managing multiple containers much better than fabric v1 you know does in a consistent way across all our products so we've we've developed some new part bits for open we now have a centralized console you can employ in to open ship which gives you a view that's a little similar to what you used to have in fabric 31 where it lists all the fused instances that you're running and then you can click on to them and yeah it'll be a hot I though so that's in place we're also adding automatic Prometheus metric exporting from any of the integrations that you deploy using fuse on open ships and one of the things that is interesting is we really have not really changed the development style of tools that were that you guys if you guys were using phase 2 o which was basically if used for overshift and with few 63 that's all remaining the same all you'll have to do is just upgrade some bomb versions to pick up the 7x line of jars and fixes we've done some tweaking around the image settings the image memory calculations that it does in turn of tune the JVM now we can scale better with large number of core counts nodes right and one new big thing is now we also support a fused on an EAP image on OpenShift right so now you can plug either craf spring boot or EAP to over ship okay so quick demo and I need to switch to my computer right so for folks who haven't seen how ok so for folks who haven't seen what developing to use for open this I'm going to show you real quick basically the code editor here there you are this is one of our sample projects that we have a quick start for and I'm just gonna show you the code here real quick so folks that maybe not that familiar with a few spring boot support this is what this would kind of look like right it's just a spring boot main app and then all the really cool stuff happens inside of a route builder and this is what a camel rest yourself kind of looks like this app will be exposing a couple of less end points and then tiny using camel route to a database we're gonna be doing some selects to extract data and we're also gonna have some periodic executions of stuff that generates data into the database so it's a really simple app don't actually want to get into showing you how camel it works I mostly want to show you that you can take the spring boot app and let's see and build it to build a spring boot off it's just a standard mating clean package right so no no big changes there if anybody's developing do before a fuse just works with it normally right we do have some additional plugins that we put into our apps here but now you'll have a a jar inside the target directory that you just build right if you run that it would actually fail because I haven't told it what the password is to the database all right so let me then since I'm I'm not gonna wait for the failure they mean that right there I just did this I'm gonna put forward to my database that I'm connecting to this I don't have that one actually running here locally so it's something like this I'll use a spring mood stuff about you can configure it by using system properties here I'm just telling you hey that my sequel service username is admin the password is password simple stuff that gets you going this will start up the app locally you can hit it at localhost 8080 look at the REST API so get a swagger things like that but the next thing you want to do is like so this is really simple it's just as simple to get this deployed on open ships all you have to do right there I'm re inserting orders into the database the random thing let me kill this alright now I always take this and put it on over ship so you just do amazing break eight oh actually let me copy this cuz I'm gonna need this is that when I also put in this time okay so maybe then I'm gonna give the same system properties because I want to tell it what what was a ID and password to connect to the database with when you're on over the ship and then you could just go robbery Hey and so what this does now it's gonna use our power key made them plug in it basically will build build your jar connecting to open shift push a binary build into open shits which basically means I'm gonna give the jar a build runs on Oh Bishop that creates the docker image for you and then this also generates all the kubernetes resources that you need to get to start up that image okay it defines the services that routes all these kinds of docker resources that gain to you to use this app so let me switch over to my console here so right now what you see is openshift already detected that builds what happened so it's redeploying the app as we speak right you're building number five was created a min ago and it pushed the docker image it was done so we kind of get good detail and once it does come up I can show it to you but actually the other thing I want to show is this is exporting that's already to Prometheus I had a previous one running and once you do have prometheus is available you can deploy Agrafena and a group on it's a nice way of seeing check charts and that come from Prometheus and this is some of the basic charts that it provides so that's a new feature with g7 and I will switch back to my console to make sure yep I finished coming up I'll go here and we get to the right right there that's at the end point the end point that it implemented if you wanted to get the API Doc's for it there's an API doc fit here this is swagger 2o which is important to say you can take that and use it to import it into our iPad solution that is gonna talk to you guys about it of the demo yeah I think what I do we're gonna do you want to talk briefly about the fire of your migration yeah yeah so property one we understand there's going to be a bit of a migration project there is a standard way of basically taking profiles that used to configure after the one with and convert them into individual fuse craft projects so basically for every container that you put a profile stand on you will create a new source project or for that container configured with the same configuration those profiles were basically doing which this is the straightforward way of mapping them and basically they'll be like a fifth fix-up cycle because there's gonna be some concepts they were party one they're just done totally different innovation for example there's no fact there's no fabric one gateway you should just use open ship services for it but at anyway you just would deploy that into open ship just like I did in my demo and you get a running fuse container and over ship here's the the list of like concepts that kind of change in open ship stuff like you know failure detection OB ship that's that for you now and it doesn't even better because it actually runs health checks against your application and readiness checks to avoid directing traffic at your server until it's ready to actually accept the traffic it has you know LK stack to have a centralized logging for all the openness consoles so that replaces what we used to have inside for ya and then switch long times anyway awesome thanks Aaron okay so we're gonna combine two things here because I was going to give a quick demo as well and so instead of showing slide rum and discuss this quickly and then I'm gonna about the rest as I demo to make sure we have enough time so when we talk about we just did like why would I use stand alone why would use a fuse on openshift in terms of why you use fuse online it's back to that use case of you have an integration problem you don't want to write code to solve it and that can scale to very simple cases point to point integration for like a line of business user right that doesn't know how to code all the way up to a that person working with the developer to contribute native extensions to our environment to handle really complex problems so it's not just this solution where you have an individual I can go in and solve a problem but both user bases these non developers and developers can work together to solve problems which is a very very powerful okay so I might use I'm going to jump right into a demo here just so you can see it live so that the key thing here is I'm just going to do a very basic example this is one of our out-of-the-box examples we have a an eval cluster we can sign up for an eval account you can do this on your own just want to give you a taste of what the interface is like so I'm at the dashboard for for a fuse online right now I'm just going to create a quick integration that integrates let's say a cloud SAS to on-premise data source or going from Salesforce to to a database so in this case I'm just going to create a new integration say hey I want to interact with Salesforce and so I'm gonna say Salesforce is the starting point and I can respond to a number of different events so what is happening in Salesforce in this case I want to say anytime an object is created in Salesforce I want to act on that so I'll say on create and then fuse online actually goes out and queries live that Salesforce instance and pulls the data model for your organization and Salesforce in this case I'm gonna select lead and now I'm done so any time a lead is created now in Salesforce my integration will be triggered now I want that to go into a database so I'm gonna select database here and I can either execute some arbitrary sequel or invoke a stored procedure so I'll go ahead and say store procedure and I can select it interrogate the database finds the stored procedures that are there and I'm gonna select add lead and you notice there's a little warning here and the reason for that is that fuse online is inherently type aware so it knows the datatypes of what's in Salesforce that you selected it knows what a lead is and also knows its introspected the stored procedure parameters so it knows what those are - so what it's saying here is that there's a data type mismatch I'm grabbing a lead and it's going into a database and those don't match so I need to add a step a data mapping step so we'll go ahead and just click on that and then notice again because it's inherently type of where I don't have to tell it about my data it knows what a Salesforce lead looks like and it knows what the parameters are for my stored procedure so if I wanted to I could just go through it straight through here and say you know map company to company I can just go all the way down here and I'm not going to do that because I want to save us some time but you can see it's pretty straightforward mapping it supports you know aggregating field to support it supports splitting fields very very powerful and I'm assuming I was actually done there I can just go ahead and say publish and give it a name integration one test integration and then go ahead and say publish and now we're off to the races a couple things to note what I'm doing right now is all our openshift online eval cluster so I didn't install anything on my laptop I've had my laptop crash at conferences before and I just use somebody else's laptop and and basically do the demo there so nothing installed on my machine I just have an eval account and I'm doing this all in in the cloud in our iPads hosted service okay so let's come back here and I address some of this already so I just want to move forward here anyone can get started with this I'll talk a little bit more about the timing in a second I already did the demo so we just could see that cool animation one more time let me wrap up first for any existing fuse customers in the audience whew seven will be coming out at the end of May if there are changes so for example fabric v1 is not present in few seven we extended the life cycle a few six last year to give existing customers as much time as they needed to make it me this transition so you have maintenance support for few 6 all the way through January 2022 and a less support all the way through 2025 so I try to tell people the building's not on fire you know loads of time to stay on whew 6x whew 6-3 is the most stable fuse there's ever been right so take your time evaluate your options and then migrate when you're ready in terms of timing we've had a number of public releases tech preview releases a few seven we're at the goal line now so I mentioned end of May is our target release date where we'll have all three distributions of fuse available so you'll see a few standalone fuse on OpenShift and fuse online all available at the same time all shipping and coordinated from a lifecycle standpoint moving forward we are moving to a new model now a few seven where we'll be releasing once a quarter so in those releases you'll see bug fixes you'll see enhancements and you'll see features but we are going to very very closely monitor and groom those changes so that they are backwards compatible what we want to do is give customers a very predictable schedule for releases and keep them and make it not an adventure to go from one miner to another this means that you'll probably see majors more frequently so probably every 18 to 24 months to see a major release because that's where we'll be doing very significant improvements like a huge camel bump for example okay so I think we're pretty close as I'm actually right on a dot 245 all right so I'm happy to take questions until they kick us out of here or the next speaker shows up but like I said we had a lot to cover so I'm sorry we don't have a lot of time for questions but I'm just going to hang out so anybody that has a question please feel free to come up yeah like can you have it so the question was can the data mapper do something like store an intermediate value and then maybe map it later or can you do like co-occurrence constraints or some of the more advanced capabilities no it's it's complicated as it gets right now is that we supports basically field level transformations so you can pad you can you can basically trim you can do a lot of like field level transformations you can do direct mappings you can split and combine and that's that's what the data mapper does right now in those XML JSON and Java all this is extensible so if you have ideas for things you'd like we'd love to see love to talk to you document that and then we can look to improve it so the question was what about CDI welled images and that would be the EAP image so we have a fuse on you and if you want to do see the ion world based development then you would use that okay thank you very much everybody and please hang out and ask questions afterwards we're happy to chat with you so thanks bye [Applause]

Channel: Red Hat Summit

Views: 15,905

Rating: 4.6210527 out of 5

Keywords:

Id: UdQz17sphZs

Length: 46min 0sec (2760 seconds)

Published: Fri May 11 2018