automatiko-io / automatiko-engine

Automatiko workflow engine to build services and functions
https://automatiko.io
Apache License 2.0
73 stars 8 forks source link

Codegen error during build with DB persistence #445

Closed deepakkapoor23 closed 1 month ago

deepakkapoor23 commented 1 month ago

[ERROR] Failed to execute goal io.quarkus:quarkus-maven-plugin:3.11.0:build (default) on project automatiko-examples: Failed to build quarkus application: io.quarkus.builder.BuildException: Build failure: Build failed due to errors [ERROR] [error]: Build step io.automatiko.engine.quarkus.deployment.AutomatikoQuarkusProcessor#generateClassesFromResourcesStep threw an exception: java.lang.IllegalStateException: src/main/java/io/automatiko/serverless/Hello_world_1_0Model.java:19: error: '{' expected [ERROR] public class Hello_world_1_0Model extends io.automatiko.engine.workflow.JsonModel, io.automatiko.engine.addons.persistence.db.model.ProcessInstanceEntity {
[ERROR] ^ [ERROR] at io.automatiko.engine.quarkus.deployment.AutomatikoQuarkusProcessor.compile(AutomatikoQuarkusProcessor.java:609) [ERROR] at io.automatiko.engine.quarkus.deployment.AutomatikoQuarkusProcessor.generateClassesFromResourcesStep(AutomatikoQuarkusProcessor.java:198) [ERROR] at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [ERROR] at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) [ERROR] at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) .builder.BuildException: Build failure: Build failed due to errors [ERROR] [error]: Build step io.automatiko.engine.quarkus.deployment.AutomatikoQuarkusProcessor#generateClassesFromResourcesStep threw an exception: java.lang.IllegalStateException: src/main/java/io/automatiko/serverless/Hello_world_1_0Model.java:19: error: '{' expected [ERROR] public class Hello_world_1_0Model extends io.automatiko.engine.workflow.JsonModel, io.automatiko.engine.addons.persistence.db.model.ProcessInstanceEntity {
[ERROR] ^ [ERROR] at io.automatiko.engine.quarkus.deployment.AutomatikoQuarkusProcessor.compile(AutomatikoQuarkusProcessor.java:609) [ERROR] at io.automatiko.engine.quarkus.deployment.AutomatikoQuarkusProcessor.generateClassesFromResourcesStep(AutomatikoQuarkusProcessor.java:198)

The generated java class looks to be extending two classes which is obviously the issue here.

@jakarta.persistence.Entity(name = "HELLO_WORLD_1_0") @org.eclipse.microprofile.openapi.annotations.media.Schema(name = "CompletedatamodelforHelloWorldWorkflow", description = "Describes complete data model expected by Hello World Workflow") @io.automatiko.engine.api.codegen.Generated(value = "automatik-codegen", reference = "hello_world", name = "Hello_world_1_0", hidden = false) public class Hello_world_1_0Model extends io.automatiko.engine.workflow.JsonModel, io.automatiko.engine.addons.persistence.db.model.ProcessInstanceEntity {

public Hello_world_1_0Model() {
    super();
}
...

}

I am running Automatiko 0.34.0 with Quarkus 3.11.0 with automatiko-db-persistence-addon and quarkus-jdbc-mssql and I have a simple two state hello world serverless workflow

And I have the following properties defined along with db user, pwd and url

quarkus.automatiko.persistence.type=jdbc quarkus.datasource.db-kind=mssql

mswiderski commented 1 month ago

looking at the stack trace, seems that you use serverless workflow example which is essentially not developed any more - I mean in automatiko - it was done as proof of concept but turned out to be dead end. No interest at all in it plus the spec itself does not to be much alive either. So automatiko support for server less workflow spec is deprecated and soon is going to be removed.

does the same happen with bpmn/java dsl based workflows?

deepakkapoor23 commented 1 month ago

Oh I see. I am very much interested in serverlessworkflows. I dont see the same issue with DSL example...so I guess its only seen when serverless code is generated with persistence enabled.

mswiderski commented 1 month ago

yeah, as I said, serverless workflow support was more of a try out to see what it can do and if the gets any traction and since it didn't no more time was invested in it and personally I am not really convinced this is the way to go (yaml/json format of the workflow). So will close this issue as no more work around serverless workflow is planned.

deepakkapoor23 commented 1 month ago

If you don't mind sharing, what are your concerns with serverlessworkflows spec?

mswiderski commented 1 month ago

main problem I see with it is that it didn't get any traction to consolidate all the cloud providers approach to workflows, they keep doing their own stuff anyway. In addition, having yaml/json as format of expressing workflows was meant to make it simple so not editors/modelers are needed. This in my opinion failed as any non trivial workflow is essentially unmaintainable as yaml/json files - simply it is too complex. Similar is about expressions with jq and alike. This is really complex and very easy to make mistakes with so again a tooling support would be crucial here as well. Last but not least it reminds me BPEL which its service orchestration focus in the SOA era and now we have pretty much the same approach with serverless workflows in cloud era. Very technical that focuses more on technology than business logic which in my opinion is the most important aspect of workflows - make the business logic more readable and maintainable.

mswiderski commented 1 month ago

I also wrote a blog about serverless workflow and BPMN when evaluating it might give some ideas too https://blog.automatiko.io/2022/05/15/serverless-vs-bpmn.html

deepakkapoor23 commented 1 month ago

Thanks for sharing. I agree with everything in your blog. However, I still feel that there is space for both serverless and bpmn to exist together. Serverless is easy to work with for developers and for system orchestration while BPMN is good to expose to business for any changes at runtime.

My suggestion would be to keep serverless support in Automatiko if you already have most of the spec working as it might see adoption in the dev community if not by the cloud providers. There are not many engines out there that can run serverless spec natively and Automatiko could lead that space.