What's the difference between Camunda and BPEL (Business Process Expression Language) and Where do we use Camunda and where do we use BPEL and which one is better?
I found this question, but BPMN != Camunda. So where is the difference between Camunda and BPEL?
Please see Jan's comment. The thread you already found is already good. You need to compare the two modelling standards, not an engine product and a standard.
BPEL was popular in SOA times, for service orchestration in full automated processes. BPEL can be excuted by a BPEL engine. There are different products offering this capability.
Early plans to be able to map BPMN 1.0 (Notation only, no model) mostly failed. This was one motivation for BPMN 2.0, which also standardases the model, not only the notation. Due to its block orientation and lack of support for human tasks BPEL did not cover all BPM/Workflow requirements. I would say BPEL is dying if not already dead. I would not spend time on it today. Of course that is a personal, biased opinion.
BPMN 2.0 on the other hand is a mature OMG standard, stable since 2014, works for a variety of process management and automation needs and has a wide and growing adoption.
Camunda offers process engine products, which interpret and execute process models based on the BPMN 2.0 standard. There are other product, which also use this modelling standard. engine specific attributes for process automation beyond the standard may differ between vendors. It depends on how closely the vendors are implementing the standard. See for instance https://www.omgwiki.org/bpmn-miwg/doku.php
Related
Intro
The company I work in (it is an intern-like position though, until I am done with university) recently implemented an automated warehouse solution, where goods are transported by means of autonomous shuttles. The basic functions of the shuttles are controlled by onboard electronics (microcontroller), routing through the warehouse racking is done by software solution which in turn communicates with our ERP solution. Effectively the ERP solution handles the whole warehousing.
Task
There are well documented processes for every of the four layers (operator who loads the the shuttles, shuttle itself, routing, ERP) individually. But since we kind of puzzled all four of them together to one solution (which was kind of new to all of the participating companies), there are only vague, on-the-flyish process descriptions involving all four layers available.
Now I have been tasked to come up with a solution to illustrate the processes at work.
Example
ERP signals goods in demand at assembly station A1
Warehouse operator looks at screen and starts loading boxes to be picked up by
shuttle
Warehouse operator puts in details into ERP, such as count/weight, box number,
...
Warehouse operator clears boxes for pick-up (by confirming inputs in ERP)
ERP generates transport order
ERP sends transport order to routing software
Routing software sends telegram to shuttle control
Shuttle control turns wheels and asks for directions to pick up boxes
...
Question
As mentioned, I have to graphically represent the kind of processes similar to the one shown in the (easy and not complete) example above. I need to incorporate the operator's actions as well as basic communication between shuttle, routing software and ERP.
Since I attended a course on BPMN at university it came to mind immediately. But now, after immersing myself into information about BPMN for several hours I still can't conclusively tell if BPMN helps my efforts or just further complicates the whole thing.
Is BPMN the right tool for my purpose?
Disclaimer
I am not a Business Analyst. I have looked at alternatives to BPMN (simple flowcharts, activity diagrams, ...) but they don't seem to fit.
Just putting together the existing processes for every respective layer yields no result, owing to the different and sometimes too detailed process descriptions.
Edit
The ERP is SAP ERP 6.0 EHP7 with integrated WMS component.
TL;DR: use the notation you would be implement process in, i.e. choose BPMS, not BPMN.
The notation itself means nothing unless it has proper tool for modelling and further process implementation aka BPMS. You can find dozens of comparisons (e.g. BPMN vs EPC or BPMN vs BPEL), however they won't help you unless you have clear understanding where and how you will be implement you modeled process.
Generally speaking, EPC is used for more high-level view of the process, whereas BPMN is utilized for more fine-grained view, where all technical details of communications between peers can be described. However, it depends.
I also recommend you to review this table
and answer the question to yourself whether your process changes (in)frequently or not, and whether you need separate BPM tool.
How I see it from your description: you have four participants (four layers), which are four lanes in BPMN terms, and they are collaborating/communicating with each other during the process. Generally speaking, this fits to BPMN application area, but personally I feel that you should stick your ERP tooling. I don't know which ERP you use, but every serious ERP solution includes tool for process customization. For example, SAP has Workflow,
which can widely enhance and extend existing processes within SAP. Probably, your ERP have it too.
Again, it's not clear which warehouse management system you use and if it is integrated to your ERP. It seems to be not, and it seems to be some old legacy system, because of which you start re-modelling the stuff. In this particular case it might me wiser to acquire special advanced warehouse management package (take a look at SAP's EWM features as an example) which can cover most of your requirements.
I am developing a business application and, provided that many companies look for integration, I would like to make it "compatible" with business systems like SAP or Navision. What mechanisms do these systems use for importing/exporting/syncing data with third-party applications?
There exist software tools known as EAI (Enterprise Application Integration) whose purpose is to act as middleware to enable the integration of applications across a company.
Apache Camel is an example of such framework, but there exist many of them. You can find a comparison list here: http://en.wikipedia.org/wiki/Comparison_of_business_integration_software
As the user nmiranda pointed out, in the case of SAP, the framework used for data interchange is SAP PI (SAP NetWeaver Process Integration).
I think your question was actually aimed to find this "starting point", wasn't it? I faced the same question some years ago and I also wondered if there was any "standard" interface to integrate applications. In such case, I hope have helped you.
There are multiple ways to integrate with ERP data sources. You can do batch integration where you setup a query that pulls the data from the source ERPs on a scheduled bases. ETL tools like Informatica and Talend shines on this front.
If you want online data integration when you want live data in your business application then you need to look at Data Virtualization solutions like Denodo, VirtDB or Composite.
Prices, feature sets, performance and flexibility highly differ. One distinguishing factor in my practice is security. Solutions tend to extract data into file system, which makes a problem when sensitive data is extracted. In real projects, implementors usually start a long process replicating the source system security objects in the target application.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Could not find an answer on this question, so would like to initiate this:
Tibco EMS vs. MSMQ vs. MQ.
How do these 3 technologies compare?
Which one is better and in which kinds of scenarios?
Specifically, I think to use one of these in SOA environment (.NET + WCF), where the scenario will mature over time.
I have one additional specific interest in the performance, which is important to mention. So, if given a choice, performance is of a critical priority.
I would appreciate to have a comparison table for a clear picture.
Thanks!
EDIT:
I am concentrated on two parameters: performance and scalability.
Scalability - how do these technologies compare in terms of supported concurrent users' count? which can support more users? scenario does not matter, let's choose the scenario which is supported by all them - e.g. simple queues.
Performance - in exactly the same scenarios, which performs faster?
If you want to use WCF than non of them really matters. You will get most of them only when you use their direct API.
MSMQ - MS technology installed with every Windows installation. It is only transport technology with support for queues.
Tibco EMS - Tibco technology supporting both queues and topics (publish/subscribe). It is expensive and more suitable for enterprise scenarios. You will most probably need other Tibco tools and technologies as well to implement full SOA solution (Tibco ActiveMatrix product suite). .NET and WCF will be only apps connected to this infrastructure which is more designed for Java world. It runs on non Windows platforms as well and together with Tibco Business Works it offers connectors (adapters) to many LOB applications. I like APIs for Tibco products but I really don't like UIs of their tools.
IBM MQ - IBM technology supporting queues and it also somehow emulates topics (publish/subscribe). Again it is expensive commercial solution more suitable for enterprise scenarios where mainframes are involved - that is biggest MQ advantage - it runs "everywhere". But that is end of advantages. APIs for both Java and .NET are terrible. .NET API is full of bugs and it doesn't work as expected. IBM doesn't understand .NET libraries versioning which leads to terrible problems when moving your client application to machines with different MQ clients installed, etc.
Edit:
There were several question / comments about what problems MQ has? As few examples you can check my MQ questions. Not every question is actually an issue but you will find few of them pointing directly to bugs. Those issues can already be fixed in new MQ client versions but that doesn't mean there are no other. Generally I found MQ .NET API the most frustrating library I have ever used - it even beaten hated SharePoint.
On the other hand if you just need to send and receive some message and don't plan to do anything special or use low level features you should be OK. At the end the API is used for a while and common use cases should work - if you are not happy enough to hit regression bugs.
For a simple integration scenario - i.e. 2 applications interacting in a Point to point manner , no difference will be there. You would better check the support of each technology within your applications. And in that type of scenarios, you shouldn't be worried about performance as the messaging time shouldn't be the main issue. On the other hand, the real selection would be based on the target model for integrating your whole enterprise. For example,
- Are you doing any mediation functions - e.g: data transformation, protocol mapping ...etc
- Will you integrate systems in a point to point manner or you may consider having a Hub / ESB?
- Will you cover security aspects in your integration scenario (Authorization, authentication, auditing, encryption, certificate exchange ...etc)
Finally having such vision will give better understanding of what real constraints you've for your design. Personally, I would go for WCF only if I'm not expecting complex integration scenarios and I'm not willing to spend money on the solution. And I would go for IBM if I'm building a foundation for SOA. And will go to Tibco if I'm planning a Java based integration with a defined scope.
Again it is expensive commercial solution more suitable for enterprise scenarios
where mainframes are involved
Not sure why you mentioned mainframes. Many MQ enterprise customers don't have them.
IBM MQ - IBM technology supporting queues and it also somehow emulates
topics (publish/subscribe)
MQ v7.0.0 (released 2008) and onwards supports pub/sub topics as a native feature, there is no emulation involved.
APIs for both Java and .NET are terrible.
The MQ Classes for Java and JMS have evolved over 10+ years and are used heavily by thousands of enterprises.
.NET API is full of bugs and it doesn't work as expected.
The .Net API has been around for 7+ years over a few major releases of MQ. I would imagine that the obvious bugs would have been shaken out by now.
I am concentrated on two parameters: performance and scalability.
MQ has unlimited scalability. Performance is very good even with no tuning.
MQ is best only if you need to integrate with lots of mainframes. Pub/Sub is implemented poorly and the many APIs are 'strange to use'.
If all your applications are Windows, MSMQ might be a good choice, but it will be difficult to bridge into Unix or Java worlds.
The whole Java community standardized on JMS so TIBCO EMS is a good choice if you ever want to connect non-Windows applications.
Hello All
I am planing to use Nhibernate in Dotnet 3.5 application.This application is like an enterprise application which will provide core services to all other application of my company. So my question is:
Is Nhibernate is right choice with this kind of application?
Are there any performance issues with Nhibernate?
NHibernate is good for any kind of data access applications.
As for performance its good enough for most of the apps. The only thing where I think it won't fit is synchronization tasks where really tons of data could be transferred. For that kind of work any ORM would suck.
I know of many places that use Nhibernate for Enterprise and mission critical application and are satisfied.
Nhibernate supplies an object oriented abstraction to data base entities. if you're comparing them to equivalent SQL operations, the performance penalty is negligible.
However, when using more complex operations, mainly on large sets of data, native SQL may perform significantly better.
NHibernate is the probably the right choice. The library is very mature (currently v3), based on java Hibernate which is there for even longer.
It depends. NHibernate is designed for OLTP scenarios. That means you load some small chunk of data, process it and you save it back. Critical part is: "small chunk".
If you find yourself in any OLAP-like scneario where you must batch process large chunks, NH is not a good choice. In such situation you most likely don't want to use any ORM at all.
As always: Right tool for the right job.
If your application is a typical enterprise like, you will be happy with NH. The library is extremely flexible with many fine-tuning options. Also remember that you can still use plain old ADO.NET in OLAP parts of your app if there are any.
If you run into any problems, NH community is very supportive plus there are companies and individuals offering consulting and paid support (in case your company policy requires it).
I'm using NH for 3 years and I can recommend it - the tool does its job.
As it is included in the license (according to SAP) we would prefer using Solution Manager over other tools, for the entire life-cycle of software development. Or is it highly recommended to use specific tools for the particular processes like Test Management? Any opinions?
in general before answering this question, please be aware that SAP will bring out a new support model and the features and functions available in your SolMan installation will differ according to the support you requested from SAP. If you stick to the Enterprise Support you will (nearly) get every functionality, for Standard Support you well get less and a lot of features will not be included. At the moment, SolMan 7.10 is in Ramp Up Phase and 7.20 will be released in 2011. Due to the fact, that SAP changes the kernel of the Solution Manager Stack, which is apparently CRM from 5.0 to 7.0 you should keep in mind, that any functionality you implement in your current SolMan will lead to high migration efforts.
Apart from this, if you look at the Enterprise version, my experience is that not all features are rather good and suitable. It also depends on the organization you are working in. The SAP tools focus only on SAP, so if you are working in an environment where non-SAP Java has an important part I would look for different tools. If you look into the change management (ChaRM), it is suitable for small landscapes and for big ones only with some effort. Here you should also consider at least to have a look at different technologies and tools. From my point, there are some things like monitoring, job scheduling etc. which are quite good, but for the more general application lifecycle management tools you should at least take other options into account.