Coder Social home page Coder Social logo

project-flogo / rules Goto Github PK

View Code? Open in Web Editor NEW
112.0 36.0 39.0 10.03 MB

Golang based Rules for Real-time Contextual Decisions

License: BSD 3-Clause "New" or "Revised" License

Go 98.60% Shell 1.40%
rules-processor ruleset golang golang-library rete event-driven events event-processing edge edge-computing

rules's Introduction

Rules is a lightweight library written in Golang to simplify the building of contextually aware, declaritive rules.

Installation

Prerequisites

To get started with the Flogo Rules you'll need to have a few things

  • The Go programming language version 1.8 or later should be installed.
  • The GOPATH environment variable on your system must be set properly

Install

$ go get -u github.com/project-flogo/rules/...

Note that the -u parameter automatically updates rules if it exists

Getting Started

Getting started should be fairly easy. Lets start off with some definitions around various types used.

Definitions

A Tuple represents an event or a business object and provides runtime data to the rules. It is always of a certain type.

A TupleTypeDescriptor defines the type or structure of a Tuple. It defines a tuple's properties and data types, and primary keys. It also defines the time to live for the tuple

A TupleType is a name or an alias for a TupleTypeDescriptor

A Rule constitutes of multiple Conditions and the rule triggers when all its conditions pass

A Condition is an expression involving one or more tuple types. When the expression evaluates to true, the condition passes. In order to optimize a Rule's evaluation, the Rule network needs to know of the TupleTypes and the properties of the TupleType which participate in the Condition evaluation. These are provided when constructing the condition and adding it to the rule.

A Action is a function that is invoked each time that a matching combination of tuples are found that result in a true evaluation of all its conditions. Those matching tuples are passed to the action function.

A RuleSession is a handle to interact with the rules API. You can create and register multiple rule sessions. Rule sessions are silos for the data that they hold, they are similar to namespaces. Sharing objects/state across rule sessions is not supported.

Each rule creates its own evaluation plan or a network. Multiple rules collectively form the rule network

Tuples can be created using NewTuple and then setting its properties. The tuple is then Assert-ed into the rule session and this triggers rule evaluations. A tuple can be Retracted from the rule session to take it out of play for rules evaluations.

Usage

Now lets see some code in action. Below code snippet demonstrates usage of the Rules API,

First we start off with loading the TupleDescriptor. It accepts a JSON string defining all the tuple descriptors.

fmt.Printf("Loaded tuple descriptor: \n%s\n", tupleDescriptor)
//First register the tuple descriptors
err := model.RegisterTupleDescriptors(tupleDescriptor)
if err != nil {
	fmt.Printf("Error [%s]\n", err)
	return
}

Next create a RuleSession and add all the Rules with their Conditions and Actionss.

//Create a RuleSession
rs, _ := ruleapi.GetOrCreateRuleSession("asession")

//// check for name "Bob" in n1
rule := ruleapi.NewRule("n1.name == Bob")
rule.AddCondition("c1", []string{"n1"}, checkForBob, nil)
rule.SetAction(checkForBobAction)
rule.SetContext("This is a test of context")
rs.AddRule(rule)
fmt.Printf("Rule added: [%s]\n", rule.GetName())

// check for name "Bob" in n1, match the "name" field in n2,
// in effect, fire the rule when name field in both tuples is "Bob"
rule2 := ruleapi.NewRule("n1.name == Bob && n1.name == n2.name")
rule2.AddCondition("c1", []string{"n1"}, checkForBob, nil)
rule2.AddCondition("c2", []string{"n1", "n2"}, checkSameNamesCondition, nil)
rule2.SetAction(checkSameNamesAction)
rs.AddRule(rule2)
fmt.Printf("Rule added: [%s]\n", rule2.GetName())

//Finally, start the rule session before asserting tuples
//Your startup function, if registered will be invoked here
rs.Start(nil)

Here we create and assert the actual Tuple's which will be evaluated against the Rule's Condition's defined above.

//Now assert a "n1" tuple
fmt.Println("Asserting n1 tuple with name=Tom")
t1, _ := model.NewTupleWithKeyValues("n1", "Tom")
t1.SetString(context.TODO(), "name", "Tom")
rs.Assert(context.TODO(), t1)

//Now assert a "n1" tuple
fmt.Println("Asserting n1 tuple with name=Bob")
t2, _ := model.NewTupleWithKeyValues("n1", "Bob")
t2.SetString(context.TODO(), "name", "Bob")
rs.Assert(context.TODO(), t2)

