This post is a continuation of ReactJS for Noobs post and if you haven’t read it already, first go through it before continuing with this article. ReactJS is a library to manipulate the web page DOM and when building a complex web app, it is paramount to manage the state of the application and most of the time React components want to talk with each other.

If all the components start to talk with each other, the whole app will be a mess and debugging an issue would be a nightmare. Hence, Flux can be used to make our lives easier. Flux is a data unidirectional architecture pattern. It is mostly a concept, rather than an implementation. First, let’s get a good conceptual understanding of what flux is and later on move on to an example implementation to get hands-on experience.

Flux in a Nutshell

Flux architecture pattern mainly consists of four components
1. View
2. Action
3. Dispatcher
4. Store

Let’s start with the View. The view is the user-visible layer which consists of React Components. Users can interact with React components since a component is mostly an HTML segment rendered on the web page. When a user interacts with a component an action can be invoked, such as showing a pop-up message when a button is clicked, and changing the color of a DIV element on mouse hover and so on.

This moves to the next component, Action. In the above-mentioned example, a user clicking on the button is the event and showing a pop-up message is the action. There can be may predefined actions and for each event, a React component can invoke an action.

When an action is invoked, the dispatcher dispatches the action to the store. The dispatcher is responsible for the wiring of React components and Stores via actions. That means whenever a component invokes an action, the dispatcher will dispatch the action to all the registered stores.

Next component is the Store, which is just an object extended from event emitter which acts as a data store. This data store keeps the state of the complete application or the state of a part of the application. When an action is dispatched to the store, the store can change its state based on the action. As an example when an action to change the color of a DIV is dispatched, the store can change its current state to reflect the new color for the DIV.

Now comes the last part. When a store changes its state, how can the React components update their component states so that ultimately the change is reflected on the web page? This is done by event listeners. A react component can register an event listener for a particular store and when the store changes its state, it will emit an event. The React Component which is listening to these events will be notified and no the component can query the new state of the store and update its component state. Below diagram summarizes connection between all these components.

Flux in Action

In this hands on tutorial we are going to build a basic React app with two components as shown in figure 2 and see how these two components can communicate with each other.

First, let’s create a react app by executing below command

create-react-app flux-example

Next, let’s add flux dependency to our app by executing below command

npm install --save flux

For this example app, apart from the boilerplate code we need two components. First let’s create a directory called components (in src directory) and within that create a file named ButtonComponent.js with below content.

As you can see the component will render two buttons with Red and Blue labels. Next within the same directory, create a ColorComponent.js file with below content.

As you can see, the component just renders a DIV with lightgrey background color. Next modify the content of App.js file as below.

Further, after adding below styles to index.css file and executing npm start and opening http://localhost:3000/ in your browser, you should see the content of the app which is similar to figure 2.

Although we have the skeleton of our app configured, clicking on the buttons will not make any change to our color component. To address that, first create a Dispatcher.js file in the src directory with below content.

This is the dispatcher for our app which will dispatch actions invoked in components to the registered stores. Now when the user clicks on a button we need an action to be invoked. For that create a directory named actions (within src directory) and within that create a file named ColorAppActions.js with below content.

You can create an action file for each component or only one file for your complete app. But it would be easier to maintain the app by keeping a separate action file for each main component. In the above code as you can see changeColor(colorName) function is exposed, so that our ColorComponent can use it to notify the change of color. Within that function we invoke the dispatch() method of the dispatcher with an object with two keys as a method argument. The type represents a unique name (throughout the app) to distinguish the action and value contains the additional information associated with the action. You can include any number of additional key-value pairs in this object. Next we need to update our ButtonComponent as shown below.

When user clicks on a button we have configured the component to invoke onButtonClick method through onClick synthetic event. Further, for each invocation we pass the name of the color as a method argument. Within the onButtonClick method, we invoke our changeColor() action.

Next, let’s move on to the store. Create a directory named stores (Within src directory) and create a file named ColorAppStore.js within that directory with below content.

This is the data store of our App. As you can see it is extended from EventEmitter because once the data in the store changes, the store will emit events so that subscribed components can update their respective states. In this store we have only one data at the moment, i.e. activeColor which represent the current background color of the ColorComponent.

const colorAppStore = new ColorAppStore();

dispatcher.register(colorAppStore.handleActions.bind(colorAppStore));

