Skip to content

Commit cd8c3ff

Browse files
authored
Merge pull request #76490 from kaldesai/SRVLOGIC-300-OSL-main
PR for SRVLOGIC-300, SRVLOGIC-190, SRVLOGIC-188, SRVLOGIC-192: Document "Serverless Logic" parent directory for Openshift Serverless Logic docs.
2 parents 02ae8bd + 00cddf8 commit cd8c3ff

File tree

44 files changed

+2050
-1
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

44 files changed

+2050
-1
lines changed

_attributes/common-attributes.adoc

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -107,10 +107,12 @@
107107
//serverless
108108
:ServerlessProductName: OpenShift Serverless
109109
:ServerlessProductShortName: Serverless
110+
:ServerlessLogicProductName: OpenShift Serverless Logic
111+
:ServerlessLogicProductShortName: Serverless Logic
110112
:ServerlessOperatorName: OpenShift Serverless Operator
111113
:ServerlessLogicOperatorName: OpenShift Serverless Logic Operator
112114
:FunctionsProductName: OpenShift Serverless Functions
113-
:ServerlessProductVersion: 1.31.0
115+
:ServerlessProductVersion: 1.33.0
114116
//service mesh v2
115117
:product-dedicated: Red Hat OpenShift Dedicated
116118
:SMProductName: Red Hat OpenShift Service Mesh

_topic_maps/_topic_map.yml

