I am getting resource not found error when running multiple munit (version 4) test cases from one file. But if run then individually they run fine.
Any help is much appriciated.
HTTP Config:
<http:request-config name="HTTP_Request_Munit_configuration" doc:name="HTTP Request configuration" doc:id="c3f254ef-d670-4cae-81dd-37eca8de05e8" basePath="/leads/v1" >
<http:request-connection host="localhost" port="8081" />
</http:request-config>
Error:
org.mule.runtime.api.exception.MuleRuntimeException: HTTP PUT on resource 'http://localhost:8081/leads/v1/XXX' failed: not found (404).
MUnit does not actually run your service. It creates special environment to run flows for testing.
If you want to test real server then you have o run it separately and then later run MUnit in the separate environment.
IMHO MUnit is designed to test units - flows, subflows, transformations. It was not designed to test servers.
Related
we have a flow where we have property file reference as given below
"context:property-placeholder location="httpdemo.${country}.properties"
now we want ${country} value to be replaced by actual value at the time of deployment.
As we know one way to achieve it is setting the value of country as environment variable on the ESB and deploying it. But we don’t want to do that because of below reasons:
We deploy same code base for multiple countries in parallel
Environment properties can be set only during start of mule runtime so if I set env variable as country=UK and have deployed for UK. Later I want to deploy for MY again I need to restart ESB by setting country=MY which we don’t want to do.
Please let me know if there is any other better way
We had a similar situation where we needed to have multiple versions of the same application running parallely. The solution we used for this was to package the property file along with the build and not have the dynamic element (environment based) to it. For eg; in this case we construct httpdemo.usa.properties and packaged it along with the app. This was fairly easy for us since we use Jenkins to manage our builds and releases. When the build is released, we reference a configuration file from Jenkins which contains all the specific "country" related properties. You can even pass this country as a parameter to the build definition. Using a custom maven plugin we replace the property file within the app with the new properties from the Jenkins property file.
Another solution to your problem could be to follow a naming convention to your apps specific to the "country" you want to use and fetch the properties using spring beans. For eg;
<spring:beans>
<spring:bean id="CountryProperties" class="org.springframework.beans.factory.config.PropertiesFactoryBean">
<spring:property name="singleton" value="true"/>
<spring:property name="location" value="${app.name}.properties"/>
</spring:bean>
</spring:beans>
<http:listener-config name="HTTP_Listener_Configuration" host="localhost" port="5000" doc:name="HTTP Listener Configuration"/>
<flow name="dynamic_propsFlow">
<http:listener config-ref="HTTP_Listener_Configuration" path="/test" doc:name="HTTP"/>
<logger message="#[app.registry.CountryProperties['country.full.name']]" level="INFO" doc:name="Logger"/>
</flow>
My properties are like below:
File - dynamic_props_usa.properties
population=10
country.full.name=united.states.of.america
File - dynamic_props_mexico.properties
population=100
country.full.name=mexico
${app.name} gives you the name of the app that is deployed. In case my app is named dynamic_props_usa, it refers the dynamic_props_usa.properties. If it is, dynamic_props_mexico, it refers dynamic_props_mexico.properties. Hope this helps!
Define context property placeholder to have a file reference in the package and have an option to override the same with server if needed at runtime as below,
<context:property-placeholder location="classpath:app-${mule.env}.properties, file:${mule.config.path}/app-${mule.env}.properties" ignore-resource-not-found="true" ignore-unresolvable="true" />
You can run your on premise Mule server with the option -M-Dmule.country=your-value
You may want to take a look at the documentation
Has anyone used MUnit with SFTP component, could yo please provide me any helpful information/example to start up?
I went through the MUnit documentation but didnt get much help on the SFTP component with Munit.
Use Munit FTP server. Enable secure attribute true to use SFTP . Please Refer this page https://docs.mulesoft.com/munit/v/1.2.0/munit-ftp-server.
Start the server before suites run, and stops the servers after. Example as below.
<ftpserver:config name="FTP_Server" secure="true" doc:name="FTP Server"/>
<munit:before-suite name="suiteBefore" description="MUnit Test">
<ftpserver:start-server config-ref="FTP_Server" doc:name="FTP Server"/>
</munit:before-suite>
<munit:test name="FlowTest" description="Test">
--flow test goes here----
<flow-ref name="test5Flow" doc:name="Flow-ref to test5Flow"/>
<ftpserver:contains-files config-ref="FTP_Server" file="testFile.xml" path="/tmp" doc:name="FTP Server"/>
</munit:test>
<munit:after-suite name="After_Suite" description="After suite actions">
<ftpserver:stop-server config-ref="FTP_Server" doc:name="FTP Server"/>
</munit:after-suite>
From Anypoint Studio, go to Help and Install New Software….
In the Work with: panel look for MUnit Update Site, and from the MUnit Tools for Mule section, select FTP server Module (Mule 3.4.0+) then you come to get munit component for ftp server .you can use this ftp server in before/after suite to handle data transformation for testing of the application and you can use this as a out bound to your application munit flow.
We currently have our mule projects organized where we have our mule flows in several flow files. We find that this helps in allowing us to reuse flows. However, it has an added side-effect. By having dependencies amongst other flow files, we are finding that our munit tests now have to load an extensive number of flow files that slows up our munit tests because we have to load many more files. We also don't want to stick our flows into one huge file either.
We want to know if there is a happy medium or a strategy with how we should be splitting our flow files so that it minimizes the impact of performance when it comes to tests and application loading?
Thanks,
Juan
I suggest that you use a general global configuration xml, where you place all your configurations and endpoint connectors. That way, you will only load the global.xml and not every other flow you are referencing.
Global.xml contains:
<http:listener-config name="HTTP_Listener_Configuration" host="0.0.0.0" port="8081" doc:name="HTTP Listener Configuration"/>
<http:request-config name="REST_Request_Configuration" host="localhost" port="80" basePath="example" doc:name="HTTP Request Configuration"/>
<http:request-config name="REST_Request_Configuration2" host="google.com" port="80" doc:name="HTTP Request Configuration" basePath="/translate/v2">
On your test suite you only need to load one classpath/xml:
<spring:beans>
<spring:import resource="classpath:global.xml"/>
<spring:import resource="classpath:workflow_you_are_testing.xml"/>
</spring:beans>
Hope this helps.
I'd define the default mule-config.xml, with the connector configurations and flow file for each task in the project. Doesn't necessarily mean each flow file will contain single flow but flows related to same task conainining sub-flows or private flows as needed. However, the flow functionality which is reuseable like alert emails, database operations, put that in separate commons-config.xml flow file.
For unit-testing, I'd create another mule-test-config.xml under src/test/resources to contain mock connectors like database or any other. The connectors to use as it is like http or some other, copy them as it is to mule-test-config.
Now to test particular flow, you'd need flow file + mule-test-config + commons-config (if any shared flow)
I am facing a strange scenario while writing Munit test cases in Mule. I have successfully written couple of Munit test cases for maven based sample Mule project and the test cases are running fine. When it comes to a project where I used RAML, and I've generated test cases and did every thing to test a flow. It was very strange that even a logger on a Munit flow is not printing any message.
Here is my flow:
<munit:config name="munit" doc:name="MUnit configuration"/>
<munit:test name="MainFlow-test-suite-MainFlowTest" description="Test">
<munit:set payload="{"msg": "Ram"}" doc:name="Set Message" />
<logger message="#[payload]" level="INFO" doc:name="Logger" />
<!-- <flow-ref name="MainFlow" doc:name="Flow-ref to MainFlow"/> -->
</munit:test>
At least, the logger should print {"msg": "Ram"}.
Can any one suggest?
The probable reason for it not to be working is that you are missing a few attributes in the munit:config, mock-connectors & mock-inbounds:
<munit:config mock-connectors="false" mock- inbounds="false"/>
In any case please take a look at this this doc page it explain the APIKit testing scenario.
HTH
i am creating one webservice in mule using cxf:jaxws-service. This is the url :http://localhost:65042/InsertDocService/InsertDoc, i am ablie to generate WSDL file, but i want to consume this service in mule using cxf:jaxws-client.
<flow name="documentumclientflowFlow1" doc:name="documentumclientflowFlow1">
<inbound-endpoint address="http://localhost:65042/InsertDocumentumService/InsertDocumentum" doc:name="Generic"/>
<cxf:jaxws-client operation="insertDocumentum" serviceClass="com.integration.IDocumentumInsert" port="80" mtomEnabled="true" enableMuleSoapHeaders="true" doc:name="SOAP"/>
<outbound-endpoint address="http://locahhost:65042/InsertDocumentumService/InsertDocumentum" doc:name="Generic"/>
</flow>
if i invoke this, it's going to Service project and getting erorr like"org.apache.cxf.interceptor.Fault: No such operation: (HTTP GET PATH_INFO: /InsertDocumentumService/InsertDocumentum)". Please any one suggest me how can i solve this issue and how can i consume this service.
Besides the type (locahhost instead of localhost), it looks like you're trying to use the same address in the outbound endpoint than in the inbound one. I don't think this is what you want to do, as it will lead to a looping re-entrant call that will eventually exhaust the pool threads, block, time out and die in a fire.
So what do you want to do with "documentumclientflowFlow1"? It is unclear from your question.