As for any store, above two lines are salient. First one creates a new instance of the store and second one registers the store with the dispatcher through a handler function so that whenever the dispatcher fetches an action, the handler function of the store will be invoked with respective action as a method argument to the handler function. In this example, the handleActions() method in the store will be invoked for any action invocation.

Within the handleActions() method, the store can query for the identifier of the action (type) and if the action is relevant to the store then the store can act upon it or if that is not the case, simply ignore the action altogether. In our case, for COLOR_APP_ACTIONS.CHANGE_COLOR we want the store to modify its activeColor accordingly and emit an event to notify the components that a change in the store has occurred. This is accomplished through below code.

this.activeColor = action.value;

this.emit(“storeUpdated”);

Next we need to update our ColorComponent as shown below to catch events emitted by the store.

First change in the component is that in the constructor for the initial state we obtain the color from the store so that we would have a single source for the background color. Next, within the componentDidMount() lifecycle method, the component is subscribing to storeUpdated events emitted from the ColorAppStore. It is mandatory to remove the listener in componentWillUnmount() method. Otherwise the store subscription will cause a memory leak in your app. As per the above code, when the ColorAppStore emits storeUpdated event, the updateBackgroundColor() method in the component will be invoked and within that method, we update the current state of the component to reflect the change in the store.

Now if you run the app and click on the buttons you will see the background color of the ColorComponent will change as shown below.

In a nutshell, when the user clicks on a button, an action will be invoked by ButtonComponent with respective color as data and the dispatcher will fetch this action to the ColorAppStore. Next, the store will extract the color information from the action and update its store data and emit a storeUpdated event. The ColorComponent which is listening to the storeUpdated events from the store will receive the emitted event and the component will update its internal state to match with the data in the ColorAppStore.

As you can see, the store acts as the single source of truth and the components talk with each other through manipulating the data within the store. This example demonstrates the basic usage of pure flux and there are better implementations of flux which abstracts out the boilerplate code to increase the developer efficiency. One such implementation is Redux and I will walk you through the basics of Redux in the next article.

The complete source code of this example app is available at https://github.com/sajithdilshan/flux-example

Call To Action

• Clap. Appreciate and let others find this article.
• Comment. Share your views on this article.
• Follow me. Sajith Dilshan to receive updates on articles like this.

ReactJS for Noobs II — Flux was originally published in codeburst on Medium, where people are continuing the conversation by highlighting and responding to this story.

Nowadays, most of the static web pages and single page web apps are hosted in AmazonS3 buckets and Amazon provides inbuilt functionality to gather server access logs for buckets which record user-agent, remote IP, and many more details. These data can be analyzed in order to identify user visit patterns and highly visited parts of the website which could be useful for marketing. Without any further ado, let’s see how we can crunch these data with Hadoop.

First, we need to copy the server access logs into HDFS. For this let’s use UltraStudio and create a flow to pull server logs from an S3 bucket and copy those logs into HDFS. If you are not familiar with UltraStudio, you can go through this video tutorial to get an overall idea about it. Let’s first create an empty project by selecting AWS connector and HDFS Connector and within that project, we need to create an integration flow named MainFlow.
After that let’s add an S3 ingress connector to the design pane and configure it as below.

In the above configuration, specify the region of the S3 bucket and specify the Access Key and Secret to pull the records from the specified bucket.

After that, add an HDFS Egress Connector specifying the hostname and port of the HDFS node as shown below.

Next, let’s connect an HDFS Payload Saver connector operation to the egress connector and specify its properties as shown below. We are going to save the log files into /s3logs directory in HDFS with the same file name.

After that, connect all the components as shown below.

Now after running the integration flow, all the files in the specified S3 bucket will be copied to /s3logs directory in HDFS.

Now let’s execute our map reduce job to find the visit count for each resource path. A particular server log entry would be as below.

83634ad2474abbbc5e3c1fa2cd1cef87b2bb814fd9accf63c7a85aa5a1acc2 beta.as2gateway.org [20/Nov/2017:07:31:29 +0000] 13.228.69.75 — BDB9C04019087152 REST.GET.OBJECT partner “GET /partner HTTP/1.1” 404 NoSuchKey 278–12 — “-” “Amazon CloudFront” -

As you can see, the resource path is under “GET /partner HTTP/1.1” section. Hence, we can write our mapper class as below.

For each line, we are going to evaluate the regular expression which captures the resource path within quotation marks and add it to the context. Next, in the reducer class, we need to calculate the total occurrence of each resource path as shown below.