Lines changed: 22 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -342,6 +342,28 @@ Topics:
342342
- Name: Using a sink binding with OpenShift Service Mesh
343343
File: sinkbinding-with-ossm
344344
---
345+
# Serverless Logic
346+
Name: Serverless Logic
347+
Dir: serverless-logic
348+
Distros: openshift-serverless
349+
Topics:
350+
- Name: Getting started
351+
Dir: serverless-logic-getting-started
352+
Topics:
353+
- Name: Creating and running workflows with Knative Workflow plugin
354+
File: serverless-logic-creating-managing-workflows
355+
- Name: Deploying workflows
356+
File: serverless-logic-deploying-workflows
357+
- Name: Managing services
358+
Dir: serverless-logic-managing-services
359+
Topics:
360+
- Name: Configuring OpenAPI services
361+
File: serverless-logic-configuring-openAPI-services
362+
- Name: Configuring OpenAPI services endpoints
363+
File: serverless-logic-configuring-openAPI-services-endpoints
364+
- Name: Troubleshooting services
365+
File: serverless-logic-troubleshooting-services
366+
---
345367
# Knative kn CLI
346368
Name: Knative CLI
347369
Dir: cli_tools
Lines changed: 88 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,88 @@
1+
// Module included in the following assemblies:
2+
//
3+
4+
:_mod-docs-content-type: PROCEDURE
5+
[id="serverless-logic-asyncAPI-consuming-event_{context}"]
6+
= Consuming an event
7+
8+
To enable seamless event consumption, define the Kafka server, subscription channel, and a function that consumes the event, and then invoke the function in your workflow. When your workflow reaches the function, it pauses and waits for the specific event from the Kafka topic before continuing.
9+
10+
.Prerequisites
11+
* You have created a {ServerlessLogicProductName} project or have access to a project with the appropriate roles and permissions to create applications and other workloads in {ocp-product-title}.
12+
* You have created your {ServerlessLogicProductName} project.
13+
* You have created the `asyncAPI.yaml` file and your project `classpath`.
14+
* Your project includes necessary dependencies for AsyncAPI and Kafka.
15+
16+
.Procedure
17+
18+
. Define the Kafka Server in your `asyncAPI.yaml` file as shown in the following example:
19+
+
20+
[source,yaml]
21+
----
22+
servers:
23+
development:
24+
url: localhost:9092
25+
description: Development server
26+
protocol: kafka
27+
protocolVersion: '1.0.0'
28+
----
29+
30+
. Create a subscription channel in the `asyncAPI.yaml` file.
31+
+
32+
The following example shows to define a subscription channel named `wait`:
33+
+
34+
[source,yaml]
35+
----
36+
channels:
37+
wait:
38+
description: A message channel
39+
subscribe:
40+
operationId: consumeWait
41+
summary: Get messages
42+
message:
43+
$ref: '#/components/messages/message'
44+
----
45+
46+
. Add a function in your workflow that uses the `asyncapi` type and points to the `consumeWait` operation ID.
47+
+
48+
[source,json]
49+
----
50+
{
51+
"functions": [
52+
{
53+
"name": "consumeEvent",
54+
"type": "asyncapi",
55+
"operation": "asyncAPI.yaml#consumeWait"
56+
}
57+
]
58+
}
59+
----
60+
+
61+
[NOTE]
62+
====
63+
The `operation` property supports `http`, `https`, and `file` schemas for the URI. If no schema is specified, it assumes the file is on the project classpath.
64+
====
65+
66+
. In your workflow, invoke the `consumeEvent` function within an operation state:
67+
+
68+
.Example of invoking the function
69+
[source,json]
70+
----
71+
{
72+
"states": [
73+
{
74+
"name": "waitForEvent",
75+
"type": "operation",
76+
"actions": [
77+
{
78+
"functionRef": "consumeEvent"
79+
}
80+
]
81+
}
82+
]
83+
}
84+
----
85+
86+
. Execute the workflow.
87+
+
88+
When the workflow reaches the `waitForEvent` state, it pauses.
Lines changed: 97 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,97 @@
1+
// Module included in the following assemblies:
2+
//
3+
4+
:_mod-docs-content-type: PROCEDURE
5+
[id="serverless-logic-asyncAPI-publishing-event_{context}"]
6+
= Publishing an event
7+
8+
To enable seamless publication of events, define the HTTP server, publishing channel, and a function that sends the event, and then invoke the function in your workflow. When your workflow reaches the function, it sends the event with the necessary payload to the HTTP server.
9+
10+
.Prerequisites
11+
* You have created a {ServerlessLogicProductName} project or have access to a project with the appropriate roles and permissions to create applications and other workloads in {ocp-product-title}.
12+
* You have created your {ServerlessLogicProductName} project.
13+
* You have created the `asyncAPI.yaml` file your project `classpath`.
14+
* An HTTP server is running and accessible at the defined URL.
15+
* Your project includes the necessary dependencies for AsyncAPI and HTTP communication.
16+
17+
.Procedure
18+
19+
. Define the HTTP Server in your `asyncAPI.yaml` file.
20+
+
21+
The following example defines an HTTP server:
22+
+
23+
[source,yaml]
24+
----
25+
servers:
26+
development:
27+
url: localhost:8080
28+
description: Development server
29+
protocol: http
30+
protocolVersion: '1.0.0'
31+
----
32+
33+
. Create a publishing channel in your `asyncAPI.yaml` file.
34+
+
35+
The following example defines a publishing channel definition named `resume`:
36+
+
37+
[source,yaml]
38+
----
39+
channels:
40+
resume:
41+
description: A message channel
42+
publish:
43+
operationId: sendResume
44+
summary: Send messages
45+
message:
46+
$ref: '#/components/messages/message'
47+
----
48+
49+
. Add a function in your workflow that uses the `asyncapi` type and points to the `sendResume` operation Id.
50+
+
51+
The following example shows function definition:
52+
+
53+
[source,json]
54+
----
55+
{
56+
"functions": [
57+
{
58+
"name": "sendResume",
59+
"type": "asyncapi",
60+
"operation": "asyncAPI.yaml#sendResume"
61+
}
62+
]
63+
}
64+
----
65+
+
66+
[NOTE]
67+
====
68+
The `operation` property supports `http`, `https`, and `file` schemas for the URI. If no schema is specified, it assumes the file is on the project `classpath`.
69+
====
70+
71+
. Invoke the function in an operation state.
72+
+
73+
In your workflow, invoke the `sendResume` function within an operation state as defined in the following example:
74+
+
75+
[source,json]
76+
----
77+
{
78+
"states": [
79+
{
80+
"name": "sendEvent",
81+
"type": "operation",
82+
"actions": [
83+
{
84+
"functionRef": "sendResume",
85+
"arguments": {
86+
"name": "Javierito"
87+
}
88+
}
89+
]
90+
}
91+
]
92+
}
93+
----
94+
95+
. Execute the workflow.
96+
+
97+
When the workflow reaches the `sendEvent` state, it sends an event to the endpoint `\localhost:8080/resume` with the payload {`"name":"Javierito"`}.
Lines changed: 116 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,116 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * serverless/serverless-logic/serverless-logic-creating-managing-workflows.adoc
4+
5+
:_mod-docs-content-type: PROCEDURE
6+
[id="serverless-logic-building-deploying-workflow-preview-mode_{context}"]
7+
= Building and deploying your workflow
8+
9+
You can create a `SonataFlow` custom resource (CR) on {ocp-product-title} and {ServerlessLogicOperatorName} builds and deploys the workflow.
10+
11+
.Prerequisites
12+
13+
* You have an {ServerlessLogicOperatorName} installed on your cluster.
14+
* You have access to an {ServerlessLogicProductName} project with the appropriate roles and permissions to create applications and other workloads in {ocp-product-title}.
15+
* You have installed the OpenShift CLI `(oc)`.
16+
17+
.Procedure
18+
19+
. Create a workflow YAML file similar to the following:
20+
+
21+
[source,yaml]
22+
----
23+
apiVersion: sonataflow.org/v1alpha08
24+
kind: SonataFlow
25+
metadata:
26+
name: greeting
27+
annotations:
28+
sonataflow.org/description: Greeting example on k8s!
29+
sonataflow.org/version: 0.0.1
30+
spec:
31+
flow:
32+
start: ChooseOnLanguage
33+
functions:
34+
- name: greetFunction
35+
type: custom
36+
operation: sysout
37+
states:
38+
- name: ChooseOnLanguage
39+
type: switch
40+
dataConditions:
41+
- condition: "${ .language == \"English\" }"
42+
transition: GreetInEnglish
43+
- condition: "${ .language == \"Spanish\" }"
44+
transition: GreetInSpanish
45+
defaultCondition: GreetInEnglish
46+
- name: GreetInEnglish
47+
type: inject
48+
data:
49+
greeting: "Hello from JSON Workflow, "
50+
transition: GreetPerson
51+
- name: GreetInSpanish
52+
type: inject
53+
data:
54+
greeting: "Saludos desde JSON Workflow, "
55+
transition: GreetPerson
56+
- name: GreetPerson
57+
type: operation
58+
actions:
59+
- name: greetAction
60+
functionRef:
61+
refName: greetFunction
62+
arguments:
63+
message: ".greeting+.name"
64+
end: true
65+
----
66+
67+
. Apply the `SonataFlow` workflow definition to your {ocp-product-title} namespace by running the following command:
68+
+
69+
[source,terminal]
70+
----
71+
$ oc apply -f <workflow-name>.yaml -n <your_namespace>
72+
----
73+
+
74+
.Example command for the `greetings-workflow.yaml` file:
75+
[source,terminal]
76+
----
77+
$ oc apply -f greetings-workflow.yaml -n workflows
78+
----
79+
80+
. List all the build configurations by running the following command:
81+
+
82+
[source,terminal]
83+
----
84+
$ oc get buildconfigs -n workflows
85+
----
86+
87+
. Get the logs of the build process by running the following command:
88+
+
89+
[source,terminal]
90+
----
91+
$ oc logs buildconfig/<workflow-name> -n <your_namespace>
92+
----
93+
+
94+
.Example command for the `greetings-workflow.yaml` file:
95+
[source,terminal]
96+
----
97+
$ oc logs buildconfig/greeting -n workflows
98+
----
99+
100+
.Verification
101+
102+
. To verify the deployment, list all the pods by running the following command:
103+
+
104+
[source,terminal]
105+
----
106+
$ oc get pods -n <your_namespace>
107+
----
108+
+
109+
Ensure that the pod corresponding to your workflow is running.
110+
111+
. Check the running pods and their logs by running the following command:
112+
+
113+
[source,terminal]
114+
----
115+
$ oc logs pod/<pod-name> -n workflows
116+
----

0 commit comments

Comments
 (0)