TIBCO Integration (including BusinessWorks and Flogo)

Solutions built with BusinessWorks are flexible

Learning curve is not too steep

Seamless integration, development, testing and deployment

Reduce time to market for any deliverable

I would like the design time to improve and match that of the designer. The newer versions are getting better.

Would like to have web app development and deployment possible through BusinessWorks design time like we had with AMSG.

BW helps create web services pretty easily

BW works well with almost all messaging protocols especially JMS/EMS

Packaging projects for deployment is effortless

REST API in 5.X needs improvment

Very strong in messaging

Unique platform which supports Microservices and Cloud with enterprise integration

Extended support and OOTB integration with APIM platforms and Event processing

OOTB Analytics support on integration BW

Upgrade from BW 5 to 6 is difficult for customers, which requires redesigning and sometimes re-coding the Integrations to support containers. Need to make it easy

It provides a palette which makes it very easy to map data from one format to another and do calculations or transformations as part of the mapping.

The pallets make it easy to get different listeners and publishers stood up very quickly.

It is easy to deploy and manage on application across multiple machines.

It provides consistent code across multiple development teams, as there are code is presented as an activity which is simple dragged and dropped.

In BW 5, there is no native JSON parsing, it must first be converted to XML which adds overhead. Native parsing was just added to BW6.

Some settings must be editors in a tea text file, and are not editable as a part of the deployment.

Nice graphical user interface and works on any platform. Easy to develop/deploy for a programmer.

BusinessWorks is forward and backward compatible.

It would be helpful to get more plugins (e.g SFTP/REST Plugin) out of the box.

Scribe Online seems a great product for replication. It manages the metadata challenges. If you don't customize Salesforce this may not be that big a deal to you but if you customize Salesforce like we do then you will appreciate how replication can adapt to the changes. It checks for changes and will automatically update the underlying SQL or whatever provider you use to replicate.

The documentation is pretty well laid out and the configuration is simple. We established new firewall rules for greater security so we needed to lock down our WAN connections as tight as possible. The documentation was quite thorough on this and we were able to make changes based on documentation alone. All other documentation on a given area seems to explain what is needed.

The agents used on-premise that work with Scribe Online work well most of the time. The configuration is simple to setup and manage. The documentation as mentioned is clear so easy to quickly implement and get the process rolling.

We have had communication problems that lead to errors that are hard to troubleshoot. Sometimes the errors are not clear what caused them nor how to clear. The support team has struggled with some of the errors as well. Most of these difficult issues seem to be tied to WAN connectivity. The processes have improved and are more robust than they used to be.

Some of the Salesforce errors we still do not have an answer for. I am not on Salesforce team and not an architect of that system but some of the errors seem related to metadata and object relations. I have mentioned the errors to Support and they seem to struggle with how to answer sometimes. I have learned to try things in the data to work around problems. But then I have worked with many tools and very comfortable doing this.

Engineering needs to bulletproof replication and make it easier to clear up issues without hurting the replication process. Mind you one of the best things is this product manages all object changes in Salesforce keeps it in sync with your destination system. But in the past, we have had issues that break the process. Support has been unable to correct a couple times and we had to recreate replication in a new process. We have done massive customization to our Salesforce system so replication has been particularly challenged. If a company does not customize much with custom objects and classes then I would think replication would be very stable. We have not had any issues in over a year so the stability has definitely improved when it comes to this. Perhaps the current product has no issues and our previous problems were only with older versions.

TIBCO Business Works does field mapping well. I often have projects that include ERPs like SAP, which can often use large and complex XML schema. BW makes it easy to map fields between these cumbersome documents, loop over repeating nodes, apply xpath... I think this is where BW has the biggest advantage over other tools.

BW also makes it easy to establish logical flow. When it's just code on a page, you have to rely on UML diagrams. BW offers an icon based designer to design the logical flow, which is pretty nice and intuitive.

TIBCO BW runs very efficiently. People are often surprised at how quickly our systems move, especially when components like the database adapter are used. We have many integrations quickly moving large amount of data.

Training developers new to Tibco BW5 easy. This might be my favorite thing about it these days. If someone already has experience with app development, or is otherwise familiar with business processes, sql, xml, ems, etc., BW5 is very easy to be productive on.

