3.2 C
New Jersey
Thursday, October 17, 2024
HomeArtificial Intelligence
Artificial Intelligence

How SailPoint makes use of Anthropic’s Claude on Amazon Bedrock to routinely generate TypeScript code for SaaS connectors

Walt H
By Walt H
0
68


Generative AI is revolutionizing the best way builders method programming by offering clever help and automation all through the coding course of. With the ability of superior language fashions and machine studying (ML) algorithms, generative AI can perceive the context and intent behind a programmer’s code, providing invaluable options, finishing code snippets, and even producing total features or modules primarily based on high-level descriptions. This know-how empowers builders to concentrate on higher-level problem-solving and structure, whereas the AI handles the tedious and repetitive elements of coding. One of many key benefits of enormous language fashions (LLMs) in programming is their means to be taught from the huge quantities of current code and programming patterns they had been skilled on. This information permits them to generate context-aware code, detect potential bugs or vulnerabilities, and provide optimizations to enhance code high quality and efficiency.

On this put up, we spotlight how the AWS Generative AI Innovation Heart collaborated with SailPoint Applied sciences to construct a generative AI-based coding assistant that makes use of Anthropic’s Claude Sonnet on Amazon Bedrock to assist speed up the event of software program as a service (SaaS) connectors.

Amazon Bedrock is a completely managed service that gives a alternative of high-performing basis fashions (FMs) from main AI firms like AI21 Labs, Anthropic, Cohere, Meta, Mistral AI, Stability AI, and Amazon by means of a single API, together with a broad set of capabilities to construct generative AI purposes with safety, privateness, and accountable AI.

SailPoint focuses on enterprise identification safety options. Over 3,000 enterprises worldwide use SailPoint to assist defend in opposition to as we speak’s dynamic, identity-centric cyber threats whereas enhancing productiveness and effectivity. Their merchandise are designed to handle and safe entry to purposes and information by means of the lens of identification, at velocity and scale, for customers inside a corporation and for exterior events equivalent to non-employees. SailPoint’s unified, clever, and extensible atmosphere offers complete identification governance capabilities, together with entry certifications, coverage administration, entry request and provisioning, password administration, and information entry governance. This helps organizations be sure that the suitable people have the suitable entry to the suitable sources on the proper instances, thereby implementing safety insurance policies and compliance necessities. Based in 2005, SailPoint has grown to be a key participant in identification safety, serving clients globally throughout numerous industries.

SailPoint connectors and SaaS connectivity

SailPoint’s identification safety options interface with numerous software program as a service (SaaS) purposes to retrieve the required info, equivalent to account and entry info, from an identification safety standpoint. Every SaaS utility implements these functionalities in barely other ways and may expose their implementation by means of REST-based net APIs which might be sometimes supported by OpenAPI specs. SailPoint connectors are TypeScript modules that interface with a SaaS utility and map the related identification safety info (equivalent to accounts and entitlements) to a standardized format understood by SailPoint. Based mostly on the APIs uncovered by the appliance, SailPoint connectors can create, replace, and delete entry on these accounts. SailPoint connectors assist handle consumer identities and their entry rights throughout totally different environments inside a corporation, supporting the group’s compliance and safety efforts.

Though a typical connector exposes a number of features, for this put up, we concentrate on creating the checklist consumer perform of a connector that connects to an API endpoint for itemizing customers, retrieving all of the customers, and remodeling them into the format required by SailPoint.

Within the following sections, we element how we used Anthropic’s Claude Sonnet on Amazon Bedrock to routinely create the checklist consumer connector, a vital element of the broader SaaS connectivity.

Understanding the checklist consumer connector

Connectors are modules that may connect with an exterior service and retrieve and replace related info from a SaaS utility. To higher perceive how connectors are constructed, we give an instance of the connector perform that connects to DocuSign’s REST API’s getUsers endpoint. The next TypeScript code defines an asynchronous perform listUsers that retrieves an inventory of consumer accounts from an exterior API and constructs a structured output for every consumer:

// imports
import { Context, Response, StdAccountListHandler, StdAccountListOutput } from '@sailpoint/connector-sdk';

const listUsers: StdAccountListHandler = async (context: Context, enter: undefined, res: Response) => {
    // retrieve api key and host url from context
    let apiKey = context.apiKey;
    let hostUrl = context.hostUrl;
    let hasMore = true;
    
    // url development
    let url = `https://${hostUrl}/Administration/v2/organizations/${context.organizationId}/customers`;
    
    // loop by means of pages
    whereas (hasMore) {
        // fetch response from the endpoint
        let response = await fetch(url, {
          headers: {
            'Authorization': `Bearer ${apiKey}`
          }
        });
        let outcomes = await response.json();
  
        // processing customers from response
        let customers = outcomes.customers;
        for (const consumer of customers) {
            const output: StdAccountListOutput = {
                identification: consumer.id,
                attributes: {
                    user_name: consumer.user_name,
                    first_name: consumer.first_name,
                    last_name: consumer.last_name,
                    user_status: consumer.user_status, 
                    membership_status: consumer.membership_status, 
                    electronic mail: consumer.electronic mail,
                    created_on: consumer.created_on, 
                    membership_created_on: consumer.membership_created_on,                     
                    ds_group_id: consumer.company_groups.map(group => group.ds_group_id),
                    ds_group_account_id: consumer.company_groups.map(group => group.ds_group_account_id)                   
                }
            };
        }
        // pagination
        if (outcomes.paging.subsequent) {
          url = outcomes.paging.subsequent;
        } else {
          hasMore = false;
        }
    }
}

The next is a breakdown of what every a part of the code does:

  • Imports – The code imports a number of sorts and interfaces from @sailpoint/connector-sdk. These embrace Context, Response, StdAccountListHandler, and StdAccountListOutput, that are used to deal with the enter and output of the perform in a standardized approach inside a SailPoint atmosphere.
  • Perform definition – listUsers is outlined as an asynchronous perform appropriate with the StdAccountListHandler It makes use of the Context to entry configuration particulars like API keys and the bottom URL, and a Response to construction the output.
  • Retrieve API key and host URL – These are extracted from the context parameter. They’re used to authenticate and assemble the request URL.
  • URL development – The perform constructs the preliminary URL utilizing the hostUrl and organizationId from the context. This URL factors to an endpoint that returns customers related to a selected group.
  • Loop by means of pages – The whereas loop continues so long as there are extra pages of information (hasMore is true). It serves the next features:
    • Fetch information – Contained in the whereas loop, a fetch request is made to the API endpoint. The request consists of an Authorization header that makes use of the apiKey. The API’s response is transformed to JSON format.
    • Course of customers – Contained in the whereas loop, it extracts consumer information from the API response. The method loops by means of every consumer, establishing an StdAccountListOutput object for each. This object consists of consumer identifiers and attributes like consumer names, names, standing, electronic mail, and group IDs.
    • Pagination – Contained in the whereas loop, it checks if there’s a subsequent web page URL within the pagination info (outcomes.paging.subsequent). If it exists, it updates the url for the subsequent iteration of the loop. If not, it units hasMore to false to cease the loop.

Understanding this instance helps us perceive the step-by-step technique of constructing this perform in a connector. We intention to breed this course of utilizing an LLM with a immediate chaining technique.

Generate a TypeScript connector utilizing an LLM immediate chain

There are a number of approaches to utilizing pre-trained LLMs for code technology, with various ranges of complexity:

  • Single immediate – You should use fashions like Anthropic’s Claude to generate code by direct prompting. These fashions can generate code in quite a lot of languages, together with TypeScript, however they don’t inherently possess domain-specific information related to the duty of constructing a connector. All of the required info, together with API specs and formatting directions, should be offered within the immediate, much like the directions that might be given to a developer. Nevertheless, LLMs are likely to wrestle when given a protracted checklist of complicated directions. It’s additionally tough for the immediate engineer to grasp which steps are difficult for the LLM.
  • Agentic frameworks with LLMs – Brokers are a complicated framework that may use instruments to carry out a sequence of complicated duties. On this case, the agent begins by breaking down the consumer requests into steps, searches for needed info utilizing instruments (a information base or net browser), and autonomously generates code from begin to end. Though they’re highly effective, these frameworks are complicated to implement, typically unstable of their habits, and fewer controllable in comparison with different strategies. Brokers additionally require many LLM calls to carry out a activity, which makes them fairly gradual in apply. Within the case the place the logic to carry out a activity is a set sequence of steps, brokers aren’t an environment friendly possibility.
  • Immediate chain – An answer that finds a great trade-off between the 2 earlier approaches includes utilizing a immediate chaining approach. This technique breaks the complicated drawback right into a collection of extra manageable steps and integrates them to craft the ultimate code. Every step has clear directions which might be simpler for the LLM to observe, and a human within the loop can management the output of every step and proper the LLM if wanted. This method strikes a stability between flexibility and management, avoiding the extremes of the opposite two strategies.

We initially examined the LLM’s means to generate connector code primarily based on a single immediate and realized that it struggles to generate code that addresses all elements of the issue, equivalent to pagination or nested information constructions. To verify the LLM would cowl all the required elements of the connector features, and since making a connector follows a set sequence of steps, immediate chaining was essentially the most pure method to enhance the generated code.

The chain we used for connector technology consists of the next high-level steps:

  1. Parse the info mannequin of the API response into prescribed TypeScript lessons.
  2. Generate the perform for consumer flattening within the format anticipated by the connector interface.
  3. Perceive the pagination of the API specs and formulate a high-level resolution.
  4. Generate the code for the ListUsers perform by combining all of the intermediate steps.

Step 1 is used as an enter to Step 2, however Step 3 is separate. Each Step 2 and Step 3 outcomes are fed to Step 4 for the ultimate consequence. The next diagram illustrates this workflow.