The main method to run the job is shown below. Make sure to specify the correct HDFS URL for configuration and the result path to store the result file of the job.

The complete code of the map-reduce class is available on Github. After running our job, the result will be available on the specified result path in below format.

Likewise, we can write custom jobs to crunch remote IP details, visitor frequency and many other useful information.

Call To Action

• Clap. Appreciate and let others find this article.
• Comment. Share your views on this article.
• Follow me. Sajith Dilshan to receive updates on articles like this.
• Keep in touch. LinkedIn, Twitter

ReactJS has been popular among web app developers recently and a lot of websites has adopted the library because of the perks it provides. This post is not about pros and cons of ReactJS library, although you can find a myriad of articles and posts on the web comparing ReactJS with other front-end frameworks.

In layman’s term, ReactJS is a javascript library which handles the View component of the MVC architecture. ReactJS is used to manipulate the DOM of a webpage in an efficient manner to render a web application.

Creating Hello World App

First, let’s create our sample React app. For this tutorial, you need Node and NPM to be installed in your environment. After that, execute the following command to install the react boilerplate app creator.

npm install -g create-react-app

Next, we can create our hello-world app using below command.

create-react-app hello-world

Now if we look at the file structure within the hello-world app, there are three important files. Those are public/index.html, src/index.js and src/App.js files. In the index.html file you can see that there is a div with id root and in the index.js file below code segment.

ReactDOM.render(<App />, document.getElementById(‘root’));

This is the starting point of our app. Basically, react will inject out App component into the div with root id. Now you might be wondering, what is App component. If you look at the App.js file, you will be able to see the App component. In React it is the convention to name the Javascript file with the same name as the component.

React Component

Now let’s see what is a React component.

Above is the simplest component we can write on React. We create a JavaScript class for our component and extend it from Component class from React library (Note the import statement). After that, we need to implement the render() method. Prior to React 16, it was a must to return a single element from render method. But after React 16, we can return an array of elements. Now if we execute npm start command within the hello-world directory, we can see that Hello world is rendered in http://localhost:3000

React JSX (Syntactic sugar for JS)

In the render method of the component, we can almost use the HTML syntax. But in reality, this is actually JavaScript, specifically known as JSX. JSX is a template language which has a similar structure to HTML with the full power of JavaScript. Hence, you can evaluate any JavaScript statement within the render method.

As an example the JSX code we wrote earlier (shown below).

will be compiled into the JavaScript code shown below.

In reality, JSX was introduced to make developer’s life easier by providing a familiar syntactic sugar.

State vs. Props

Now let’s create another component named Alice under src/Alice.js file. The content of the Alice component would be as below.

Now we can include this Alice component as a child component in our App component as shown below.

Note the new import statement for the Alice component. Without that our app will break since React is unable to find the component which corresponds to the Alice tag.

Next, let’s see how we can manipulate the state of our components. For each React component, there is a state and by manipulating the state object we can change the behavior of our component. This state object is specific to the component.

As shown above, we can declare the state object within the constructor (Note that it is a must to call super() within the constructor of a React component). This state object contains greetings property with the value “Hello World!”. In the render method, we have used this property as {this.state.greeting}, and this is the usual way of evaluating JavaScript expressions within JSX. You can add as many properties you want to the state object. Now let’s see how we can pass data from the App component into its child component, Alice.

In the modified App component(shown above), I have added another property named parentMessage and passed it to Alice component as shown below.

<Alice newMsg={this.state.parentMessage} />

Note that newMsg is the key I’ve used to pass the data, for that, you can use any valid string. Now let’s look at the corresponding Alice Component.

If you look at the constructor of the Alice component, there is a method argument named props. This object contains all the data passed from the parent component (Input from parent component to the child component). I have initialized the state of the Alice component using the newMsg property passed from the App component. If you have used another string as the key instead of newMsg, you can access it as same as props.newMsg.

Now the app should be rendered as shown below (Figure 2).

Below table summarizes the basic differences between state and props objects of a component.

Another very important thing to note is that whenever we want to modify the state object, we do it through this.setState() method as shown below.

In the constructor, I have added a timeout function which modifies the greeting message to “Hello World Update!” after 10 seconds. DO NOT use this.state.greeting = “Hello World Updated!” to update the state as it would not work since React uses an event driven approach rather than using dirty checking to maintain the state of React components.

