we're looking for a GUI-based development tool for Activiti processes in order to reduce the formal development tasks associated with the XML configuration and Java support. Ideally we want to end up with any changes (config and functional) being GUI-driven so as to reduce the requisite skills for support. This leads me to believe we're after something like the functionality used in Oracle SOA Suite/Jdeveloper or Mule, whereby we can create the backend logic via the GUI and not have any re-development or code changes as such - the config will be done on a high-level via a designer using wizards or the like.
We have looked at the Activiti Eclipse plugin properties, and decomposing existing BPMN diagram files to their XML and modifying it manually, but this still requires generation of the service classes to support the process.
Does anybody have any experience with this type of requirement or any designer front-end for the process that uses wizards or dialogs for auto-generating the supporting backend?
Creating backend logic (this means Java) via GUI is not something activiti is intended for. You can create the diagram with several tools and this can be done for non-IT people. But you have to implement Service Tasks by yourself.
Related
I'm working on multiple projects where most of them include SOAP services that i have been testing using SOAPUI open source, creating multiple linked steps, using groovy script and so on.
However when it comes to complicated TCs & reusing , it doesn't seem to be so efficient
So a colleague of mine suggested that we can generate WSDL client using any IDE like eclipse or intellj , and thus we will be able to invoke methods found in WSDL directly with a much more privileges & control.
My question is what can possibly go wrong with that, i believe there's a reason why SOAPUI have been around for so long and most commonly used tool when it comes to web services testing.
I may be a little biased, but after using soapUI for 10+ years, I haven't found many web service test cases that it isn't able to handle, from simple calls to complex orchestrations and validations involving both REST and SOAP services. But, like any comprehensive tool, it takes time and effort and some trial and error to become proficient in its use. It also has some quirks and annoyances, but less than most of the tools in my development toolkit IMHO.
See the soapUI tag page for some resources that may help get the most out of soapUI.
It you've reached the limits of OSS soapUI, try the paid version: soapUI Pro/Ready API. The additional feature set is significant, including better support for reusing Groovy scripts and a script editor that some intellisense to help write code.
I would fully exhaust the the capabilities of soapUI and soapUI Pro before I would remotely consider trying to write my own web service client.
After evaluating existent tools like Ansible Tower, rundeck and others, it seems that no tool can fulfill the needed requirements.
We have complex data-center servers, cluster of DB and web servers, the data-center has a lot of client-systems, +100, and other tools like solr, redis, kafka... deployed there across the physical servers, not to mention that the same data-center servers have different accounts, linux users, (QA,stag,production..etc), for now the meta-data about these environments alongside their web-apps, source code to be used, servers of the cluster are all defined on xml and there is a bash scriptsreads from that XML that operated manually to run any operation/task (like checkout the source, build, deploy, start, stop... and other customized operations)
This system should be done with a developer and DevOps engineers together, but what I want to know, is there any preferable framework(s) that could be used for this system? does the workflows frameworks are usable on this case? e.g, Activiti BPMN? the Ant is an option but we don't need just an automation tool more that scheduler and logging and a lot of other services.
And if this is not the right place, can you please point out where cat I ask such question?
What's required is to create a web-based system as automation tool with:
UI to define the specific operations to be done, like build, deploy across the cluster specific web-app on specific env, start/stop specific web-app on specific machine, or any other customized operation, with multiple selections and flexible and dynamic options choosing way.
The FE should show the executing workflows and operations within them.
Dynamic way to create set of operations as a single workflow, that have dynamic ability to set the dependencies among them.
An interface between the back-end code of this system with the already existent bash scripts that will do the actual tasks across the DC servers.
A scheduler to be able to organize these operations in respect to a defined complicated dependencies between the workflows.
Authentication & authorization services to the users since there will be a lot of customized roles upon the operations,environments, the products...etc
Logging system to save the operations outputs.
Why not use a combination of ansible/Docker and jenkins, Jenkins can do most of the stuff you described using Pipeline projects/MultiProjects and Ansible for your UI and role related details
The task you're describing is basic network orchestration, and there're a bunch of orchestration engines/software out there. However, the fact that you are asking this question means you're just starting out and not ready to invest in a full fledged management product yet.
I strongly suggest that you take a look at Chef for your purposes.
Hope this helps.
I would recommend you to take a look at jenkinsx.io if you are targeting kubernetes and containers (docker). As part of the activiti bpm team we are trying to align with such technologies to make people life easy to integrate more complex workflows with DevOps and operations of your projects.
I'm currently starting to integrate "Delphi Web Script" in my application basically only as a scripting engine (interfacing with functions, classes, etc.); awesome software for the standard delphi open source quality in my opinion, but just for curiosity,
What's exactly the "web part" of the project?
How is intended to be used?
It was used somewhere with some success commercially?
Thanks!
As ain said, the original use was for PHP-like, ASP-like server-side web-page generation, but it was also capable of general purpose use, which is what I used it for. And as I did not use the "web" side of DWScript, most of the "web-oriented" features haven't been ported over (only the HTML Filter was ported actually).
The Web functionality is still available in the SourceForge repository, if someone wants to tackle the port. Though, they may be outdated beyond simple renamed methods and classes, as since DWSII, the script engine has gained various features. For instance, it is now capable of multiple thread-safe executions of a single compiled script, while the old codebase is built around the limitation that a compiled script can be executed by only one thread at a time.
On the other hand, there are some new features that could simplify the porting, the simple WebServer demo recently added uses RTTI to expose TWebResponse & TWebRequest f.i. (was manually exposed in DWSII). On the down side, that's only possible with recent Delphi versions.
AFAIK the main focus of the original author of this scripting engine was to make it possible to embed Pascal scripts into HTML pages, just like ie PHP does it. Hence the name "Delphi Web Script". While the focus of the current maintainer, Eric Grange, is on using it as a general purpose scripting engine, it should still be possible to use it for web purposes as well - for that you use the "filters" feature of the library. Check out the dwsHtmlFilter unit for HTML filter.
I started digging into the liferay 6.x ServiceBuilder framework and really liked its code generation approach. A simple service.xml file can generate ready to use powerful services without even writing a single line of code.
I also tried looking into AndroMDA which can generate similar services from the UML model, which sounds even more interesting since it will link my business model directly without me needing to learn a new xml config for service.xml (in case of liferay ServiceBuilder)
now I am in the process of deciding which tool should I use. Based on your experience with any of these tools Please let me know what are Pros/Cons of using any of this library,
I am interested to know these aspects, along with your own thoughts
Which is better to keep my development more productive in long term.
If I use ServiceBuilder will I be able to use the services outside portal env (lets say running same service from a non-portal app server.
Is UML driven approach always good or there are some practical cons/challenges of it.
Do you know of any other code generation library which is better than these two for liferay 6.x development? I also checked these SO Threads
Do You Use Code Generators
Java Code Generation
Following few problems I have experienced with Servicebuilder (I am using liferay 5.2.3) :
Not able to make use ORM framework. There is no way to generate
relations among objects. Because of this I am effectively working
just object mapper. It is not generating onetomany kind of relations
Can not use basic object oriented things like inheritance with domain or services
It is quite hard to write unit test cases
I still didn't understand what is the need of complex domain structure
I feel the code it is generating can be quickly written using an IDE
But definitely it has its own benefits like Egar said, it is specifically made for Liferay. So it can quickly generate everything that is needed for liferay. I heard in latest versions of liferay few of above problems are fixed.
Overall it depends on your requirement. If you need more control over your ORM layer and you have complex business logic which needs quite a lot of unit testing, go for normal spring services which can be exposed as webservices or REST services to your portlets.
Otherwise service builder is also good for simple portlets. Other approach could be using both. All complex services as a separate project and simple ones with service builder.
There is an important fact that you should be aware of. ServiceBuilder has been used to help building the portal itself and it is tightly integrated into it. You cannot use it outside of Liferay...I mean it probably could be taken and modified for general usage, but I doubt it would make sense.
Most importantly because Portal and each plugin that you are developing have their own web application context in a servlet container - each has its own classloader. Plugins are using Portal classloader and portal services, etc. etc.
Simply put, ServiceBuilder generated code and spring context can exist only if there is a webapp/ROOT/ which is Liferay Portal with portal classloader etc.
AndroMDA is a MDA framework for general usage. I don't know it much, so that I'm rather not going to make comparisons. The power of ServiceBuilder is that it is not a framework for general usage - the more powerful it is for liferay plugin development.
Nowadays I hear a lot about "Groovy on Grails" and I want to know more about it:
What is Groovy?
What is Grails?
What kind of applications are built using Groovy on Grails?
What is Groovy on Grails?
It doesn't exist under this name anymore. It's simply called Grails now.
What is Groovy?
Originally, a dynamic language for the JVM. However, since Groovy 2.0, both static and dynamic typing are supported.
What is Grails?
Grails (previously known as "Groovy on Grails") is a programming framework based on Groovy and inspired by Ruby on Rails (there are differences, but there are lots of similarities too). Like RoR, Grails promotes "coding by convention", development best practices, and is meant to be highly productive.
What kind of Applications are built using "Groovy on Grails"?
Grails is used to build web applications that run on the JVM.
What are the advantages of Groovy on Grails?
High productivity, focusing on business instead of plumbing. (Note that I wouldn't recommend to use Grails with an existing data model. The reason behind this is that Grails encourages a top-down approach where the databases ER model arises as result of the Domain classes. If you are using a legacy database, you cannot take this approach. You must map the database to the domain classes, and probably the naming convention won't match, making necessary the use of hbm.xml Hibernate configuration files or annotations. IMO, this is not a trivial change in the workflow, it can become really cumbersome and you end up losing most of the advantages of Grails.)
Why would one want to use Groovy on Grails when we have standard programming languages like C/C++, Java/J2EE, and .NET/C#?
Because of point 5.
Groovy is an object-oriented programming language for the Java platform. It is a dynamic language with features similar to those of Python, Ruby, Perl, and Smalltalk. It can be used as a scripting language for the Java Platform. Groovy has a Java-like syntax and works seamlessly with Java bytecode.
Other features include:
Easy learning curve
Support for domain-specific languages
Compact syntax
Support for dynamic typing
Powerful processing primitives
Ease of Web application development
Support for unit testing.
Grails is an open source web application framework which uses the Groovy programming language. It is intended to be a high-productivity framework by following the "coding by convention" paradigm, providing a stand-alone development environment and hiding much of the configuration detail from the developer.
Like Rails, Grails seems to be what I call "Strongly Grained". If you do things the Grails way, development is easy (and generally quite fast). The framework tends to have a preferred way of doing most things. On the other hand, if you need to go against the grain, you'll have a comparably rough time of it.
And don't say Groovy on Grails(doesn't exist), for reasons refer to this blog.
Grails is directly analogous to Ruby on Rails, but running with Groovy. What's Groovy ? It's a scripting language that runs on the Java Virtual Machine (JVM).
So you can make use of Java libraries that you already have or are available (since they're compiled to bytecode and thus run on a JVM), plus the power of the JVM (for garbage collection, speed via JIT compilation etc.) and the conciseness of Groovy. The learning curve for a Java programmer to pick up Groovy is supposed to be pretty small (thus leveraging off the huge number of available Java programmers).
It's a very different way of creating web apps to the standard Java mechanisms of servlet programming, JSPs, Java Server Faces etc. Grails (like Ruby on Rails) promises a more dynamic and iterative development environment than the standard development mechanisms (whether that's true in practise, I can't advise)
Grails- MVC framework for developing a web application and a ready to code platform with DRY (Don't repeat yourself) built on the top of Spring+Hibernate. Grails platform takes care of the infrastructure and dependencies to run a web app such that the developers can concentrate on building the functionalities for the product. Grails -a great framework for the startup organizations to launch the product from the development mode to production mode.