Within the following sections, we are going to dive into the prompting strategies we used for every of those steps.

System immediate

The system immediate is a vital part of LLM prompting that sometimes offers the preliminary context to information the mannequin’s response. For all of the prompts within the chain, we used the next system immediate:

"""
You're an professional net developer who has a wonderful understanding of REST APIs and backend
API growth utilizing TypeScript. Your objective is to grasp API specification offered in 
OpenAPI specification or Swagger specification as YAML recordsdata and to jot down TypeScript code,
XML, API descriptions and so forth. as requested within the activity description. Don't deviate from the 
offered specification and documentation and if one thing is unclear within the specification then 
point out your uncertainty within the feedback don't make up info that's not out there in 
the specs or description.

When writing TypeScript code, present minimal however significant feedback.
"""

Extra particularly, the system immediate is used to determine the function of the LLM (professional net developer), give it a normal objective (perceive API specs and write TypeScript code), give high-level directions (add feedback within the code) and set boundaries (don’t make up info).

Knowledge mannequin parsing

On this step, we immediate the LLM to grasp the construction of the API response and create TypeScript lessons comparable to the objects within the response. Though this step isn’t strictly needed for producing the response, it might probably assist the LLM immensely in producing an accurate connector. Just like chain-of-thought reasoning for arithmetic issues, it’s forcing the LLM to “assume” earlier than responding.

This step affords two main advantages:

  • Verbose API response simplification – API responses specified within the documentation may be fairly verbose. By changing the response construction into TypeScript lessons, we compress the knowledge into fewer strains of code, making it extra concise and simpler for the LLM to understand. This step helps make sure that the important info is prominently displayed at the beginning.
  • Dealing with fragmented consumer responses – In some APIs, the consumer response consists of a number of fragments due to the reuse of information constructions. The OpenAPI specification makes use of the $ref tag to reference these reusable elements. By changing the consumer response into TypeScript lessons, we are able to consolidate all of the related info right into a single location. This consolidation simplifies the downstream steps by offering a centralized supply of knowledge.

We use the next activity immediate to transform the API response into prescribed TypeScript lessons:

"""
You're given an API spec of OpenAPI or Swagger for a REST API endpoint
that serves an inventory of customers for Software program as a Service (SaaS) utility. You'll 
be requested to extract the construction of the Person within the JSON response from the API endpoint. 

Right here is the API spec offered between the XML tags  . 
Perceive and keep in mind the API spec properly.


{api_spec}


Use the next directions to create TypeScript interfaces primarily based on the construction 
of the Person. 

- Present the code in between   XML tags. 
- If there are any nested objects, develop them into their very own interfaces.
- Be complete and embrace all attributes.
- Retrieve all attributes, together with these marked as not obligatory, not required, or nullable.
- The attributes are listed below `properties` part.
- Output just one Person interface that features all of the attributes from any interfaces it extends.


The anticipated format of the output is as follows: 
 
// Person
interface Person {{
  id: quantity;
  first_name: string;
  last_name: string;
  electronic mail: string;
  is_active: boolean;
  company_groups_ids: quantity[];
  other_attribute: string;
  nested_type: NestedType[];
}}

// Some complicated kind
interface NestedType {{
    type_id: string;
    some_string_attribute: string;
    some_number_attribute: quantity;
}}


"""

Within the previous immediate template, the variable {api_spec} is changed with the API specification of the endpoint. A particular instance for a DocuSign ListUsers endpoint is offered within the appendix.

The next code is an instance of the LLM-generated lessons when utilized to the DocuSign API specs. This has been parsed out of the tags.

// Person
interface Person  'activation_sent' 
  
// DsGroup
interface DsGroup {
    ds_group_id: string; // format: uuid
    account_id: string; // format: uuid
    source_product_name: string;
    group_id: string;
    group_name: string;
    description: string;
    is_admin: boolean;
    last_modified_on: string; // format: date-time
    user_count: quantity; // format: int32
    external_account_id: quantity; // format: int64
    account_name: string;
    membership_id: string; // format: uuid
}

Person flattening perform technology

The anticipated construction for every consumer is an object consisting of two properties: an identifier and a dictionary of attributes. The attributes dictionary is a map that associates string keys with both primitive attributes (quantity, Boolean, or string) or an array of primitive attributes. due to the potential for arbitrarily nested JSON object constructions within the response, we use the capabilities of an LLM to generate a consumer flattening and conversion perform. Each the consumer ID and the attributes are extracted from the response. By using this method, we successfully separate the intricate activity of changing the consumer construction from the REST API response into the required format for the SailPoint connector SDK (hereafter known as the connector SDK).

The advantages of this method are twofold. First, it permits for a cleaner and extra modular code design, as a result of the complicated conversion course of is abstracted away from the principle code base. Second, it allows better flexibility and adaptableness, as a result of the conversion perform may be modified or regenerated to accommodate modifications within the API response construction or the connector SDK necessities, with out necessitating intensive modifications to the encompassing code base.