React Component Lifecycle

React provides highly valuable lifecycle hooks (method) for each state of the component as listed below. These methods can be classified into 3 categories mainly, i.e. mounting, updating and unmounting.

Mounting hooks are fired when the react component is initially being rendered in the browser page. Below methods are fired in the specified order.

1. constructor() - Invoked when creating the react component for the first time.
2. componentWillMount() - Invoked before adding the component to the actual DOM of the web page.
3. render() - Invoked when adding the component to the actual DOM.
4. componentDidMount() - Invoked after adding the component to the actual DOM.

Updating methods are invoked when the component is re-rendered on the web page. This happens due to changes in state/props objects. Below methods are invoked in the specified order.

1. componentWillReceiveProps(newProps) - This method is invoked when new props are received from parent component. Note that this method will not be invoked at the initial time when the component is created even though parent component passes props. The initial time should be handled within the constructor.
2. shouldComponentUpdate(nextProps, nextState) - This method is invoked before the component is re-rendered. It is a must to return a boolean from this method. If true is returned, the component will be re-rendered and the component will not be re-rendered if false is returned.
3. componentWillUpdate() - This method is invoked before the component is re-rendered in the actual DOM
4. render() - Invoked when the component is re-rendered in the actual DOM
5. componentDidUpdate() - Invoked after the modified component is re-rendered on the actual DOM

As for the unmounting, there is one hook named componentWillUnmount(). This method is invoked immediately before the component is removed from the actual DOM. Apart from that starting from React 16, there is another lifecycle hook named componentDidCatch() which will be invoked when there is an exception during any of the lifecycle hooks of the component. This method can be used to gracefully show an error message when a React component fails to function as expected. For more information on the component lifecycle events, take a look at the awesome react documentation.

Virtual DOM vs Real DOM

When applying the changes of a React component to the actual web page, React uses a virtual DOM to calculate the changes and then apply only the modified bits into the real DOM. Since React completely builds the virtual DOM, you might be wondering why not build the actual DOM instead. Re-building the actual DOM is quite expensive since the browser needs to re-calculate all the CSS properties, re-draw the canvas and fire all the event listeners unnecessarily. Hence, building the virtual DOM and applying only the difference to the actual DOM is quite efficient and this process is known as reconciliation. React implements a heuristic based algorithm to calculate the difference between the virtual and actual DOMs which has a time complexity of O(n).

As an example when rendering a component, initially both DOMs are empty (Figure 3).

First the virtual DOM is populated with the content (Figure 4).

Next the real DOM is populated with the content and the virtual DOM is cleared (Figure 5).

After that for any change, the complete virtual DOM is generated with the newly modified content (Figure 6).

Next the difference is calculated and only the modified section is updated in the real DOM and the virtual DOM will be cleared (Figure 7).

This sums up the basic introduction to the ReactJS and it is time for you to get your hands dirty and start building your first react app to get a first hand experience. In the next blog post let’s see how we can craft an elegant data flow between React components using Flux. Until then, happy coding!

Call To Action

• Clap. Appreciate and let others find this article.
• Comment. Share your views on this article.
• Follow me. Sajith Dilshan to receive updates on articles like this.
• Keep in touch. LinkedIn, Twitter

ReactJS for Noobs was originally published in codeburst on Medium, where people are continuing the conversation by highlighting and responding to this story.

Java Messaging Service (JMS) is an API which is capable of creating, sending and reading messages. JMS provides loosely coupled, reliable and asynchronous communication functionality. Hence, JMS is used in enterprise applications to integrate multiple systems together.

When it comes to integration, it is paramount to guarantee the reliability of the overall solution as to not lose any message which is passing through the solution. This is where the JMS transactionality comes in handy where you can read a message transactionally from a JMS queue and after performing all the required logic on the message you can either commit or rollback the message. In the case of committing the message, it will be removed from the source queue and in the case of rollback, the message will remain in the JMS queue for a successive re-try attempt.

In order to connect to a JMS queue, we need a JMS connection factory and the Spring binds the transaction of the message to the connection factory. Hence, we cannot span a single transaction among multiple JMS queues which are not connected via the same connection factory. Without any further ado, let’s dig into the code.

First, a Java class with the required thread local as shown below is required. If you are not familiar with thread locals, the best starting point would be the Java documentation of thread locals.