//Now assert a "n2" tuple
fmt.Println("Asserting n2 tuple with name=Bob")
t3, _ := model.NewTupleWithKeyValues("n2", "Bob")
t3.SetString(nil, "name", "Bob")
rs.Assert(context.TODO(), t3)

Finally, once all Rule Condition's are evaluated and Action's are executed, we can Retract all the Tuple's from the RuleSession and unregister the RuleSession.

//Retract tuples
rs.Retract(context.TODO(), t1)
rs.Retract(context.TODO(), t2)
rs.Retract(context.TODO(), t3)

//delete the rule
rs.DeleteRule(rule.GetName())

//unregister the session, i.e; cleanup
rs.Unregister()

Try out this example

$ go get github.com/project-flogo/rules/examples/rulesapp

Either manually run from source

$ cd $GOPATH/src/github.com/project-flogo/rules/examples/rulesapp
$ go run main.go

or install and run

$ cd $GOPATH/src/github.com/project-flogo/rules/examples/rulesapp
$ go install
$ ./$GOPATH/bin/rulesapp

Running Rules in a Flogo App

To use the Rules action in your Flogo App, refer to examples/flogo/simple/README

Connect with us

If you have any questions, feel free to post an issue and tag it as a question, email [email protected] or chat with the team and community:

  • The project-flogo/Lobby Gitter channel should be used for general discussions, start here for all things Flogo/Flogo Rules,etc!
  • The project-flogo/developers Gitter channel should be used for developer/contributor focused conversations.

License

Flogo Rules source code in this repository is under a BSD-style license, refer to LICENSE

rules's People

Contributors

balamg avatar jpark800 avatar kkiyer avatar lakshmimekala avatar mellistibco avatar mmussett avatar nareshkumarthota avatar pointlander avatar rameshpolishetti avatar tibmatt avatar vpatil-tibco avatar ykalidin avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

rules's Issues

Migrate to `project-flogo/core`

Current behavior (how does the issue manifest):
Currently TIBCOSoftware/flogo-lib is used.

Expected behavior:
Migrate to project-flogo/core.

Add descriptor.json to ruleaction

Current behavior:
Since ruleaction still using legacy action.json, flogo CLI installing it as legacy action and installing additional components like [email protected], etc which are not necessary.

Expected behavior:
Upgrade ruleaction by adding descriptor.json

Additional information you deem important:

You can observe that legacy support is getting installed while creating an app. Info below:

$ flogo create -f flogo.json 
Creating Flogo App: simplerules
Installing: github.com/project-flogo/core@latest
Installed trigger: github.com/project-flogo/contrib/trigger/rest
Installed legacy action: github.com/project-flogo/rules/ruleaction
Installed Legacy Support

Support more complex tupleTypes

Current behavior:

TupleTypes have a flat structure, only supporting scalar types.

Expected behavior:

Would be great if tupleTypes supported more complex structures so it's easier to unmarshall complex json. Otherwise, there's quite a bit of work to flatten or map between structures. Another option would be to support structs directly somehow?

Fix terminology deviations

Current behavior (how does the issue manifest):
As part of the issue #65 discussion, concern has been raised by @mellistibco on the terminology used in the rules repository. For example trigger should be used to describe an input source into an action, instead of channel/etc.

The objective of this issue to Identify such terminology deviations across Rule repository and fix.

Expression syntax for conditions

Current behavior:
Currently, one has to write code in Go for authoring rule conditions

Expected behavior:

What is the motivation / use case for changing the behavior?
For ease of use, it would be nice to support an expression syntax for conditions. For example,
rule.AddCondition ("$customer.name == Bob")

Additional information you deem important (e.g. I need this tomorrow):

Not share node in Rete Network

I fork your code and try to use it. When I create some Rules which have the same operator. But when I ran, I saw the repeat in the calculation

I used the examples/rulesapp
Here is my config for ruelsapp.json:
[ { "name": "n1", "properties": [ { "name": "name", "type": "string", "pk-index": 0 }, { "name": "age", "type": "number", "pk-index": 1 }, { "name": "address", "type": "string", "pk-index": 2 } ] }, { "name": "n2", "properties": [ { "name": "name", "type": "string", "pk-index": 0 }, { "name": "wife_name", "type": "string", "pk-index": 1 }, { "name": "child_name", "type": "string", "pk-index": 2 } ] } ]