We use the next immediate to generate the conversion perform, which takes as enter the info mannequin generated within the earlier step:

"""
Perceive and keep in mind the next information mannequin offered 
as a set of TypeScript class definitions.
You may be required to generate a TypeScript perform primarily based on the 
information mannequin offered between   XML tags.


{data_model}


DO NOT use the TypeScript interfaces outlined above within the code you write, 
as they are going to be unavailable. Substitute them with the kind `any` the place required 
to jot down code that works with strict TypeScript.

Given the TypeScript class definitions and information mannequin above, your objectives is to
write a TypeScript perform that transforms the consumer into an object containing two
keys - an `identification` and `attributes`. The attributes is an inventory of attributes
aside from the identifier attribute.

Listed below are the foundations for mapping attributes from the consumer object to attributes area:


- The perform takes in a consumer and return StdAccountListOutput.
- Extract all attributes specified within the consumer schema above within the 
- attributes can solely comprise both primitives values or array of primitive values.
- Decide the kind of the attribute from the  above. Don't guess it from the
names of the attributes. E.g. if the identify is plural do not assume it's an array.
- All primitive attributes equivalent to string and numbers are copied with out transformation.
- All arrays of primitive attributes are copied with out transformation.
- All objects are flattened out and their attributes are copied as easy attributes.
- All arrays of objects are transformed into a number of attributes the place every attribute is an array of primitive kind. 
See additional instruction beneath between the XML tags .
- Use `any` kind in features and arrow perform definitions in order that it really works with TypeScript.





Think about the next construction of the response the place `obj_array` is an attribute that's array of objects of kind `MyObj`.
Then within the flattening course of, for the response, you will want to transform the `obj_array` attribute 
into a number of attributes like `obj_array_attribute1`, `obj_array_attribute2` every of which is an array of strings on this case.

interface Person {{
  id: string; // format: uuid
  user_name: string;
  first_name: string;
  obj_array: MyObject[];
}}

interface MyObj {{
  attribute1: string; // format: uuid
  attribute2: string; // format: uuid
  attribute3: string;
}}
 


Output the code based on the template program beneath enclosed between the  XML tags.

This perform is a component of a bigger program so hold the StdAccountListOutput within the perform as it's.
Don't overcomplicate and write easy, properly readable code. 



perform flattenUser(consumer: any): StdAccountListOutput {{
  return {{
    identification: consumer.id,
    attributes: {{
      first_name: consumer.first_name,
      last_name: consumer.last_name,
      user_type: consumer.kind,
      login: consumer.login,
      electronic mail: consumer.electronic mail,
      location: consumer.location,
      employee_id: consumer.employee_id,
      reviewer_id: consumer.reviewer_id,
      is_active: consumer.is_active,
      struct_array_attribute: consumer.struct_array.map( (val: any) => val.struct_attribute)
    }}
  }}
}};


"""

Within the previous immediate template, we substitute the {data_model} variable with the info mannequin of TypeScript lessons extracted within the earlier technology step of parsing the info mannequin.

The next code is an instance of the LLM-generated consumer flattening perform when utilized to the DocuSign API:

perform flattenUser(consumer: any): StdAccountListOutput {
    const identification = consumer.id;
    const attributes: { [key: string]: any } = {};
  
    // Copy primitive attributes
    attributes.user_name = consumer.user_name;
    attributes.first_name = consumer.first_name;
    attributes.last_name = consumer.last_name;
    attributes.user_status = consumer.user_status;
    attributes.membership_status = consumer.membership_status;
    attributes.electronic mail = consumer.electronic mail;
    attributes.created_on = consumer.created_on;
    attributes.membership_created_on = consumer.membership_created_on;
  
    // Convert array of objects to a number of attributes
    const dsGroupAttributes: { [key: string]: any[] } = {};
    consumer.ds_groups.forEach((dsGroup: any) =>  [];
      dsGroupAttributes.last_modified_on.push(dsGroup.last_modified_on);
  
      dsGroupAttributes.user_count = dsGroupAttributes.user_count );
  
    Object.assign(attributes, dsGroupAttributes);
  
    return {
      identification,
      attributes
    };
}

Pagination understanding

As talked about earlier, the REST API can implement a number of pagination schemes. Typically, the pagination particulars aren’t explicitly talked about. Throughout the growth of the chain, we discovered that when there are a number of pagination schemes, the LLM would combine up parts of various pagination schemes and output code that isn’t coherent and typically additionally accommodates errors. As a result of looping over the paged outcomes is an important step, we separate out this step within the code technology to let the LLM perceive the pagination scheme applied by the API and formulate its response at a excessive stage earlier than outputting the code. This enables the LLM to assume step-by-step in formulating the response. This step generates the intermediate reasoning, which is fed into the subsequent and closing step: producing the checklist customers perform code.