The txnStatus thread local is used to store the current status of the transaction. If we evaluate the thread local value during runtime, we will be able to see the content of the TransactionStatus object’s content as below.

In order for a transaction to be initiated, we need to wrap the connection factory with the Spring JMSTransactionManager. Further, we need to initialize the txnStatus thread local in the doReceiveAndExecute() method within org.springframework.jms.listener.SpringMessageListenerContainer class. Sample implementation would be as follows.

After that, we need to copy the thread locals from one thread to another. This is the tricky part. Of course, we can use reflection and directly copy the thread locals but in this case, we can use the JMS message as a context object and attach the thread locals to the JMS message from the initial IO thread. All the important thread locals which need to be copied resides within org.springframework.transaction.support.TransactionSynchronizationManager class and the resources thread local in that class plays an important role here. The evaluated value of that during the runtime would be as below.

As you can see, this is a map and the key is our connection factory and the value is a resource holder which includes the JMS session information. Using below code segment, we can obtain the resource map and clear the thread local from the current thread.

The savedResources variable can be attached as a property to the JMS message and later when the message is being processed by a new thread, we can obtain this resource and set it as the thread local value for the new thread by invoking the bindResource() method of TransactionSynchronizationManager class for each key, value pair in the savedResources map. After that, the new thread will be a part of the initial JMS transaction.

One salient point to remember is that it is vital to clear the thread locals at the end of the thread execution time if we are re-using the threads. As an example, when using a thread pool, it is mandatory to clean the thread locals before returning them to the pool. Otherwise, it would result in a thread local leak and unexpected behavior in JMS transactionality.

One of the biggest advantages of propagating a JMS transaction over multiple threads is that it will optimize the usage of IO threads which initially polls the message for a JMS queue. Usually, IO thread has to execute all the logic related to JMS message until it is committed or rolled back. If the intermediate logic involves time-consuming computations, it will negatively affect the message throughput of the system. By propagating the transaction, we delegate the computation logic to a new thread while preserving the transactionality of the message flow.

It seems like a lot to digest at first, but the good thing is that AdroitLogic’s Project-X framework provides all of this functionality out of the box and you can try it out by yourself using UltraStudio without writing a single line of code. There is a sample project which explains the JMS transactionality and you can create and run the project directly within UltraStudio.

Call To Action

• Clap. Appreciate and let others find this article.
• Comment. Share your views on this article.
• Follow me. Sajith Dilshan to receive updates on articles like this.
• Keep in touch. LinkedIn, Twitter

Dear Apple,

Couple of weeks ago I bought a Series 2, 38mm Apple watch from Singapore through a friend of mine. Don’t believe me? Here’s the receipt.

Needless to say I was so excited to use the watch, and at first glance it was truly a beauty. I wanted to wear this watch while I was at the gym, while playing badminton, while I was swimming and even during my evening walks.

But my expectations were shattered into pieces during the first week. I was wearing the watch while playing badminton and accidently I hit the watch with my racket. Below is the proof and the current state of the watch. I hit the lower right corner of the watch and the screen cracked into two sections. The best part is that the touch doesn’t even works on the lower part.

After that I knew the water resistance is long gone and sadly I’ve never even got to wear the watch at least once while I was swimming. I was truly astounded and disappointed by the lack of durability of the watch, since it is highly marketed as a sports watch and the Apple watch even has a separate Nike model which is promoted for athletes.

For a company who pays a lot of attention to bring the best quality products at a premium price to their beloved customers, I have no explanation as to why you didn’t make the screen of the Apple watch with more hard and durable material which can endure rough usage and maintain structural integrity.

After this incident I wouldn’t recommend anyone to buy an apple watch, if they are looking for a sports model since clearly you need to get your shit together and come up with a solid, durable watch and please stop deceiving people by saying it is the ultimate sports watch.

Kind Regards,

Sajith

When working with Phoenix framework, you need to create your data models and plug in your database schema to your app. If you are not starting your project from the scratch, there is a high probability that you want your data models to be adhered an existing database schema with unconventional column names. So without any further ado, let’s see how we can introduce custom column names in Ecto.

For this example, I am assuming that you have already set up your Phoenix app. If you haven’t yet, go through the awesome documentation of Phoenix Framework and create your app.