Here is main function
https://github.com/DucVuMinh/rules/blob/chech_rete_work/examples/rulesapp/main.go

Actions/Conditions Ignored if tuple is changed in an Action

Current behavior (how does the issue manifest):
Consider we have conditions c1,c2,c3 which are always true and corresponding actions a1,a2,a3. In a1 if we try to modify tuple value then a2 & a3 are not getting executed.

Expected behavior:
All actions a1,a2,a3 should get executed as c1,c2,c3 are always true.

Minimal steps to reproduce the problem (not required if feature enhancement):
Attached rule descriptor and main.go.
Run main.go file and see the output. Repeat the same by commenting line 72,73 you can see the difference.

Please tell us about your environment (Operating system, docker version, browser & web ui version, etc):
running with latest code taken from github.

Flogo Rules version (CLI & contrib/lib. If unknown, leave empty or state unknown): 0.X.X

Additional information you deem important (e.g. issue happens only occasionally):

issue.zip

read-only cache support

Current behavior:
Tuples objects are transient. i.e. It goes away when rule engine shuts down.

Expected behavior:
Selected tuple data to be available via cache regardless of a rule engine instance's lifecycle.

What is the motivation / use case for changing the behavior?
Long lasting factual data such as employee record would need to be more persistent compared to event data. Tuple object management should support such cases more natively.

Add support for Decision Table

Current behavior:
At present all Rules need to be written in Go. Decision Tables will provide more flexibility for defining Rules for non Go users. Very useful when Rules are in the order of 100s-1000s making it easier to define and manage Rules

Expected behavior:
Provide a Visual way to define Rules i.e. spreadsheet(table) that can be easily imported at start up and can be evaluated/executed in conjunction with other Rules written in Go

What is the motivation / use case for changing the behavior?
Ability to easily define 100-1000s of Rules that are easy to manage and change without having to write several Condition/Action blocks of code which can be cumbersome and error prone
Additional information you deem important (e.g. I need this tomorrow):

AddRule/DeleteRule/AddRule for rule session is not working

Current behavior (how does the issue manifest):

  1. Adding a rule the first time works. The rule conditions and actions are executed

  2. Deleting the rule works. Rule conditions and actions are not executed any more

  3. Adding the same rule again, it return success but the rule conditions or actions are not executed anymore

  4. Adding a complete new rule (with new name) does not work either

Expected behavior:

  1. Adding a rule the first time works. The rule conditions and actions are executed

  2. Deleting the rule works. Rule conditions and actions are not executed any more

  3. Adding the same rule again, it return success and the rule conditions and actions should be executed

  4. Adding a complete new rule (with new name) should also work and conditions and actions should be executed.

Minimal steps to reproduce the problem (not required if feature enhancement):
Follow steps 1 to 4 as indicated above

Please tell us about your environment (Operating system, docker version, browser & web ui version, etc):
MacOS.

Flogo Rules version (CLI & contrib/lib. If unknown, leave empty or state unknown): 0.X.X
Latest version in github.

Additional information you deem important (e.g. issue happens only occasionally):
Issue happens all the time.

README : $GOTPATH must be GOPATH in the example

Current behavior (how does the issue manifest):

In the example of README, the commands are wrong because the variable $GOTPATH must be $GOPATH.

Expected behavior:

The variable $GOTPATH must be $GOPATH.

Minimal steps to reproduce the problem (not required if feature enhancement):

Please tell us about your environment (Operating system, docker version, browser & web ui version, etc):

Flogo Rules version (CLI & contrib/lib. If unknown, leave empty or state unknown): 0.X.X

Additional information you deem important (e.g. issue happens only occasionally):

Lookup asserted tuples by key

Current behavior:
There isn't a way to check if a tuple with a certain key has already been asserted

What is the motivation / use case for changing the behavior?
In some cases it is necessary to be able to access previously asserted tuples by their keys from from action functions

Additional information you deem important (e.g. I need this tomorrow):

Bug in handling rule conditions with no identifiers

Current behavior (how does the issue manifest):
When an additional filter condition does not contain an identifier, it does not get evaluated
Expected behavior:
It should still be evaluated
Minimal steps to reproduce the problem (not required if feature enhancement):
The following test fails. The additional condition R1_c2 below with no identifiers will not get evaluated

package tests

import (
	"github.com/project-flogo/rules/common/model"
	"github.com/project-flogo/rules/ruleapi"

	"context"
	"testing"
)