We use the next immediate to get the pagination logic. As a result of we’re utilizing Anthropic’s Claude Sonnet on Amazon Bedrock, we ask the LLM to output the logic in XML format, which is thought to be an environment friendly strategy to construction info for that mannequin.

"""
Perceive and keep in mind the next OpenAPI specification offered between the
  XML tags. You'll reply questions primarily based on this specification,
which describes an endpoint for itemizing customers from a SaaS utility. 


{api_spec}


Along with the specification, use the next details about the API to 
perceive the small print that aren't out there within the spec. The small print
are included in between XML tags  .


{api_info}


The checklist customers API is used to acquire an inventory of customers from the API. This API
might implement a number of pagination schemes to retrieve the checklist of customers. 
Pagination is used to retrieve pages of outcomes separately as a substitute of 
unexpectedly.

Your objective is to grasp the a number of pagination schemes applied 
within the API finish level and use the only scheme to loop over the pages
to retrieve all of the customers. 

First describe in particulars how the pagination is applied by the API 
in a step-by-step method. Embody the small print of the right way to get the primary 
web page after which the right way to get the following pages. Present the output in between
the XML tags  . If the API doesn't 
implement pagination then output "No pagination applied".

If the API implements a number of pagination schemes: 
- Choose the best scheme and implement utilizing solely that one scheme. 
- If the API response accommodates a subsequent URL both within the response physique or the 
headers, want that pagination scheme over extra complicated offset-based schemes.

If there may be inadequate or lacking info within the specs then don't
make up or guess it. Specify it within the output.

Output the leads to the next format


     checklist all of the pagination schemes 
     choose one scheme to implement looping 
     steps to get first web page 
     steps to get subsequent web page 
     situation for exiting loop 
     sure/no 

"""

Within the previous immediate template, the variable {api_spec} is changed with the API specification. An instance of the DocuSign API is offered within the appendix on the finish of this put up. The variable {api_info} may be changed with further API documentation in pure language, which is left as an empty string within the DocuSign instance.

The next is the LLM’s response for the pagination logic extraction within the case of the DocuSign API, parsed out of the tags:

"""

1. Offset-based pagination utilizing the beginning and take question parameters. 
2. Index-based pagination utilizing the beginning and finish question parameters. 
3. Hyperlink-based pagination utilizing the subsequent and former hyperlinks within the response.



Hyperlink-based pagination utilizing the subsequent and former hyperlinks within the response.



1. Make a GET request to the /v2/organizations/{organizationId}/customers endpoint with none pagination parameters. 
2. The response will comprise the primary web page of outcomes and a subsequent hyperlink for the subsequent web page (if there are extra outcomes).



1. Examine if the response accommodates a subsequent hyperlink. 
2. If the subsequent hyperlink is current, make a GET request to the URL offered within the subsequent hyperlink. 
3. The response will comprise the subsequent web page of outcomes and a subsequent hyperlink for the following web page (if there are extra outcomes).



Proceed making requests to the subsequent hyperlink till the response not accommodates a subsequent hyperlink, indicating that there aren't any extra pages.



sure

"""

ListUsers perform technology

This closing step within the chain combines the knowledge extracted within the earlier steps along with the consumer flattening perform generated within the earlier steps to formulate the ultimate response, which is the TypeScript perform that retrieves an inventory of customers from the offered API.

We use the next immediate to generate the entire TypeScript perform:

"""
Your activity is to jot down a TypeScript program to retrieve an inventory of customers from REST API. Detailed
directions for the duty are offered beneath. The API sometimes returns a set of customers at a
time, you'll have to paginate by means of the outcomes to retrieve all customers whereas there are extra 
outcomes remaining.

Perceive and keep in mind the next OpenAPI YAML specification offered between the
  XML tags you may be requested to jot down a TypeScript program primarily based on it.


{api_spec}


Along with the specs the next documentation and implementation particulars concerning the
API are offered in between the XML tags  .


{api_info}


The next pagination logic laid out in between   XML 
tags offers excessive stage particulars on  the right way to implement looping over paginated outcomes to retrieve 
all of the customers. Choose the pagination based on the desire mentions within the pagination logic beneath.


{pagination_logic}



Now, implement a TypeScript perform that retrieves all of the customers following the directions beneath

- Don't modify the `flattenUser` perform and reproduce it as it's.
- Change solely the BODY of `listUsers` perform however don't modify the perform signature as it's
a part of the massive program that expects this perform signature.
- Don't create or invent any new sorts.
- For pagination adhere to the directions offered in  and 
- If pagination requires variety of outcomes, then fetch 50 customers at a time.
- Assume that `context.hostUrl` from the enter context will present the API hostname and port within the 
format "hostname:port_number" or "host_ip_address:port_number".
- If the API makes use of a Hyperlink primarily based pagination you then sometimes don't have to reconstruct the url utilizing
`hostUrl` as the entire hyperlink can be offered within the subsequent url or within the hyperlink headers.
- substitute the `endpoint_url` with the endpoint url offered within the specs.
- You'll be able to assume that any required values equivalent to `apiKey` can be offered within the `context` variable.
- Change the authorization headers to match the knowledge within the headers.
- Assume that any parameters which might be required to assemble the trail are equipped by means of `context` variable. The names of such variable 
will match precisely with the variable specified within the templated path within the API specs.


Right here is the instance output


import {{ Context, Response, StdAccountListHandler, StdAccountListOutput }} from '@sailpoint/connector-sdk';

{flatten_user_function}

const listUsers: StdAccountListHandler = async (context: Context, enter: undefined, res: Response) => {{
    let apiKey = context.apiKey;
    let hostUrl = context.hostUrl;
    let hasMore = true;

    let url="http://${{hostUrl}}/{{endpoint_path}}";
    whereas (hasMore) {{

        // fetch response from the endpoint
        let response = await fetch(url, {{
          headers: {{
            'Authorization': `${{apiKey}}`
          }}
        }});
        let outcomes = await response.json();

        // get the customers from the returned outcomes
        let customers = outcomes.customers;
        for (let consumer of customers) {{
            flattened_user = flattenUser(consumer)
            res.ship(flattened_user);
        }}

        // Set the url to the "subsequent" URL from the response whether it is out there
        if (outcomes.subsequent) {{
          url = outcomes.subsequent;
        }} else {{
          hasMore = false;
        }}
    }}
}}


Output the generated code between the XML tags   and 
solely output the code with none further formatting like triple quotes.
"""

