mule elements and flows

mule is a simple message router, which is configured in an .xml (mostly mule-config.xml)… following main elements can be found in it:

  • connectors: defining the class, which will be used for the connection (can be used by endpoint with connector_ref)
  • transformers: definig the class, which transforms the message to usable stuff (can be used by endpoints this transformer_ref)
  • inbound-endpoint: inbound-event for a flow
  • outbound-endpoint: outbound event for a flow, or message forwardpoint
  • component: class in a flow which will be called after inbound, before outbound

there are 2 types of flows… flows with an outgoing-endpoint and flows without… in a flow it is possible to define multiple entrypoints and it should be possible to define multiple endpoints… i think, only 1 component can be defined… a PoC will show…

so a normal flow will be as followed:

  • defined inbound-endpoint with a connector (to connect and wait for the incomming message) and a transformer(to handle the message and transform it into a format which the component expects)
  • defined component which will do something with the message
  • defined outgoing-endpoint to sent the message to other systems

additionally there is a model and services in the config file… couldn’t figure out, what the heck they are for…

mule esb

my project at work will use mule as central framework and so i need to come up to speed with this technology as well…

mainly it should be an esb… but actually is my understanding of a bus completely different… mule is a centralized server, where messages are forwarded… ok its a little bit bigger… incoming messages are handled in a flow… transformed if needed and sent out, as outgoing messages to other applications, components…

but where is the bus? my bus understanding is a (lets say) cable, where all applications/components can attach themselfs and lock into the dataflow in the cable, and take the message, if it concerns them… like Observer-Pattern… but in mule, the message flow is defined on the server, with inbound- and outbound-endpoints… so where is the bus?

pom.xml

pom.xml is the configuration file of maven… the main file… the one most important file… and its kinda confusing… 🙁

the basic xml tags are easy and mostly slefexplaining… every thing is based on the basic lifecycle… but with plugins it is possible to improve and change the lifecycle…

first of all it is possible to create Mojo classes (<name>Mojo)… these classes can be executed during the build process… whereas the pluginname (artifactId) is mavan-<name>-plugin… and if set a groupId a java package name…  with a <configurations> tag it is possible to set private parameters on initialisation…

additionally these classes can be executed… in the <execution> the when of the execution can be defined, in which phase (phase-tag).

mostly helpful

actual its really confusing but i think  i start to see the power of maven… but i think learning maven is only possible to do so on the job… so only if you really need to create plugins, dependencies and other fancy stuff, you really understand it… and the problem of this learning approach is lerning-it-wrong possibility…

currently there is a pom.xml file on my project, so my maven learning curve will be slow 🙁 or just flat 😛

maven lifecycle

ok commands are cool… understanding them is easy… but seeing behind it is hard, but important… follworing list of commands is from Build Lifecycle Basics:

  • validate – validate the project is correct and all necessary information is available
  • compile – compile the source code of the project
  • test – test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed
  • package – take the compiled code and package it in its distributable format, such as a JAR.
  • integration-test – process and deploy the package if necessary into an environment where integration tests can be run
  • verify – run any checks to verify the package is valid and meets quality criteria
  • install – install the package into the local repository, for use as a dependency in other projects locally
  • deploy – done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.

the important thing here is, that if you call package, all the commands before will be called… eg. validate, compile, test and package.

this is the default behavior and can be modified by plugins…

maven commands

the tutorial is actually really good, and i think i understand it… ok currentlly its just the basic tutorial project, but hey… i really didnt know anything…

following command list might be useful 🙂

  • mvn compile: as its named, compiles the project 🙂
  • mvn test: runs all the implemented test…
  • mvn package: comiles and tests the project and creates the jar file, or whatever is defined…
  • mvn install: puts the jarfile to the repository… as defined somewhere… hopefully the somewhere will be solved in the tutorial 🙂

there are other commands… but currentlly less important…

import maven projects to eclipse

maven has its predefined structure of the project files and there is a simple, easy command to create it 🙂

mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DgroupId=com.mycompany.app -DartifactId=my-app

and yeah… its from a tutorial… so the structure is ready… the pom.xml is created… but it has no eclipse .project file… ok i could have created the same thing in eclipse, with a maven plugin, which is actually installed on my eclipse… but as i told you before… its a tutorial… and importing to eclipse is easy… with the plugin…

Import… –> Maven –> Existing Maven Project

nuff said…

building in maven

once again… new projects, new concepts and new technologies… this time its maven… the project i am working on, has already set up everything (hopefully)… and my maven knowledge didnt even allow starting the build process… so current reading everything about maven… starting with the wiki page… an building is named packaging… and the console command is:

mvn package

or in eclipse:

right-clicking the project –> Run as –> Mavan Package

esb – enterprise service bus

new job, new technology and of course new concepts… esb…

i knew this architectional concept might be part of my new job… so i tried to read/learn it in advance… but as you might know, i failed… so now i am on the job and really need to understand it… an with these blog entries(1, 2), of a Mule ESB founder its really simple and clear 🙂

crm test instance updates

ok after moving our crm test instance to a new destination (http://support.microsoft.com/kb/952934/en-us),  the next goal to reach was the update of this instance… not software, data…

our crm in the productiv environment is really used a lot… so to test (and develop) the actuall productiv data would be a big bonus… so we needed to copy the productiv database to the test environment. sounds easy… but it isnt…

so… first of all copying the database was easy… backup the data on the productiv sql server, restore it on the test sql server… voila… ok normally this works… but in crm we need to set the installation to the new database, with the same name, with actually no difference… but ok… and its easy, because a tool (Deployment Manager) on the test server can handle this… but because its the same name, crm thinks, it works already… and actually there is no refresh button in the deployment Manager… so just load a fake organisation… then load the correct organisation again… voila… but wait… its an actuall copy… so all absolute links are still pointing into the productiv environment (eg. isv.config) and funnyly relative links might be swiched by the crm to absolute… so crap…

ok currently we will do it manualy the updade, when we need it… if there is a way to automate the hole thing… contact me…

moving crm

we needed to move our crm environment… ok it sounds like bad idea and the reason was the server naming convention… ok now you will thick: why the hell didnt they do it correct the first time? actually… we did… but the consultant, how installed the crm, didnt… yeah and its our fault, that he did it wrong, we should have had controlled him better… but on the other hand, its just our test- / dev-enivornment… so it has no impact to our company, when we rename it, reinstall it and so on…

in my opinion, the move is not really importent… ok i am leaving this company next week, but its only a test server… therefore wth? but on the other side, we need to figure out a way, to replicate the data of the productiv environment to test… and i think this will actually be really similar to the move process… therfore, its training 🙂

and with following link pretty easy: http://support.microsoft.com/kb/952934/en-us

now i only have to re-install all our applications and re-configure the iis and re-register the plugins and… meh!