//no-identifier condition
func Test_T8(t *testing.T) {

	rs, _ := createRuleSession()

	rule := ruleapi.NewRule("R1")
	rule.AddCondition("R1_c1", []string{"t1.none"}, trueCondition, nil)
	rule.AddCondition("R1_c2", []string{}, falseCondition, nil)
	rule.SetAction(assertTuple)
	rule.SetPriority(1)
	rs.AddRule(rule)
	t.Logf("Rule added: [%s]\n", rule.GetName())

	rs.RegisterRtcTransactionHandler(t8Handler, t)
	rs.Start(nil)

	t1, _ := model.NewTupleWithKeyValues("t1", "t1")
	rs.Assert(context.TODO(), t1)
	rs.Unregister()

}


func assertTuple(ctx context.Context, rs model.RuleSession, ruleName string, tuples map[model.TupleType]model.Tuple, ruleCtx model.RuleContext) {
	t, _:= model.NewTupleWithKeyValues("t1", "t2")
	rs.Assert(ctx, t)
}

func t8Handler(ctx context.Context, rs model.RuleSession, rtxn model.RtcTxn, handlerCtx interface{}) {

	t := handlerCtx.(*testing.T)
	if m, found := rtxn.GetRtcAdded()["t1"]; found {
		lA := len(m)
		if lA != 1 {
			t.Errorf("RtcAdded: Expected [%d], got [%d]\n", 1, lA)
			printTuples(t,"Added", rtxn.GetRtcAdded())
		}
	}
	lM := len(rtxn.GetRtcModified())
	if lM != 0 {
		t.Errorf("RtcModified: Expected [%d], got [%d]\n", 0, lM)
		printModified(t, rtxn.GetRtcModified())
	}
	lD := len(rtxn.GetRtcDeleted())
	if lD != 0 {
		t.Errorf("RtcDeleted: Expected [%d], got [%d]\n", 0, lD)
		printTuples(t,"Deleted", rtxn.GetRtcDeleted())
	}
}

Please tell us about your environment (Operating system, docker version, browser & web ui version, etc):

Flogo Rules version (CLI & contrib/lib. If unknown, leave empty or state unknown): 0.X.X

Additional information you deem important (e.g. issue happens only occasionally):

TrackNtrace in develop branch: Package in sitting is not changed to delayed state even if the package is idle for 10 seconds

Current behavior (how does the issue manifest):
Trackntrace example in develop branch:
When a package is in sitting state for 10 seconds it should automatically be changed to delayed state. The state of the package is not changing.

Minimal steps to reproduce the problem (not required if feature enhancement):
Run the example in the readme .
Run the below command :
curl http://localhost:7777/moveevent?packageid=PACKAGE1\&targetstate=sitting

The package stays in sitting state even after 10 seconds.

Throw error when handler name is missing or does not have a matching event source

Current behavior (how does the issue manifest):
If the handler does not have a name or the name does not match an event source no error is thrown when an event is dispatched to the rules action. Simply nothing happens.

Expected behavior:
Output a warning or error.

Minimal steps to reproduce the problem (not required if feature enhancement):
Create a handler that does not have a name property or does not have a name that matches event in the action settings for the rules action.

Please tell us about your environment (Operating system, docker version, browser & web ui version, etc):

Flogo Rules version (CLI & contrib/lib. If unknown, leave empty or state unknown): 0.1.0

Additional information you deem important (e.g. issue happens only occasionally):

Add Kafka trigger example

Current behavior:
Currently, we have only rest trigger based examples

Expected behavior:
Add kafka trigger based example, describing how a Kafka message can be input source to rule action & how kafka topic and messages are mapped to tuple type and data.

flogo rules action is accessing query parameters directly

Current behavior (how does the issue manifest):
To create a tuple from the HTTP payload, the run method accesses HTTP query parameters directly
Expected behavior:
This should not be the case. The mapper should provide a consistent way to access input values. This was working well before the refactor for using the new repo

Minimal steps to reproduce the problem (not required if feature enhancement):

Please tell us about your environment (Operating system, docker version, browser & web ui version, etc):

Flogo Rules version (CLI & contrib/lib. If unknown, leave empty or state unknown): 0.X.X

Additional information you deem important (e.g. issue happens only occasionally):

Timer Support

I'm submitting a ... (check one with "x")

[] bug report => search github for a similar issue or PR before submitting
[x] feature request
[] support request
[] general question