On this immediate, we substitute {flatten_user_function} with the flattenUser that was generated earlier and {pagination_logic} with the one which was generated earlier. We offer a template for the listUsers perform to ensure the ultimate output meets the necessities for the connector perform. The ensuing output is the next listUsers perform, which makes use of the flattenUser perform from earlier:

const listAccounts: StdAccountListHandler = async (context: Context, enter: undefined, res: Response) => {
    let apiKey = context.apiKey;
    let hostUrl = context.hostUrl;
    let organizationId = context.organizationId;
    let hasMore = true;

    let url = `https://${hostUrl}/Administration/v2/organizations/${organizationId}/customers`;
    whereas (hasMore) {

        // fetch response from the endpoint
        let response = await fetch(url, {
          headers: {
            'Authorization': `Bearer ${apiKey}`
          }
        });
        let outcomes = await response.json();

        // get the customers from the returned outcomes
        let customers = outcomes.customers;
        for (let consumer of customers) {
            let flattened_user = flattenUser(consumer)
            res.ship(flattened_user);
        }

        // Set the url to the "subsequent" URL from the response whether it is out there
        if (outcomes.paging.subsequent) {
          url = outcomes.paging.subsequent;
        } else {
          hasMore = false;
        }
    }
}

Classes realized

On this put up, we demonstrated how LLMs can tackle complicated code technology issues by using numerous core prompting rules and the immediate chaining approach. Though LLMs excel at following clearly outlined directions and producing small code snippets, this use case concerned a considerable quantity of contextual info within the type of API specs and consumer directions. Our findings from this train are the next:

  • Decomposing complicated issues – Breaking down a fancy code technology drawback into a number of intermediate steps of decrease complexity enhances the LLM’s efficiency. Offering a single complicated immediate can lead to the LLM lacking some directions. The immediate chaining method enhances the robustness of the technology, sustaining higher adherence to directions.
  • Iterative optimization – This technique permits for iterative optimization of intermediate steps. Every a part of the chain may be refined independently earlier than shifting to the subsequent step. LLMs may be delicate to minor modifications in directions, and adjusting one facet can unintentionally have an effect on different targets. Immediate chaining affords a scientific strategy to optimize every step independently.
  • Dealing with complicated selections – Within the part on understanding pagination, we illustrated how LLMs can cause by means of numerous choices and make complicated selections earlier than producing code. For example, when the enter API specification helps a number of pagination schemes, we prompted the LLM to determine on the pagination method earlier than implementing the code. With direct code technology, with out utilizing an intermediate reasoning step, the LLM tended to combine parts of various pagination schemes, leading to inconsistent output. By forcing decision-making first, in pure language, we achieved extra constant and correct code technology.

By automated code technology, SailPoint was in a position to dramatically scale back connector growth time from hours or days to mere minutes. The method additionally democratizes code growth, so that you don’t want deep TypeScript experience or intimate familiarity with SailPoint’s connector SDK. By accelerating connector technology, SailPoint considerably shortens the general buyer onboarding course of. This streamlined workflow not solely saves invaluable developer time but additionally allows quicker integration of numerous programs, finally permitting clients to make use of SailPoint’s identification safety options extra quickly and successfully.

Conclusion

