Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Configurable Async API Test Behaviour #384

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

195858
Copy link
Contributor

@195858 195858 commented Apr 8, 2021

Motivation for these changes are described in #367.
The changes are configurable, the default behaviour has not changed.

  • Added an option to use a "bare" namespace for Async API channels - this omits the service name and version prefix and uses the Async API channel names as-is. We require this behaviour for our use case. It only applies to the Async API behaviour. It is relevant in two places - the example message view in the service page where the relevant mock-topic is displayed and in the async minion where the topic names are generated for message publication.
  • Added an option to specify for which operation type (PUBLISH, SUBSCRIBE) mock messages should be scheduled. The async-api.default-frequency is used for the operations of the type/method in the new property, the other operations are set to 0 (mock messages are disabled). If the property is omitted the current behaviour (schedule for both types) is preserved.
    The reason for this change: an Async API spec describes the interaction between a client and a broker from the brokers point of view. Publish means "the broker publishes this to the client", subscribe means "the broker subscribes/receives messages form the client". So in order to mock the "broker" side we essentially only want to publish mock messages for the "publish" operation type.

need this to govern if prefix of servicename and version is added to topics/channels. some use cases require strict adherence to the spec's channel definitions
Moved class so it can be reused in async minion
# Conflicts:
#	webapp/src/main/java/io/github/microcks/util/asyncapi/AsyncAPIImporter.java
…messages

Added configuration option to list the operation method that should result in scheduled mock messages. Depending on the use case it is desirable to only emit messages for a specific method.
…eam/microcks into feat-async-api-enhancements

# Conflicts:
#	minions/async/src/main/java/io/github/microcks/minion/async/producer/KafkaProducerManager.java
@@ -52,20 +52,24 @@
<artifactId>avro</artifactId>
<version>${avro.version}</version>
</dependency>

<dependency>
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After moving the URIBuilder I had to adjust the dependencies - it required the microcks-model as well as the spring-boot-starter-web dependency to build successfully.

import io.github.microcks.util.el.TemplateEngine;
import io.github.microcks.util.el.TemplateEngineFactory;

public abstract class BindingProducerManager {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I introduced this base class to remove duplicate code (topic string creation) and in order to simplify the ProducerManager class (the case statement switching between bindings).

There's a template method publishMessages that makes sure topic strings are created and messages are sent.
Sub-classes can extend the topic generation (see the KafkaProducer) and need to implement a publishOne() method.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant