Module org.mule.sdk.api
Package org.mule.sdk.api.data.sample

Interface SampleDataProvider<T,A>

Type Parameters:
T - the generic type of the output value
A - the generic type of the message attributes
@MinMuleVersion("4.4") @DoNotEnforceMinMuleVersion @Experimental public interface SampleDataProvider<T,A>
Implement this interface to enhance operations and message sources with sample data that is representative of the one that the component will produce in real production scenarios. The sample data is represented as a traditional Result object which contains both the payload and attributes output values. For operation methods that return a single value instead of a Result, implementations of this interface should return Result<T, Void>.

Implementations can use annotations such as Parameter, Config and Connection to access actual parameters, configs and connections that are required in order to generate the sample data.

Implementations also MUST guarantee that the act of fetching that sample data DOES NOT generate any significant side effects on the target system.

For connectors, implementations are most valuable when they return real data from the system they connect to. This is the best practice and should be preferred over the option of simply returning hard coded values.

This interface defines two generic types for the component's output (T for the output payload and A for the output attributes). These must match the actual output types of the enhanced components. For components which returns dynamic types, it's each implementation's responsibility to return instances of the correct dynamic type.

Streaming is not supported. When providing sample data for components which return an InputStream, implementations should use a ByteArrayInputStream or any other "offline" implementation which has already procured the entire data stream before the getSample() method returns. The InputStream MUST be fully consumable even after the underlying connection has already been closed. Using temporal buffer files here is also discouraged.

Paging is streaming. The Mule Runtime considers paged operations as a particular case of streaming. Therefore, same limitations of InputStream applies. For operations which return a PagingProvider, a List of the same item types should be used instead. For example, for this method: 

 
 public PagingProvider<Map<String, Object>, Connection> pagedOperation() {

 }
The getSample() method should be defined like this: 
   public Result<List<Map<String, Object>, Void> getSample() {

   }

It is a best practice for implementations to not return large objects or data streams. Make sure that the data is relevant yet small enough to fit into the memory of a small worker instance.

Implementations MUST provide a default constructor. NOTE: Experimental feature. Backwards compatibility not guaranteed.

Since:
1.4

  • Method Summary

    Modifier and Type
    Method
    Description
    String
    getId()
    An id which identifies each implementation of this interface.
    Result<T,A>
    getSample()
    Obtains and returns the sample information.

  • Method Details

    • getId

      String getId()
      An id which identifies each implementation of this interface. It MUST be unique among implementations in the same extension. Subsequent invocations MUST always return the same fixed value.
      Returns:
      the resolver's id

    • getSample

      Result<T,A> getSample() throws SampleDataException
      Obtains and returns the sample information.
      Returns:
      a Result object
      Throws:
      SampleDataException - if the sample cannot be obtained