General development time on BW5 is quick. From a business perspective, I would say this is the strongest advantage. Creating new processes and making adjustments is fast and reliable -- not prone to creating new issues.

When discussing needed improvements to BW, we have to make a clear discrepancy between BW5 and BW6. BW5 is stable, tried-and-true, and easy to train people on. BW6 is the total opposite. Also, BW6 offers no significant advantage over BW5. I began using BW6 almost two years ago now. Our original intention was to make use of its REST activities first thing, then transition all our processes to BW6. Today I still only use it for REST, but I don't use the REST activities because they can't do complex queries. I have to use HTTP activities... We also have NO plans to move anything other than REST interfaces to BW6.

The main issue with BW6 is the dreadful bugs. It's a sophisticated system but very immature, so it's loaded with dangerous surprises. I even took the BW6 bootcamp class, intending to get a good start. But the class was mostly worthless because the instructor couldn't even run the example solutions. We just fumbled though numerous introductions to features. The best advice I can give is, first learn BW5. Then, if you really want to learn BW6, go ahead, but don't use it for any projects with critical deadlines. Also, push to the repo often, and understand that your workspaces are basically disposable. Things go wrong that just aren't worth all the XML editing to fix, so it's better to just backup an hour or two and start again. Also, delete and recreate if anything starts to act funny. When the designer crashes, start it up, shut it down, then start it up again. Also, you're not alone. Everyone knows this thing is buggy.

The BW6 designer is built on Eclipse. I was optimistic about this, and anticipated a more efficient interface compared to BW5's designer, which is clunky. BW6 designer looks more slick, but it offers no real advantages over BW5, and is heavy and unstable. It crashes often, is painfully slow, corrupts project files, and otherwise requires a lot more time than BW5 for even simple tasks.

Testing is more difficult on BW6 than on BW5. Setting up a whole integration and running it locally is an easy task with BW5. Things run quickly. It's easy to see the input and out put data from each process. Errors are quickly evident. BW6 -- just getting it to build and run can be difficult. The big issue is that there are numerous run time hazards that BW6 will not indicate after compilation. You just have to run the thing and sift through terminal output. Here's a tip. It always say every process is imparted. The gobs of red text that poor out, that's normal and OK. Neither of these sections are describing your error. Your error will be in black text somewhere.

Once you get your integration running, examining the input and output is challenging. The designer will take your focus for various reasons. For example, if you have http debugging enabled, you simply can't look at anything else. The focus is repeatedly returned to the standard output terminal. Or, even with minimal debugging and nothing trying to grab focus, just digging up the data can be difficult, especially if you're dealing with large objects. You can't click on an activity to see its output, as with BW5. You have to sift through the nested lists of processes and down into activities. It's actually hard to even explain how to see input/output without an image.... But you can't really even see the data from within the designer itself. You have to copy it out and paste it into a text editor.

Integration of applications

Deployment

Use

Hot deployment

Security aspects are made easy

Easy programming

Code reuse

Well documented

Extending the choice of adapter

Multilanguage being

Create a plugin for automatic job creation

Cloud based system

Ability to map fields

Interface was able to talk to multiple systems.

Updates were slow to propagate.

Mappings were expensive as it needed to be done by a consultant.

Error handling wasn't very good.

As a middleware, it can be integrate with different IT technologies

It offers a design-time platform that helps customers to build up services and process really fast

The runtime offers a easy deployment and scalability of EARs

BW 6 is still young product and it suffers in stability

The TEA doesn't offer the flexibility to manage the bw 6 applications

BW 6 design time platform is not stable and fast as it was the designer for BW5

Extremely flexible

Quite reliable

Notably powerful

It is extremely complex--we work with ON24 for all of our configuration

It does not come--at least as we have been using it--with preset templates for logical use cases

Does not proactively provide information about errors as would be more useful.

BW uses its own JVM container, which is highly scalable and portable

BW is very configurable and high performing

BW is very analogous to the microservice implementation concept and smaller in foot print than the typical J2EE app server containers

Startup time when instrumented with JVM monitoring software

XML-based configuration is great for separation of logic with TRA run time, but the parsing and traversing could be time consuming.

Reduces the number of trivial tasks that are often associated with other programming languages.

