I have doubt, current version we have DataWeaver which is similar to Datamapper for transformation.
If we need, require to add as a plugin.
In this link https://docs.mulesoft.com/mule-user-guide/v/3.7/datamapper-user-guide-and-reference#examples says Datamapper is exclusive to entreprsie edtion only.
Is the Datamapper can be used throughout the future version of enterprise edition completely ( either as Plugin for standalone or default for cloudhub?.
Is it have a any chance of deprecating in future for enterprise version?
Thanks in advance.
DataMapper will be supported till Mule runtime version 4.0 , if you start off new i would recommend going with DataWeave. Otherwise you'll need to migrate at a later moment
Related
We are currently using pentaho 7.X, after log 4j vulnerability we need a solution for that. Please let me know if we have any updates in pentaho 7.x after log4j issuse or we need to upgrade to latest version. If we need to upgrade to latest version, what is the steps?
Thanks in advance
By now Hitachi Vantara hasn't published any patch for the Community Edition version, I don't know if they have provided a patch for the Enterprise Edition.
They are going to release the 9.3 version, I don't know if there's an official date. Maybe in the Community Edition of the 9.3 version the log4j libraries will be updated, look for the official release notes when it's published.
We have MuleSoft applications and they are deployed in Mule Runtime. We need recommendations on patching MuleSoft applications. The patch can be either in MuleSoft Runtime itself or can be in application.
MuleSoft's recommendation on patching a MuleRuntime is available at https://support.mulesoft.com/s/article/How-to-apply-patches-to-Mule-4-x.
Here, the recommendation to patch MuleRunTime is to replace the jars/plug-in. But with this, how can we maintain/know the version of patch that is applied.
What is the recommended way to patch a application which is deployed in MuleRunTime.
Any help/recommendation on this is appreciated. Thanks.
You can look at infrastructure automation tools that auto install your runtime with the correct patches etc like puppet, chef and so many other tools. So that your runtime is always using the correct doenedencies and is repeatable. Which tool depends on your organisation.
Or just as with your code you can version control your runtime or install scripts in git etc.
The Mule runtime will log its own version and the versions of each plugin and applied patch, whenever it starts your app. So check the log from the last time you started and you'll see the current version and patch level.
So trust the recommendations in the help document you cited in the OP. As Ryan says, you can use any dev-ops tools favored in your organization. (If you don't have a favorite, Maven is integrated very nicely with Anypoint Studio and can help with this.)
I'm looking for a solution on how to deal with API versions in ANYpoint API manager. At the moment it is possible to create a new version of an API. But it is not possible to distinguish between different OTAP environment. In my situation it could be possible that a test environment has a newer API version than production. Do anyone recognize this issue and how did you solve it?
Currently, there are no environment promotion capabilities per se in Anypoint Platform. Having said that, there are a number of things that you can do that can help in that regard, for example:
- You can export an API from Organization A and import it on Organization B.
- You may define different sub organizations, to reflect your OTAP environment structure.
In general, it is not strictly bad that on QA, Stage or UAT environment, you have a newer API version than in Production, if you plan to implement such version in there.
Just my 2c, Nahuel.
As far as i understand if we want are going to create multiple apis then RAML versioning should be followed. what i do i can share with others.
development raml version= 0.1.0
First major release version=1.0.0
if there is any minor change then we can do 1.0.1
if there is any major contract breaking change then we can use 2.0.0.
I need to migrate my application to WAS 6.1 to WAS 8.5.5. I would need list of things to be taken care before migration and what are all the major changes involved.
I googled and sufficient informations I couldnt get. Can some one please help me on this ?
One thing to do is to setup an eclipse with IBM WebSphere Application Server Migration Toolkit and then import your application source code (you may even analyse your binaries with Migration Toolkit for Application Binaries) in the workspace.
You then run Software Analyzer and select the Websphere Migration rules.
We have a requirement to connect SAP ERP. As per Mule documentation, to connect SAP( Jco jars) it says 3.0.11 ( Latest) is not supported by the connector.
[http://www.mulesoft.org/documentation/display/current/SAP+Connector][1]
We have reached SAP - they says like only Latest version ( 3.0.11) should be downloaded from Marker place.They were not supporting the SAP old version jars since latest is released( with bug fixed) .
Please suggest, how do we get older version of jars ( 3.0.9 or 3.0.6). It will be very helpful. We are looking for options.
Thanks in advance.
SAP do not release older versions of the SAPJCO or SAPIDOC libraries as the latest versions are fully backward compatible.
The difference between 3.0.9 and 3.0.11 are very minor bug fixes, so its surprising to hear that 3.0.11 does not work. MuleSoft should liaise directly with SAP as they are an SAP Certified Integration Partner and their software should always run on the latest versions of the various SAP connectors.
As a certified partner MuleSoft will be abundantly aware that customers only have access to the most recent versions of the SAPJCO/IDOC libraries, and that SAP do not release older versions.
You would also think that MuleSoft would have access to older versions of the libraries from engagements with existing/previous SAP customers.
I would advise you to go back to MuleSoft and have them speak directly with SAP. This is not a problem for the customer.