GetAddInInfo API¶

Returns version and description information for the specified infoRouter client Add-in. Add-in clients (such as the Microsoft Word or Outlook add-ins) call this API at startup to check whether their installed version is current. You can also call it programmatically to verify whether a particular add-in has been deployed to the server and to read its published version metadata.

This operation takes no authentication ticket. There is no parameter for one, so every caller is anonymous and the installed add-ins and their versions can be read by anybody who can reach the server. GetAddIns, which lists the same facts, does take a ticket.

Endpoint¶

/srv.asmx/GetAddInInfo

Methods¶

• GET /srv.asmx/GetAddInInfo?AddInName=...
• POST /srv.asmx/GetAddInInfo (form data)
• SOAP Action: http://tempuri.org/GetAddInInfo

Parameters¶

Response¶

Success Response¶

Returns a <response> element with success="true" and the add-in metadata as attributes. The Name attribute is always returned in uppercase.

<response success="true"
          Name="WORDADDIN"
          Version="8.1.150"
          DLLVersion="8.1.150.0"
          Description="infoRouter Word Add-in" />

Response Attributes¶

Error Response -" Add-in Not Found¶

<response success="false" errorCode="4041" error="A request to check for a newer version of the infoRouter Add-in failed.
The add-in information could not be found on the server.
Please contact your Administrator." />

The three sentences are separated by real line breaks. They used to be the literal characters backslash-r backslash-n, so a client that showed the message showed the backslashes.

Error Response -" Server Error¶

<response success="false" error="SystemError: ..." />

Required Permissions¶

No authentication is required. This API does not accept an authentication ticket and can be called anonymously. It is intended for use by infoRouter client add-ins during their startup version check.

Example¶

GET Request¶

GET /srv.asmx/GetAddInInfo?AddInName=WORDADDIN HTTP/1.1

POST Request¶

POST /srv.asmx/GetAddInInfo HTTP/1.1
Content-Type: application/x-www-form-urlencoded

AddInName=WORDADDIN

SOAP Request¶

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:tns="http://tempuri.org/">
  <soap:Body>
    <tns:GetAddInInfo>
      <tns:AddInName>WORDADDIN</tns:AddInName>
    </tns:GetAddInInfo>
  </soap:Body>
</soap:Envelope>

JavaScript¶

Every call answers XML with HTTP 200, success or not, so success is the thing to branch on and errorCode is the number to report.

async function call(action, params) {
  const response = await fetch(`/srv.asmx/${action}?${new URLSearchParams(params)}`);
  const root = new DOMParser()
    .parseFromString(await response.text(), 'text/xml')
    .documentElement;

  if (root.getAttribute('success') !== 'true') {
    throw new Error(`${root.getAttribute('errorCode')}: ${root.getAttribute('error')}`);
  }
  return root;
}

The version and description of one add-in.

// No ticket: this operation has no authenticationTicket parameter.
const response = await fetch(`/srv.asmx/GetAddInInfo?${new URLSearchParams({ AddInName: 'SCANSTATION' })}`);
const root = new DOMParser().parseFromString(await response.text(), 'text/xml').documentElement;

root.getAttribute('Name');          // upper cased, whatever case was asked for
root.getAttribute('Version');
root.getAttribute('DLLVersion');
root.getAttribute('Description');

This is what a client calls to find out whether the copy it has is current. The name is upper cased before the folder is looked for, so case does not matter.

Notes¶

• Case-insensitive name: The AddInName parameter is converted to uppercase before the server looks up the add-in directory. wordaddin, WordAddin, and WORDADDIN all resolve to the same directory.
• No authentication ticket: unlike nearly all other infoRouter APIs, this endpoint has no AuthenticationTicket parameter at all, so the installed add-ins and their versions can be read by anybody who can reach the server. It is designed to be called by the add-in before a user has logged in. GetAddIns, which lists the same facts, does take a ticket.
• Server-side file location: The add-in metadata is read from an info.ini file inside a subdirectory named after the add-in (uppercase) within the server's configured add-in path. If the directory or file does not exist the API returns the "not found" error message.
• Non-standard error message: when the add-in is not found, the error string is a three-line message intended to be shown to the end user as it stands. The errorCode is 4041 as everywhere else.
• Version fields may be empty: If Version, DLLVersion, or Description keys are absent from info.ini the corresponding attributes are returned as empty strings.

Related APIs¶

• GetAddInPart - Download the add-in installation package (parts.zip) as a byte array

Error Codes¶

The errorCode values this operation returns, checked against a running server:

A name that tries to walk out of the add-in folder is refused with two sentences: "Invalid file or directory name." and what was wrong with it. They used to be concatenated with no separator at all. | HTTP 400 | AddInName was empty; refused by model binding, so there is no error document |

The not-found message is three sentences on three lines, meant to be shown to the user as it is.