Enterprise friendly for both multi user development and deployment solutions. Also fully capable of running a highly available infrastructure.

Extensible out-of-the-box and through plug-ins.

BW 5.x and the run-time agent both feel very dated, though this has been addressed with BW 6.x.

BW 5.x is not as friendly to CI, though this has been addressed with BW 6.x.

While the tool doesn't require specific programming language knowledge, it is still necessary to become familiar with BusinessWorks which is most effective with training. This does require that developers to have knowledge of the tool and has lead to some difficulties finding skilled software developers.

Easy to use and faster to develop applications

Fault tolerance / high availability for application is easily configurable

Easy to administer the application via GUI

XML parsing options are limited via palettes

TIBCO is easy to use and understandable even for people with little experience in programming

Possibility to integrate different technologies and platforms

You can create applications (even as uilities) in less time than a complex programming language

Some add-ons might be easier to find (e.g. plugin rest for TIBCO BW 5.9)

The possibility to cancel the last actions performed (such as CTRL + Z)

It is a very good integration platform. Easily used to model a business process and integrate data sources and services.

It is easy to learn and one does not have to learn a different programming language. It provides loads of built-in services that are dragged and dropped to build processes.

Deployment of its services are very simple and well managed my the administrator.

It integrates very well with other TIBCO software to build more robust development platform.

Extension of build-in services/APIs.

Improvement could made in its integration with iProcess.

Improvement is the information logged by the inbuilt-services in cases of errors.

TIBCO allows creation of a good integration between lots of external systems

TIBCO BusinessWorks includes the most complete suite of messaging infrastructure

TIBCO has many adapters that can integrate with lots of legacy, standard or cloud applications

Tibco’s Graphics

Simple commands

Have more examples for the most difficult configurations

Good support for various modes of communications, Java JMS, Tibco EMS, HTTP, Restful, SOAP etc. With easy to develop interfaces.

Acts as a good data transformation layer with excellent interfaces for cross mapping the data with easy to implement new custom x-path functions and complex data mapping between the complex XML structures.

Easily Scalable

Needs more support to customize SOAP interfaces. Although the SOAP based interfaces are very easy to implement, they are not Java like. It is hard to add any custom headers, need to define new port to allow the SOAP clients to download and the wsdl etc.

I am using BW 5.13, Restful support is not available out of the box in this version. Although the parallel version BW 6.x has the support for restful interfaces, BW 5,13 needs a new plugin. Which is annoying and expensive.

Most databases and SQLs has been supported by TIBCO. But still they cannot support a prepared statements with "in" clauses like "select * from employee where workplace in ( ?, ?, ? ... )". TIBCO needs to implement the in clause more cleverly where the developers can have any number for values in the "in" clause.

I have to either write a database stored procedure or use SQL direct for this purpose. I have SQL direct as this is tagged as a security vulnerability and we have no track of what sql is been executed ?

Very stable, scalable, powerful

Robust

Easy to use

Intuitive UX

Extensions like the way - Mulesoft provides

Cloud-based integration

Entire E2E architecture solutions

Giving access to the internals of the product like the way Mulesoft provides

Exceptional handling - like in Mule 4 beta version

BusinessWorks helped to integrate all our backend systems seamlessly.

Gives the highest performance ever seen with any other products. Helps to complete a single transaction in a fraction of milliseconds.

Easy to develop, deploy, debug and maintain the code. User-friendly tool.

Due to its high pricing, it is losing many customers.

Graphic implementation

Model development

Can be "0" coding

limited model available

too expensive to buy a model

not good at auto testing

TIBCO is very easy to use. User friendly.

Trouble shooting is very straightforward. You can figure out the issue from designer very easy.

If something goes wrong with the process, it is easy to reprocess the data most of the time.

TIBCO is a pretty expensive product.

It seems like there are a lot of issues for BW 6 so far.

Ease of Integration between different end systems.

Less Development time and time to market delivery.

Good knowledge base community and product support

Proxy parameters while using REST pallets.

Better memory management using TIBCO designer.

Room for improvement in logging. More meaningful or logical errors which can give more ideas.

BusinessWorks designer is easy and intuitive to use.

It's very easy to make web services.

Improve the Java code invocation from BusinessWorks.