Package com.oracle.bmc.loadbalancer.requests

Class UpdateRoutingPolicyRequest

  • @Generated(value="OracleSDKGenerator",
           comments="API Version: 20170115")
public class UpdateRoutingPolicyRequest
extends BmcRequest<UpdateRoutingPolicyDetails>

    Example: Click <a href=“https://docs.oracle.com/en-us/iaas/tools/java-sdk-examples/latest/loadbalancer/UpdateRoutingPolicyExample.java.html"target=”_blank"rel=“noopener noreferrer”>here to see how to use UpdateRoutingPolicyRequest.

    • Constructor Detail

      • UpdateRoutingPolicyRequest

        public UpdateRoutingPolicyRequest()

    • Method Detail

      • getUpdateRoutingPolicyDetails

        public UpdateRoutingPolicyDetails getUpdateRoutingPolicyDetails()
        The configuration details needed to update a routing policy.

      • getLoadBalancerId

        public String getLoadBalancerId()
        The OCID of the load balancer associated with the routing policy to update.

      • getRoutingPolicyName

        public String getRoutingPolicyName()
        The name of the routing policy to update.

        Example: example_routing_policy_name

      • getOpcRequestId

        public String getOpcRequestId()
        The unique Oracle-assigned identifier for the request.

        If you need to contact Oracle about a particular request, please provide the request ID.

      • getIfMatch

        public String getIfMatch()
        For optimistic concurrency control.

        In the PUT or DELETE call for a resource, set the if-match parameter to the value of the ETag for the load balancer. This value can be obtained from a GET or POST response for any resource of that load balancer.

        For example, the eTag returned by getListener can be specified as the ifMatch for updateRuleSets.

        The resource is updated or deleted only if the ETag you provide matches the resource's current ETag value.

        Example: example-etag

      • getOpcRetryToken

        public String getOpcRetryToken()
        A token that uniquely identifies a request so it can be retried in case of a timeout or server error without risk of executing that same action again.

        Retry tokens expire after 24 hours, but can be invalidated before then due to conflicting operations (e.g., if a resource has been deleted and purged from the system, then a retry of the original creation request may be rejected).