Our AI-powered resolution for producing connector code opens up new prospects for integrating with REST APIs. By automating the creation of connectors from API specs, builders can quickly construct strong connections to any REST API, saving developer time and lowering the time to worth for onboarding new clients. As demonstrated on this put up, this know-how can considerably streamline the method of working with numerous APIs, permitting groups to concentrate on utilizing the info and performance these APIs present fairly than getting overwhelmed by connector code particulars. Think about how such an answer may improve your personal API integration efforts—it may very well be the important thing to extra environment friendly and efficient use of the myriad APIs out there in as we speak’s interconnected digital panorama.

Concerning the Authors

Erik Huckle is the product lead for AI at SailPoint, the place he works to resolve vital buyer issues within the identification safety ecosystem by means of generative AI and information applied sciences. Previous to SailPoint, Erik co-founded a startup in robotic automation and later joined AWS as the primary product rent at Amazon One. Erik mentors native startups and serves as a board member and tech committee lead for a EdTech nonprofit group.

Tyler McDonnell is the engineering head of AI at SailPoint, the place he leads the event of AI options to drive innovation and affect in identification safety world. Previous to SailPoint, Tyler led machine studying analysis and engineering groups at a number of early to late-stage startups and revealed work in domains spanning software program upkeep, info retrieval, and deep studying. He’s enthusiastic about constructing merchandise that use AI to carry optimistic affect to actual individuals and issues.

Anveshi Charuvaka is a Senior Utilized Scientist on the Generative AI Innovation Heart, the place he helps clients undertake Generative AI by implementing options for his or her vital enterprise challenges. With a PhD in Machine Studying and over a decade of expertise, he focuses on making use of revolutionary machine studying and generative AI strategies to deal with complicated real-world issues.

Aude Genevay is a Senior Utilized Scientist on the Generative AI Innovation Heart, the place she helps clients deal with vital enterprise challenges and create worth utilizing generative AI. She holds a PhD in theoretical machine studying and enjoys turning cutting-edge analysis into real-world options.

Mofijul Islam is an Utilized Scientist II on the AWS Generative AI Innovation Heart, the place he helps clients deal with complicated, customer-centric analysis challenges utilizing generative AI, giant language fashions (LLM), multi-agent studying, and multimodal studying. He holds a PhD in machine studying from the College of Virginia, the place his work centered on multimodal machine studying, multilingual NLP, and multitask studying. His analysis has been revealed in top-tier conferences like NeurIPS, ICLR, AISTATS, and AAAI, in addition to IEEE and ACM Transactions.

Yasin Khatami is a Senior Utilized Scientist on the Generative AI Innovation Heart. With greater than a decade of expertise in synthetic intelligence (AI), he implements state-of-the-art AI merchandise for AWS clients to drive effectivity and worth for buyer platforms. His experience is in generative AI, giant language fashions (LLM), multi-agent strategies, and multimodal studying.

Karthik Ram is a Principal Options Architect with Amazon Internet Companies primarily based in Columbus, Ohio. He works with Impartial Software program Distributors (ISVs) to construct safe and revolutionary cloud options, together with serving to with their merchandise and fixing their enterprise issues utilizing data-driven approaches. Karthik’s space of depth is Cloud Safety with a concentrate on Infrastructure Safety and risk detection.

Appendix

The next API specs had been used for the experiments on this put up:

