You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+59-2Lines changed: 59 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -24,8 +24,6 @@
24
24
# Eiffel Intelligence
25
25
Eiffel Intelligence is a real time data aggregation and analysis solution for Eiffel events. While Eiffel represents an event based architecture, Eiffel Intelligence addresses the need of stakeholders to view the current state of the system by bridging the divide from immutable events to mutable state representation.
26
26
27
-
## Detailed documentation is provided in [the repository wiki](../../wiki).
28
-
29
27
# About this repository
30
28
The contents of this repository are licensed under the [Apache License 2.0](./LICENSE).
31
29
@@ -35,3 +33,62 @@ To get involved, please see [Code of Conduct](./CODE_OF_CONDUCT.md) and [contrib
35
33
This repository forms part of the Eiffel Community. Eiffel is a protocol for technology agnostic machine-to-machine communication in continuous integration and delivery pipelines, aimed at securing scalability, flexibility and traceability. Eiffel is based on the concept of decentralized real time messaging, both to drive the continuous integration and delivery system and to document it.
36
34
37
35
Visit [Eiffel Community](https://eiffel-community.github.io) to get started and get involved.
Suppose, we publish an “EiffelArtifactCreatedEvent” (given below) on the message bus.
4
+
5
+
{
6
+
"meta": {
7
+
"time": 1473177136433,
8
+
"source": {
9
+
"domainId": "example.domain"
10
+
},
11
+
"type": "EiffelArtifactCreatedEvent",
12
+
"id": "ccce572c-c364-441e-abc9-b62fed080ca2",
13
+
"version": "1.0.0"
14
+
},
15
+
"links": [{
16
+
"target": "23df3bd2-c620-42ce-80ba-b7ba6551c9f9",
17
+
"type": "COMPOSITION"
18
+
},
19
+
{
20
+
"target": "9ace5eea-3547-45f6-be4d-25b43d87e6dc",
21
+
"type": "ENVIRONMENT"
22
+
},
23
+
{
24
+
"target": "51601fdb-db7c-4b3f-862e-da1154e4ae96",
25
+
"type": "PREVIOUS_VERSION"
26
+
},
27
+
{
28
+
"target": "51c77087-74e2-449f-9def-00acd5e2c944",
29
+
"type": "CONTEXT"
30
+
}
31
+
],
32
+
"data": {
33
+
"customData": [{
34
+
"value": "ArtC2",
35
+
"key": "name"
36
+
},
37
+
{
38
+
"value": 53,
39
+
"key": "iteration"
40
+
}
41
+
],
42
+
"fileInformation": [{
43
+
"extension": "jar",
44
+
"classifier": "debug"
45
+
},
46
+
{
47
+
"extension": "",
48
+
"classifier": "test"
49
+
},
50
+
{
51
+
"extension": "exe",
52
+
"classifier": ""
53
+
}
54
+
],
55
+
"gav": {
56
+
"version": "1.53.0",
57
+
"artifactId": "sub-system",
58
+
"groupId": "com.mycompany.myproduct"
59
+
}
60
+
}
61
+
}
62
+
63
+
64
+
When this message is received at EI, processing begins for possible aggregation and notification. In the next step rules object for the message is extracted. The rules object is a set of rules in JSON format that helps extract required information from an event by using JMESPath API (for more information about the EI rules follow this [link](./Rules.md)). From the rules object, “IdentifyRules” is extracted which is a JMESPath identifier of ids and will be used to search for all existing aggregated objects linked to the event under process. Here it should be noted that rules object path is configured in the application.properties file as “rules.path”.
65
+
66
+
**Rule object extracted from the event under consideration:**
67
+
68
+
{
69
+
"TemplateName": "ARTIFACT_1",
70
+
"Type": "EiffelArtifactCreatedEvent",
71
+
"TypeRule": "meta.type",
72
+
"IdRule": "meta.id",
73
+
"StartEvent": "YES",
74
+
"IdentifyRules": "[meta.id]",
75
+
"MatchIdRules": {
76
+
"_id": "%IdentifyRules_objid%"
77
+
},
78
+
"ExtractionRules": "{ id : meta.id, type : meta.type, time : meta.time, gav : data.gav, fileInformation : data.fileInformation, buildCommand : data.buildCommand }",
If no event-linked aggregated object is found, then next step is to check whether the given event is a “start event”. It should be clear that, term “start event” means that the event might be starting a new flow and therefore, a new aggregated object may be created out of this. If the current event is not a “start event” then it is stored in the database. The name of the collection is configured in the application.properties file as “waitlist.collection.name”. The event is stored with the aim that if an aggregated object is created later with links to this specific event then it can be merged with that object. The event storage life time is set in the properties file as “waitlist.collection.ttlValue”.
90
+
91
+
Otherwise, If the event is a start event (as is the current event) then the next step is information extraction from the event and adding into the aggregated object. It should be noted that this event has no links to any aggregated object. However, as it is a start event so a new aggregated object is created by extracting information from this event.
92
+
93
+
**Information Extraction from an Event:** In this step, information from a given event is extracted. This information will then be added into a relevant aggregated object. This is what the term aggregation comes from. What information is extracted from a given event is encoded in the extraction rules. Extraction rules are represented in the rules object with a key named “ExtractionRules”. For example, for the current event and rule object, following information will be extracted:
94
+
95
+
{
96
+
"id": "ccce572c-c364-441e-abc9-b62fed080ca2",
97
+
"type": "EiffelArtifactCreatedEvent",
98
+
"time": 1473177136433,
99
+
"gav": {
100
+
"version": "1.53.0",
101
+
"artifactId": "sub-system",
102
+
"groupId": "com.mycompany.myproduct"
103
+
},
104
+
"fileInformation": [{
105
+
"extension": "jar",
106
+
"classifier": "debug"
107
+
}, {
108
+
"extension": "",
109
+
"classifier": "test"
110
+
}, {
111
+
"extension": "exe",
112
+
"classifier": ""
113
+
}],
114
+
"buildCommand": null
115
+
}
116
+
117
+
Once the information extraction is complete, the next processing steps are different for start events (an event with no linked aggregated object) and events with link to an associated aggregated object. For start event, an object is created out of the extracted content and inserted into the database, with a name configured in the properties file as “aggregated.collection.name”. The next step is to query the database for all the upstream linked objects for this event. Then each of the linked object is processed individually. For each object, its rule object field “HistoryExtractionRules” is used to extract contents from it and merge with the aggregated object. More about the “HistoryExtractionRules” can be found [here](./Rules.md). Finally, the modified aggregated object is updated in the database.
118
+
119
+
On the other hand, If the event is linked to aggregated object(s) then each of the aggregated object is processed together with this event. The contents of the event to be merged into the aggregated object are extracted and added to the aggregated object using “MergeResolverRules”. More about “MergeResolverRules” can be found [here](./Rules.md). Next, “ProcessRules” (if exist) are applied on the aggregated object and the resulting modified aggregated object is updated in the database.
Authentication is not a requirement but can be turned on and off in the application properties file with the '_ldap.enabled_' property.
11
+
12
+
## Check if security is enabled
13
+
14
+
Returns the json variable '_security_' that is set to either true or false
15
+
16
+
GET /auth
17
+
18
+
Curl command
19
+
20
+
curl -X GET -H "Content-type: application/json" http://<host>:8090/auth
21
+
22
+
Example of response body
23
+
24
+
{"security":true}
25
+
26
+
## Login point that returns the name of current user
27
+
28
+
Upon the first time valid credentials are used the response will contain an 'X-Auth-Token' header that must be saved and attached to any following calls to endpoints that require authentication. If the same client connection is used then session cookie is used to authenticate and 'X-Auth-Token' would not be needed in that case.
29
+
30
+
GET /auth/login
31
+
32
+
Curl command
33
+
34
+
curl -X GET -H "Content-type: application/json" -u <username>:<password> http://<host>:8090/auth/login
Removes the current session bound to the client. If 'X-Auth-Token' is used to authenticate then the same token needs to be attached when calling the logout endpoint.
59
+
60
+
GET /auth/logout
61
+
62
+
Curl command with session cookie
63
+
64
+
curl -X GET -H "Content-type: application/json" http://<host>:8090/auth/logout
65
+
66
+
Curl command with token
67
+
68
+
curl -X GET -H "Content-type: application/json" -H "X-Auth-Token: <uuid>" http://<host>:8090/auth/logout
69
+
70
+
## Check if backend is running
71
+
72
+
An arbitrary endpoint to check if backend is up and running
73
+
74
+
GET /auth/checkStatus
75
+
76
+
Curl command
77
+
78
+
curl -X GET -H "Content-type: application/json" http://<host>:8090/auth/checkStatus
Address and port for message buss and MongoDB needs to be configured in [application.properties](https://github.com/Ericsson/eiffel-intelligence/blob/master/src/main/resources/application.properties) for the application to run properly.
4
+
5
+
Each property is explained in the file so open the properties file for a view on properties role.
0 commit comments