Wilma Feature List

Wilma Operation Modes

Wilma can act as pure Proxy, can act as pure Service Stub, and can act in mixed mode (use both Proxy and Service Stub features). See details about it here....

For individual messages, it is also possible to enforce Wilma to ignore the stub settings and enforce working in proxy mode.

Stub - Configuration

The Stub part of Wilma is configured via JSON file(s). Details about how the Stub Configuration should be used can be found here....

Wilma can handle multiple stub configurations. With this feature grouping of stub functions (by team, by stubbed application, by individual services, etc.) can be used. See details about this possibility here....

The schema of the stub configuration JSON that is used by Wilma can be accessed at the following address:

http://epam.github.io/Wilma/schema/StubConfig-SchemaV2.0.json

Stub - Condition Checkers

The stub configuration contains several dialog-descriptors that describes a stub request-response pair. These pairs have a condition-descriptor and a template-descriptor, and the first may contain several Condition Checkers, those evaluate the request and help identifying the ones where stub response should be generated (based on the template-descriptor).

Among the numerous built-in Condition Checkers, you may write and use your own solutions too.

See details on Condition Checkers here, at "Object: condition" section.

See details on the built-in Condition Checker classes here.

Stub - Templates

When a stub response should be generated, it is easy to use a previously saved response template, and send it back. Such templates can be plain text, xml, json, or anything else you need.

To get more information on how templates are handled by Wilma, search for information here, at "Object: template" section.

Stub - Response Formatter Classes

In many cases the predefined response templates cannot be used as they are, but the response should be formed - fields should be changed, time stamps should be updated, and so on. To address this Wilma offers built-in response formatters, however it is possible for you to write and use your own response formatter classes.

It is also possible to call several response formatters before the stub response is finally sent back as answer.

See details on response formatters here, at "Object: responseDescriptor" section.

See details on the built-in Response Formatter classes here.

Using Interceptor classes

Interceptors are classes those intercept either request or response (or both) messages, and do whatever they would like to do with the intercepted messages. You may write and use your own interceptor classes. See more details on interceptors here...

Using Message Sequences

Sometimes it is necessary to know not just the last request to form a stub response, but previous messages content should be known as well (like messages connected together in a session). Wilma offers Sequence handling feature to address this problem, with this feature it is possible to collect and group request-response pairs into Sequences, and use such sequence to generate the stub response - as necessary. meanwhile there are some built-in sequence handles, you may write your own class, therefore collect request-response pairs as you need.

See details on this feature here...

Configuring Wilma at run time - via UI

Wilma has a home page, where basic configurations can be made at run time. You can reach the home page under the following URL after Wilma has started: http://wilma-url:internal-port/index.

  • wilma-url  is the address of the server where Wilma is running.
  • internal-port  is the port of the internal web server in Wilma that is configured in wilma.conf.properties (default is  1234 )

The Wilma home page currently contains two configuration groups: Message Logging and Operation Mode switches.

Regarding Message Logging, it can be turned on and off. By turning Message Logging on, every HTTP/S request and response that goes through Wilma will be logged.

Regarding Operation Mode, you can influence the major behavior of Wilma:

  • Switch between modes: can be switched between WILMA, PROXY and STUB modes. See more here....
  • Interceptor usage: enabling/disabling message interceptors. See more here....
  • Localhost blocking: enabling/disabling Localhost blocking feature, see more here....
  • Sequence handling: enabling/disabling the build-in Message Sequence handling. See more here....

Note: Switch changes has immediate affect on Wilma operation!

Note2: There is an additional switch: Message Marking, that is not exposed onto the UI, but available by using direct url.

Configuring switches via direct url:

  • Get status of message logging: 
    http://wilma-url:internal-port/config/public/logging/status
  • Turn ON message logging: 
    http://wilma-url:internal-port/config/admin/logging/on
  • Turn OFF message logging: 
    http://wilma-url:internal-port/config/admin/logging/off
  • Get status of operation mode: 
    http://wilma-url:internal-port/config/public/switch/status
  • Set operation mode: 
    http://wilma-url:internal-port/config/admin/switch/[MODE]
     where MODE can be wilma, stub and proxy.

  • Get status of message marking: 
    http://wilma-url:internal-port/config/public/messagemarking/status
  • Turn ON message marking: 
    http://wilma-url:internal-port/config/admin/messagemarking/on
  • Turn OFF message marking: 
    http://wilma-url:internal-port/config/admin/messagemarking/off

Configuring Wilma at run time - via Java Service Library

