Skip to content

Martini Invoking Services via a URL Alias Trigger

The URL Alias trigger in Martini allows you to map memorable, concise URL paths to methods within your services, scripts, and code. This feature enhances API usability for your customers by providing straightforward URLs for service invocation, and it maintains the flexibility to update underlying code without changing the URL path. Services invoked through this trigger are accessible at the Martini root context /api, making it easier for API consumers to interact with your services.

Overview

The URL Alias trigger is key to simplifying how clients access services within Martini. It obviates the need for end-users to navigate complex URLs, offering a direct method to invoke services. This consistency is crucial for maintaining a stable API interface, despite potential changes in service implementation.

Properties

Configuring a URL Alias trigger involves specifying several properties to define its behavior and how it interacts with the targeted services:

Property Default Description
Name (required) A unique identifier for the trigger.
Service (required) The service to be executed when the trigger is activated.
Run As Anonymous The user context under which the service is executed, with actions logged for tracking.
Document Type The type of document to log in Tracker when the trigger activates.
Auto Start true Determines whether the trigger should automatically activate upon package startup.

URL Alias-Specific Configuration

To further tailor the URL Alias trigger to specific needs, additional properties are available:

Properties Default Description
URL Alias (required) The URL pattern that the service will respond to.
Request Method The HTTP method (GET, POST, etc.) that needs to match for the trigger to activate.
Secured false When set to true, restricts trigger activation to authorized users only.
Users Specifies individual users allowed to invoke the URL Alias.
Groups Identifies user groups with permission to access the URL Alias.

Configuring a URL Alias Trigger

Setting up a URL Alias trigger in Martini involves a few steps to ensure correct operation and security:

  1. Access the Martini Dashboard: Navigate to the package where your target service resides.
  2. Create a New Trigger: In the package's "Triggers" section, opt to add a new URL Alias trigger.
  3. Specify Trigger Properties:
    • Name: Provide a distinctive name for your trigger.
    • Service: Select the service to be invoked by the URL Alias.
  4. Define URL Alias-Specific Settings:
    • URL Alias: Enter the URL path that will act as the alias.
    • Request Method (optional): Choose an HTTP method to restrict the trigger to specific request types.
    • Secured: Enable and define Users or Groups if the trigger should be restricted to certain users.
  5. Activate the Trigger: Ensure "Auto Start" is enabled for the trigger to become active immediately upon configuration.

Best Practices

  • Naming: Use descriptive, intuitive names for URL aliases to clearly indicate the service's functionality.
  • Security Considerations: Secure sensitive endpoints by leveraging the "Secured" property and specifying authorized users or groups.
  • API Stability: While URL aliases can abstract service changes from users, consider implementing versioning for APIs undergoing significant modifications.

Troubleshooting

  • Trigger Not Activating: Confirm the trigger is enabled and check for URL pattern conflicts with existing aliases.
  • Access Denied: For secured triggers, verify the correctness of specified users and groups allowed to access the URL Alias.

Given the request to add examples excluding Gloop, we'll focus on illustrating how to implement and expose a Groovy service using a URL Alias trigger in Martini. This approach simplifies the process of connecting HTTP requests directly to your service logic, enhancing the API's usability and accessibility. Here's how you can achieve this with a Groovy script.

Example

Groovy Service Implementation

Let's replicate the functionality of the previous Gloop service example using Groovy. The goal is to create a service that receives a JMS queue destination and a message content via HTTP GET request parameters, and then publishes the message to the specified JMS queue. Here's a simple Groovy script that accomplishes this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
class JMSExamples {

    static String sendJms(String jmsQueue, String messageContent) {
        // Simulate publishing the message content to the JMS queue
        // This is a placeholder for the actual JMS publishing logic
        println "Publishing to $jmsQueue: $messageContent"
        return 'Message sent successfully!'
    }

}

In a real-world scenario, you would replace the println statement with actual logic to publish the message to a JMS queue. The publishTo method mentioned could be part of a Groovy extension or utility class that facilitates JMS interactions.