Copyright (c) 2017- DocuSign, Inc. (https://www.docusign.com)
swagger: '2.0'
information:
  title: DocuSign API
  model: v2.1
host: api.docusign.web
basePath: "/Administration"
schemes:
- https
consumes:
- utility/json
produces:
- utility/json
paths:
  "/v2/organizations/{organizationId}/customers":
    get:
      tags:
      - Customers
      abstract: Returns details about the customers in a corporation.
      description: |-
        Returns details about the customers in a corporation.

        You have to embrace a minimum of one of many following question parameters within the request:

        - `account_id`: The ID of an account related to the group.
        - `organization_reserved_domain_id`: The ID of one of many group's reserved domains.
        - `electronic mail`: An electronic mail tackle related to the customers that you just wish to return.
      operationId: OrganizationUser_OrganizationUsers_GetV2
      produces:
      - utility/json
      parameters:
      - identify: organizationId
        in: path
        description: The group ID Guid
        required: true
        kind: string
        format: uuid
      - identify: begin
        in: question
        description: Index of first merchandise to incorporate within the response. The default worth
          is 0.
        required: false
        kind: integer
        format: int32
      - identify: take
        in: question
        description: Web page measurement of the response. The default worth is 20.
        required: false
        kind: integer
        format: int32
      - identify: finish
        in: question
        description: Index of the final merchandise to incorporate within the response. Ignored if
          `take` parameter is specified.
        required: false
        kind: integer
        format: int32
      - identify: electronic mail
        in: question
        description: E mail tackle of the specified consumer. At the least one in all `electronic mail`, `account_id`
          or `organization_reserved_domain_id` should be specified.
        required: false
        kind: string
      - identify: email_user_name_like
        in: question
        description: Selects customers by sample matching on the consumer's electronic mail tackle
        required: false
        kind: string
      - identify: standing
        in: question
        description: Standing.
        required: false
        kind: string
      - identify: membership_status
        in: question
        description: |
          The consumer's membership standing. One in all:

          - `activation_required`
          - `activation_sent`
          - `lively`
          - `closed`
          - `disabled`
        required: false
        kind: string
      - identify: account_id
        in: question
        description: Choose customers which might be members of the required account. At the least
          one in all `electronic mail`, `account_id` or `organization_reserved_domain_id` should be
          specified.
        required: false
        kind: string
        format: uuid
      - identify: organization_reserved_domain_id
        in: question
        description: Choose customers which might be within the specified area. At the least one in all
          `electronic mail`, `account_id` or `organization_reserved_domain_id` should be specified.
        required: false
        kind: string
        format: uuid
      - identify: last_modified_since
        in: question
        description: Choose customers whose information have been modified for the reason that date specified.
          `account_id` or `organization_reserved_domain_id` should be specified.
        required: false
        kind: string
      responses:
        '200':
          description: OK
          schema:
            kind: object
            properties:
              customers:
                kind: array
                gadgets:
                  kind: object
                  properties:
                    id:
                      format: uuid
                      kind: string
                      instance: 00000000-0000-0000-0000-000000000000
                      description: The consumer's distinctive ID.
                    user_name:
                      kind: string
                      description: The complete identify of the consumer.
                    first_name:
                      kind: string
                      description: The consumer's first identify.
                    last_name:
                      kind: string
                      description: The consumer's final identify.
                    user_status:
                      kind: string
                      description: |
                        The consumer's standing. One in all:

                        - `lively`
                        - `created`
                        - `closed`
                    membership_status:
                      kind: string
                      description: |
                        The consumer's membership standing. One in all:

                        - `activation_required`
                        - `activation_sent`
                        - `lively`
                        - `closed`
                        - `disabled`
                    electronic mail:
                      kind: string
                      description: The e-mail tackle.
                    created_on:
                      format: date-time
                      kind: string
                      description: The date the consumer's account was created.
                    membership_created_on:
                      format: date-time
                      kind: string
                      description: The date on which the consumer turned a member of the group.
                    ds_groups:
                      kind: array
                      gadgets:
                        kind: object
                        properties:
                          ds_group_id:
                            format: uuid
                            kind: string
                            instance: 00000000-0000-0000-0000-000000000000
                            description: ''
                          account_id:
                            format: uuid
                            kind: string
                            instance: 00000000-0000-0000-0000-000000000000
                            description: Choose customers which might be members of the required account. At the least
                              one in all `electronic mail`, `account_id` or `organization_reserved_domain_id` should be
                              specified.
                          source_product_name:
                            kind: string
                          group_id:
                            kind: string
                          group_name:
                            kind: string
                          description:
                            kind: string
                          is_admin:
                            kind: boolean
                          last_modified_on:
                            format: date-time
                            kind: string
                          user_count:
                            format: int32
                            kind: integer
                          external_account_id:
                            format: int64
                            kind: integer
                          account_name:
                            kind: string
                          membership_id:
                            format: uuid
                            kind: string
                            instance: 00000000-0000-0000-0000-000000000000
                  description: Details about a consumer.
                description: An inventory of customers.
              paging:
                  kind: object
                  properties:
                    result_set_size:
                      format: int32
                      kind: integer
                      description: The variety of gadgets in a consequence set (web page).
                    result_set_start_position:
                      format: int32
                      kind: integer
                      description: The index place of the primary consequence on this set.
                    result_set_end_position:
                      format: int32
                      kind: integer
                      description: The index place of the final consequence on this set.
                    total_set_size:
                      format: int32
                      kind: integer
                      description: The overall variety of outcomes.
                    subsequent:
                      kind: string
                      description: 'A URL to the subsequent set of outcomes. '
                    earlier:
                      kind: string
                      description: 'A URL to the earlier set of outcomes. '
                  description: Accommodates details about paging by means of the outcomes.
            description: A response containing details about customers.

Previous article
Exactly Publicizes Breakthrough in Knowledge Enrichment with New Knowledge Graph API
Next article
ESA Selects Kepler for HydRON House-Primarily based Terabit Broadband Community
Walt H
Walt Hhttps://linkclicks.co

Related Articles

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Stay Connected

237FansLike
121FollowersFollow
17FollowersFollow

Latest Articles

Load more

Welcome to LinkClicks! Our blog is dedicated to exploring the rapidly evolving world of Technology & Internet Marketing. Whether you're a tech enthusiast, a digital marketer, or simply someone who wants to stay ahead in the digital age, we aim to provide valuable insights, trends, and tips to help you navigate these fast-paced industries. At LinkClicks, we believe in delivering content that not only informs but also empowers you to take action. From in-depth analyses of cutting-edge technologies to practical marketing strategies, our mission is to be your go-to resource for everything tech and marketing. Feel free to explore our latest articles and updates here.

Contact us: email@linkclicks.co

Copyright © 2024 linkclicks.co All rights reserved