In this example, I have four tables, and those are Tenant, Group, User and Permission. Further, the primary key of these tables are auto generated, sequentially increasing integers. But the primary key column name will be ID (not the usual id). Figure 1 depicts the ER diagram of the schema. In the ER diagram, what I would like to highlight is the relationships between each table. There are many_to_many, belongs_to, and has_many relationships among the tables.

First, let’s create the migration. Below command will create a new migration file.

$> mix ecto.gen.migration sample_migration

The content of the migration file is as below.

Note that when creating tables, primary_key: false has been specified so that we can specify our own primary key. add :ID, :serial, primary_key: true specifies our custom primary key column. Since we are specifying a custom primary key column name, we need to explicitly specify the column name when specifying foreign key constrains [references(:TEST_TENANTS, column: :ID)]

Now let’s see the table schemas. Below is the Tenant schema

User schema

Permission schema

And.. last but not least, the Group schema

I will explain how the custom column names are supported using the group schema. First, we have specified @primary_key {:ID, :id, autogenerate: true} which denotes that the primary key column name of this table is ID and the type of the column is id. After that, schema “TEST_GROUPS” specifies that this model represents the table with the name TEST_GROUPS in the database.

According the the ER diagram, a group belongs to a tenant. below line represent that constrain.

belongs_to :TENANT, Test.Tenant, foreign_key: :TENANT_ID, references: :ID

But in this case, we need to specify that the foreign key column name is TENAT_ID. and the corresponding primary key column name in the tenant table is ID. Otherwise, when we run an Ecto query, the query will try to find a column name TENAT_id in TEST_GROUPS table.

Next a particular group can have many permissions. Below line represents that constrain.

has_many :PERMISSIONS, Test.Permission, foreign_key: :GROUP_ID, references: :ID

In here, we need to specify the foreign key column name in the TEST_PERMISSIONS table explicitly. Otherwise, queries would look for a column named GROUP_id. Apart from that, we need to specify that the GROUP_ID column in TEST_PERMISSIONS table refers to the ID column of the TEST_GROUPS table.

Finally, there is a many_to_many relationship between TEST_USERS and TEST_GROUPS table. Below line denotes that relationship.

many_to_many :USERS, Test.User, join_through: “TEST_GROUPS_USERS”, join_keys: [GROUP_ID: :ID, USER_ID: :ID]

Note that the many_many_relationship is maintained via TEST_GROUPS_USERS table and we need to specify it using join_through. Further, we need to specify the primary key column names under join_keys since our primary key column names are unconventional.

That’s it. Now the Ecto models are mapped with our database schema. Next, let’s see how we can execute a query with all this custom column names. Suppose I want to obtain all the groups of an user with a particular Id (e.g: 6) , then below query would do the trick.

Usually, the where clause would be user.ID == 6. But this will not compile since ID is in uppercase. Hence, we need to specify it within single quotes. This goes for all the other column names as well since all of them are in upper case.

Hope this blog post has been useful to you. Happy coding with Elixir+ Phoenix.

UltraStudio is a fully featured integration flow development environment for UltraESB-X. It is built on top of the world’s best IDE, IntelliJ IDEA, so you could have the best of both worlds. If you are already using IntelliJ IDEA, you can integrate UltraStudio into your IDE with just a few clicks.

With UltraStudio, developing a mediation sequence — or integration flow, as we call it now — is just a matter of playing around with building blocks — connectors and processors. Want to expose a HTTP endpoint? Just drag-and-drop a HTTP ingress connector from the palette and configure it. Want to convert the inbound XML message to JSON? Add an XML-to-JSON transformer and attach it to the connector. With the super-simple graphical UI, a complex flow that takes hours of design and hundreds of lines of code could come to life within a matter of minutes.

UltraStudio comes with hundreds of resources to kickstart your integration project, including a lot of sample projects to help you understand the new development flow. With a wide range of connectors for JMS, HTTP, FIX, AS2, SFTP, AMQP and other protocols, and processors to manipulate the messages flowing through the UltraESB-X, developing integration flows has become easier and more intuitive than ever.

Having said that, if you feel like writing your own processor or connector, you can simply go ahead and do it within your IDE itself since the underlying Project-X framework supports extensibility by nature. Further, you can run the flow you have created within the IDE, and trace the details of the message which went through each component to debug any possible issues in your flow as well.

Last but not the least, have a sneak peek at the following screencast on how to develop, run and test an integration project with the new UltraStudio by AdroitLogic!

Originally published at sajithdilshan.github.io on January 12, 2017.