Need support Timers in order to set time out to states and configure necessary actions contingent on State Transitions, Missing Event(non-Event) detection etc.

api package name change

Current behavior:

api package name is "ruleapi" which in an import looks redundant: github.com/project-flogo/rules/ruleapi

Expected behavior:

I think "github.com/project-flogo/rules/api" would look cleaner

What is the motivation / use case for changing the behavior?

Additional information you deem important (e.g. I need this tomorrow):

Invoke flogo activity as a rule action

Current behavior:
Currently, rule action is a Go function.

Expected behavior:
Able to configure a flogo activity as a rule action, so that it gets invoked when the rule fires.

What is the motivation / use case for changing the behavior?
This allows rules application to send events/messages to external applications by leveraging various flogo activities readily available (ex: rest, kafka, etc...)

Additional information you deem important (e.g. I need this tomorrow):

How to retract a tuple inserted via flogo ruleaction?

Does flogo ruleaction support retracting a tuple after a rtc completion?

For example, when running the app built from examples/flogo/simple, if the same tuples are injected via two identical curl requests(i.e. invoke 'curl localhost:7777/test/n1?name=Bob' twice), it returns with the message

"Tuple with key [n1:name:Bob] already asserted"

Retracting a tuple is supported via api. Is there way to achieve it in functions.go or flogo action's json configuration?

Join failing for more than 2 tuple types

Current behavior (how does the issue manifest):
If there are more than 2 tuple types for join

Expected behavior:
Should be able to join across more than 2 tuple typles

Minimal steps to reproduce the problem (not required if feature enhancement):
Create 3 tuple types with a condition checking a property across all 3. Finally create instances for the 1st 2nd. Ideally the condition should not get invoked, should wait for 3rd type to come in before condition invocation.

Update the README to reflect both usage in the context of a Flogo app & the API

Current behavior (how does the issue manifest):
The current README only reflects getting started and usage via the API.

Expected behavior:
The README should capture all variants of usage, such as, within the context of a Flogo application leveraging the JSON DSL. We should also capture the usage around leveraging the streaming action along side the rules action in a single application.

GetOrCreateRuleSessionFromConfig is hardcoding context

Current behavior (how does the issue manifest):
When rules are created from config file, the context is hardcoded
Expected behavior:
The context should be set from the value provided in config file. If value is not provided, the . it should be defaulted to the hardcoded value
Minimal steps to reproduce the problem (not required if feature enhancement):
Just creating a rule with a config file, all rules will have the same value
Please tell us about your environment (Operating system, docker version, browser & web ui version, etc):
MacOS
Flogo Rules version (CLI & contrib/lib. If unknown, leave empty or state unknown): 0.X.X
0.5.8
Additional information you deem important (e.g. issue happens only occasionally):

Document Samples

Current behavior (how does the issue manifest):
The examples that demonstrate how to use the rules action within a flogo app.json are not documented.

Expected behavior:
Document the usage of the samples.

Action execution is changed on modifing the order of conditions

Current behavior (how does the issue manifest):
The actions fired are changing if the order of conditions is changed which is unexpected.

Expected behavior:
The actions should be fired irrespective of the order of conditions.

Minimal steps to reproduce the problem (not required if feature enhancement):
1)Attached the main.go file and Descriptor file.There are two conditions in main.go.
The checkForBob condition is true only when name is "Bob"
The checkForName condition is true when name is not empty.
Run the main.go file.The action gets fired even if "Tom" is sent as name, which is unexpected.
Below is the output:

Rule added: [rule1]
Rule fired: [rule1]
Context is [This is a test of context]
name= Bob
Rule fired: [rule1]
Context is [This is a test of context]
name= Tom

2)Now modify the order of the conditions by reversing lines 33 and 34.
Run the main.go.Below is the output:

Rule added: [rule1]
Rule fired: [rule1]
Context is [This is a test of context]
name= Bob

The output is changed when the order of conditions is changed.
This is an erroneous behavior.

issue.zip

Tool to generate functions.go based on rules descriptor

Current behavior:
User has to write down functions.go with condition evaluators and action functions as defined in the rules descriptor json.

Expected behavior:
Add a cli tool or flogo cli plugin to generate functions.go boilerplate code based on supplied rules descriptor json.

What is the motivation / use case for changing the behavior?

  • Improves turn around time to create and run a new rule application.
  • Eliminates human errors caused due to mismatch function names (usually spelling mistakes) between descriptor json and functions.go

