Fast, flexible integrations without needing external code

Introduction

IT asset management implementations typically rely on external scripts, middleware, or implementation services to integrate with other systems. That approach increases implementation time, operational overhead, and maintenance costs. While this traditional API setup is available to xAssets customers, we also provide an advanced architecture where full API capabilities plus an embedded scripting and execution environment can run inside the product.

This means you don't need to write C# or VB programs to create functionality specific to your needs - the entire functionality can be created inside your xAssets instance, so there's no security concerns with API keys, and no need to provide a platform to host your code.

Traditional API‑only integration

• External hosting for integration code (servers, containers)
• Credential and API key lifecycle management
• Monitoring, error handling and reconnection logic
• Version and compatibility testing when APIs change

xAssets approach - transformations with server‑side automation

Transformations are server-side tasks which take data from one place, and send it to another place, with conversions, translations, data cleansing, recognition, lookup refactoring, and other data manipulation as needed.

Transformations provide a scripting language called AMSX. This integrates completely with the xAssets API, and provides many other extended commands to manipulate data. It has the normal language structures like looping and IF statements.

Every capability of xAssets is accessible via the public API (the same API used by the web user interface). AMSX is a VB‑style scripting language embedded in the server subsystem. AMSX scripts execute within the platform and can perform integrations, data transformation, scheduled jobs, notifications, imports and exports.

Key functional areas where AMSX is typically used:

• Automated imports from external Excel, CSV, JSON, and API sources
• Integrate to any web service
• Run network discovery processes and import the discovered data
• Data cleansing and normalization during an import
• Integration to push data to third‑party systems
• Scheduled reconciliation and licence matching
• Email alerts and notifications
• Emails for event driven workflows
• Email reports periodically as PDF or Excel attachments

Benefits

1. Changes can be developed and deployed quickly inside the product; typical tasks complete in hours or days rather than weeks
2. Reduced operational surface area, with no separate hosting, no external credentials, no network dependencies
3. Improved security, since there is no credential transmission and scripts run internally under the xAssets batch execution context
4. Easy to maintain, since all logic is versioned and stored in your instance. Backups and restores include the automation code

When to use the API

Use the API when external systems must connect directly. The API exposes every product capability; AMSX is recommended when you want contained execution and lower operational overhead. AMSX supports advanced language constructs and can run multiple processes on different threads in parallel

Example AMSX script

A scheduled AMSX job that imports

    // Parameters will automatically construct a dialog box to prompt the user for values
    Parameters ApplicationServerCredentials, JiraProject

    Set ProjectsExist = SQL"select name from sys.objects Where object_id = OBJECT_ID(N'$TempDB$JIRAProjects') and Type = 'U'"

    If %ProjectsExist% = '' Then
        RunTransform "JIRA Get Projects"
    end if

    Set Parameter.JiraProjectName = SQL "select ProjectName from $TempDB$JIRAProjects where ProjectKey = %JiraPRoject%"

    // Get the credentials
    ReadCredentialPack "%ApplicationServerCredentials%", "domainname", "apiusername2", "apipassword2"

    if %domainname% = '' or %domainname% = '.' then
        Throw "JIRA integration requires a JIRA credential pack with the domain name set to the URL used to access the JIRA API"
    end if

    Set AssetFieldName = "%spo:JIRAAssetFieldname%"

    if %AssetFieldName% = '' Then
        Set AssetFieldName = RunTransform "JIRA Get Asset Field Name"
    end if

    // encode credentials for the http header
    Set Base64 = BASE64 "%apiusername2%:%apipassword2%"

    // JIRA uses a basic auth header
    HTTPHEADER "Authorization", "Basic %base64%", "string"

    Set url = "https://%domainname%/rest/api/3/search?jql=Project='%JIRAProjectName%'"

    // get the data from JIRA with a HTTP get
    Set json = GET "%url%", "application/json"

    // write to a file for debugging purposes
    SaveTextFile "%web%\userfiles\JIRAIssuesList.txt"

    // declare the mapping for the JSON data to move into a table
    // "issues" is the root node and the array underneath it represents each record

    TEXT

        Project:fields.project.name,
        IssueKey:key,
        IssueType:fields.issuetype.name,
        CreatedDate:fields.created,
        Summary:fields.summary,
        Description:xmltext:fields.description.content,
        Reporter:fields.reporter.displayName,
        ReporterEmail:fields.reporter.emailAddress,
        Assignee:fields.assignee.displayName,
        Status:fields.status.name,
        AssetID:fields.AssetFieldName(0).originId,
        UpdatedDate:fields.updated,
        Url:self

    ENDTEXT

    Set FieldMap = "%text%"
    Set FieldMap = replace "AssetFieldName", "%AssetFieldName%"

    // Get the variable directly into the result buffer
    GetVariable "json"

    // ... and parse the result into an xml document
    JSONTOXMLTABLE "issues","%fieldmap%"

    // Load the XML into a temp table, then the data load into the data model can run from the caller
    XMLTOTEMPTABLE "$tempdb$Jira", "0", "1"

    // Now we have our jira data in a sql server temporary table, ready to be mapped with a transformation

    RecogniseAndClean "$tempdb$Jira", "Manufacturer", "Model", "SerialNumber"

    RunTransform "JIRA Integration - Temp Table to Data Model"

Architectural Considerations

In reality, the transformation and AMSX model works best for almost all scenarios. Despite the power of being able to work with API calls from external programs, it is almost always better to place the functionality inside xAssets Transformations and AMSX scripts:

• Integrations can use AMSX except where an external program must connect into xAssets
• Prefer tranformations and AMSX for one-off and scheduled imports, data transformations, and workflows that do not require direct external access to raw data
• Reserve direct API access for real‑time integrations where another system must pull xAssets endpoints directly, e.g. to pull asset data in real time for a help desk system
• AMSX based transformations can be reused in different processes
• AMSX can run multiple processes in parallel in different threads

Conclusion

xAssets combines full API transparency with a contained execution environment (AMSX) to improve security, implementation time and reduce complexity.