Since Wilma version 1.5, Wilma Java Service Library have the feature of configuring the stub part programmatically. See details here.

Uploading External Resources

There are four kinds of external resources those can be uploaded to Wilma, and each use different addresses for the upload.

  • condition checkers:
    An external condition checker class can be uploaded to the following url, with a file name parameter: 
    http://wilma-url:internal-port/config/admin/stub/conditionchecker
  • templates
    A response template can be uploaded to the following url, with a file name parameter: 
    http://wilma-url:internal-port/config/admin/stub/templates
  • response formatters
    A response formatter can be uploaded to the following url, with a file name parameter: 
    http://wilma-url:internal-port/config/admin/stub/responseformatter
  • stub configuration
    A new stub configuration can be uploaded to the following url, with a file name parameter: 
    http://wilma-url:internal-port/config/admin/stub/stubconfig
By using the `curl` command, this can be done in the following way: 
# this example uploads 'ExternalConditionChecker.class'
# the class should be in the folder the command is executed.
# don't forget the fileName parameter at the end of the command!
curl -X POST --data-binary @ExternalConditionChecker.class http://wilma-url:internal-port/config/admin/stub/conditionchecker?fileName=ExternalConditionChecker.class

Note: If the file name is not provided as parameter in the url, the file will not be uploaded successfully.

Wilma also has a UI page (the /stubconfig), where the list of dialog descriptors of the actual stub configuration, the uploaded interceptors, condition checkers, template formatters, templates, sequence handler and jars are visible, can be viewed and downloaded. New files can uploaded here as well, such as a new stub configuration and new resources.

Getting the Message Logs

There is a /messages page on Wilma UI, where configuration regarding the message logging can be viewed. Also the message log files can be downloaded from here. Their content can be viewed online by clicking on the '[Source]' link next to the message file.

Note: If you need more sophisticated message search functionality, there is a lucene index based search engine solution, that is the Wilma Message Search application.

Getting the Wilma Application Logs

The Wilma application log files can be accessed at the page /logs via UI. Their source can be also viewed online by clicking on the '[Source]' link next to the file name.

For expert users, the level of application logging can be configured by changing the logback.xml, that is embedded in the jar file.

Blocking messages arrived from Localhost

In certain cases, when a remotely deployed Wilma application is in use, and the original target of the request is "localhost" - as Wilma hosted on another machine from where the request is coming - Wilma is unable to determine the real target host. In this case forwarding to "localhost" would not have meaning, and it is unknown where the request should be forwarded exactly. To avoid such bad environment setup, it is possible to ask Wilma not to handle requests coming from localhost.

In case the localhost blocking functionality is enabled, it stops proxied requests directed to 127.0.0.1 or localhost. If it is disabled, no such restriction applied.

See details on this feature here...

Stability Rules

Wilma is designed to protect itself in case of huge load. Therefore - like if decoding the messages or saving it on the disk would take too much time, and the internal queries are getting full, - Wilma (on-the-fly) configures itself to turn off time consuming operations, as the load increases, first turns off decoding FIS-coded messages, and if the load is still high, it turns off saving messages to the disk. As soon as the load goes back to normal, Wilma turns back the message logging, and later the FIS decoding too. See the wilma.config.properties file for setting the limits (search for safeguard.* properties).

Maintaining Message Logs

Wilma is designed to clean-up the old messages from the disk. A dedicated regular thread within Wilma checks the old messages, and delete them. This ensures that you can avoid disk full problems. How to set how old messages should be deleted? Look for such info (see log.maintainer.* properties) in wilma.config.properties file.

Load Information

Both of the applications (Wilma and Wilma Message Search) provide data about their actual load and other information. These data are available on both UIs.

Get more information on the load data provided by the applications here...

Java and .NET Service Libraries for Wilma

Wilma has service libraries in order to ease the communication/configuration of Wilma from your own code.

Java Service Library for Wilma is available via MavenCentral. See more info here...

.NET Service Library for Wilma is available via NuGet. See more info here...

Wilma Service Endpoint Extension possibility

By implementing the ExternalWilmaService interface, it is possible to communicate with your external plugins directly by using HTTP/REST calls. See details here.

Shutting down Wilma and Wilma Message Search applications

You can shutdown Wilma application by sending a GET/POST request to the '/config/admin/shutdown' URL.

You can shutdown Wilma Message Search application by sending a GET/POST request to the '/shutdown' URL.

Both cases, killing the application JVM works too ;)

Table Of Contents

©2021, EPAM Systems.