Additional information you deem important (e.g. I need this tomorrow):

Document the Flogo examples

Current behavior (how does the issue manifest):
The examples that demonstrate how to use the rules action within a flogo app.json are not documented.

Expected behavior:
Document the usage of the samples via a README in the corresponding samples directory

How does Flogo Rules compared to Drools

What is your question?
Hello!
We are evaluating tech stack for rules and processing of events. One strong candidate is Drools, but we prefer to have something written in Golang. And this is how we found Flogo. ๐Ÿ˜Š

But from documentation https://www.flogo.io/ , we have several high level questions:

  1. In the website, it's mentioned that flogo rules support Forward chaining for Inferencing, what about backward chaining?
  2. Is there any performance benchmark for our reference? i.e. we want to roughly understand if Flogo can scale to handle big amount of events, or it's mostly only suitable for "edge application".

Thank you in advance!

A tuple remains in the rule session's network after retract is invoked

Current behavior (how does the issue manifest):
After retracting a tuple, asserting another tuple with the same key in the same rule session fails as the tuple is found when looked up.

Expected behavior:
The retract should take the tuple out of play for the rule session but it doesn't.

Minimal steps to reproduce the problem (not required if feature enhancement):
Described in the current behavior above.

Additional information you deem important (e.g. issue happens only occasionally):
The purpose of Retract api compared to the Delete api in the rule session api is not clearly described.

Document the action implementation

Current behavior:
We do not have any documentation for the action implementation.

Expected behavior:
A definition of how the action implementation works

  • how to define events
  • that all input needs to map into a property called values
  • that the handler name is used to correlate the incoming event typ, etc

What is the motivation / use case for changing the behavior?
Getting started is difficult without documentation

Get data back or modify data in an Action

Current behavior:
When a condition evaluates to true the assigned action func is triggered and does something with the map of tuples but the function signature does not allow for data to be returned or the tuple to be modified in any way.

Expected behavior:
If data is passed into the rules engine could we get data that is modified back to the caller

What is the motivation / use case for changing the behavior?
Ex. Given two services: service1 and EngineService:

  • service1 passes data to EngineService for processing.
  • EngineService has a rule: "if x == 5; then set y = 10;"
  • how can we get 'y' back to service1 from the action

Additional information you deem important (e.g. I need this tomorrow):

Programs don't build for GOOS=linux GOARCH=arm GOARM=5

Current behavior (how does the issue manifest):
Get error when trying to build program for the indicated platform:

GOOS=linux GOARCH=arm GOARM=5 flogo build -e

ev3rules/vendor/github.com/project-flogo/rules/rete

vendor/github.com/project-flogo/rules/rete/network.go:342:14: constant 4294967295 overflows int
FATAL: command "build" failed: exit status 2

Expected behavior:
Build should complete.

Minimal steps to reproduce the problem (not required if feature enhancement):
Try building any program using Flogo rules for the above platform

Please tell us about your environment (Operating system, docker version, browser & web ui version, etc):
GOOS=linux GOARCH=arm GOARM=5

Flogo Rules version (CLI & contrib/lib. If unknown, leave empty or state unknown): 0.X.X

Additional information you deem important (e.g. issue happens only occasionally):

Expression syntax for rule conditions

Current behavior:
Currently, conditions need to be written in Go code

Expected behavior:

What is the motivation / use case for changing the behavior?
It is much easier to author rule conditions using an expression syntax such as, for example,"$n1.name == 'Bob'" instead of writing Go code for the same

Additional information you deem important (e.g. I need this tomorrow):

Actions are triggered multiple times when multiple conditions are added

Current behavior:
Actions are called multiple times when there are multiple actions for a rule and a new tuple data is asserted.

Expected behavior:
Actions should be fired only once per data.

Minimal steps to reproduce the problem:
1)Attached the main.go file and Descriptor file. There are two conditions in main.go which returns true always. Run the main.go file.
Below is the output seen:

Insert data 1
Rule fired: [rule1]
name= Tom
Insert data 2
Rule fired: [rule1]
name= Bob
Rule fired: [rule1]
name= Bob
Rule fired: [rule1]
name= Tom

The rule is fired once when data 1 "Tom" is asserted.
But when the next data "Bob" is asserted, the rule is fired 3 times(2 times for Bob and 1 time for Tom).
Actions are triggered multiple times when there are multiple conditions.This behavior is unexpected.

issue1.zip

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.