For the steps below, take statefun-smoke-e2e-golang module as a reference implementation. You can copy the static config/protobuf files from there.
pom.xml
.commands.proto
from the reference implementation into the created module under src/main/protobuf
.commands.proto
. For example, the following line is added into commands.proto
to generate GoLang bindings:option go_package = ".;app";
src/main/LANGUAGE
. This enables the function to serialize/deserialize the messages sent/received.remote-module/module.yaml
, Dockerfile
, log4j.properties
into src/test/resources
. These files are for launching the Smoke E2E driver, hence no code changes needed.CommandInterpreterFn
is a remote function that performs the operation based on the command received. Following is the high level introduction to the logic to be implemented in the function. One can also look into other Smoke E2E's implementation for reference.SourceCommand
s generated by the CommandGenerator
(see details in statefun-smoke-e2e-driver).Commands
from the SourceCommand
, and performs corresponding operations based on the command types:Command.Send
: send the enclosing Commands
to the target address.Command.SendAfter
: send the enclosing Commands
to the target address after a certain delay of time(defined as a constant, say, 1 millisecond).Command.IncrementState
: increment the counter(state) by 1.Command.SendEgress
: send a message to the DISCARD_EGRESS
. The message can be just a simple string with whatever content.Command.Verify
: build a VerificationResult
by filling in the expected count from the Command.Verify
, and the actual count from function's counter(state). Then, send it over to the VERIFICATION_EGRESS
.VerificationResult
should be statefun.smoke.e2e/verification-result. Think of the typename is the unique identifier of messages across different language bindings. You can find all the naming in Constants
under statefun-smoke-e2e-driver.CommandInterpreterFn
as an HTTP endpoint using a simple web container. The endpoint should listen on 8000 port, aligning to the module.yaml
setting.src/test/java
. Most of the code can just be copied from other Smoke E2E implementations. Particularly, you should focus on preparing resources for launching the language specific HTTP endpoint in the configureRemoteFunction
method.Dockerfile.remote-function
under src/test/resources
, which builds the resources prepared by SmokeVerificationE2E into a Docker image. The image is then launched as an HTTP endpoint inside the container serving the CommandInterpreterFn
.module.yaml
defined in statefun-smoke-e2e-multilang-harness.@Ignore
in MultiLangSmokeHarnessTest
.MultiLangSmokeHarnessTest
.Flnik StateFun cluster -> SimpleVerificationServer (Containers) (JUnit Process) ^ | ˇ Remote Function (Container)
The SmokeRunner
orchestrates the entire Smoke E2E runtime and does the following:
StatefulFunctionsAppContainers.Builder
and passed to the SmokeRunner
as an input parameter. The detailed configuration can be found in concrete implementation such as SmokeVerificationGolangE2E
CommandGenerator
wrapped by CommandFlinkSource
starts to generate commands and sent them over to the remote function for state manipulations(counters). At the same time it also applies the commands internally to its internal states.CommandFlinkSource
enters the verification stage and starts to send out Command.Verify
messages along with the counts stored in its internal states as expected counts.Command.Verify
messages), and the actual counts(from remote function states) into VerificationResult
messages.VerificationResult
messages are then sent to SocketClientSink
, and further sent to SimpleVerificationServer
that collects the verification results.awaitVerificationSuccess
method in SmokeRunner
keeps polling the result arrived at SimpleVerificationServer
and verifies it by simply doing actual == expected evaluation. When all the messages are successfully verified, the program exits.Testing utilities such asSmokeRunner
, which is the facet class that organizes the Smoke E2E runtime architecture.
The core logic of the Smoke E2E driver. The driver code here is built into a self-contained jar that can be loaded and ran by the Flink StateFun cluster directly.
This module contains a generic pom.xml
that have the dependencies and the driver jar downloaded to run the Smoke E2E.
The Harness test that run the Smoke E2E as a JUnit process. Noted that one should have a remote function running at localhost 8000 port for Harness test to interact with.