# Partitions (Tenants)

Partitions allow you to segregate a Telephony Server into multiple areas in order to only allow users specific visibility on certain Devices & ACD Agents when running reports or administering the Akixi Application. Within the Akixi Application, Devices and ACD Agents always belong to a specific Partition (tenant).

Partition entries are the nearest concept within Akixi that defines a “Customer Site”. Due to the fact that each telephony platform environment is configured differently, a Partition can in some deployments be specifically associated with a single sub-site within an enterprise, or conversely associated to an entire large multi-site enterprise.

For Cisco BroadWorks® telephony environments, a Partition within Akixi can be made to represent any of the hierarchical levels supported by BroadWorks such Service Provider, Enterprise, and Group components levels. However, note that the corresponding hierarchical level must be implicitly accessible via the BroadWorks API integration credentials specified on the appropriate Telephony Server that the corresponding Partition is configured against. To learn more about how to specifically integrate external BroadWorks provisioning systems with the Akixi Service, refer to the corresponding sub-heading.

In the following sub-sections, you will learn how to programmatically create, modify, delete and view Partitions.

# Supported Operations

The list of currently supported Partition operations is provided below. Operations related to Akixi Partition components start with a “Partition” prefix. They will be referred to as “Partition Operations” interchangeably hereafter.

Please note that depending on your assigned Akixi Telephony Server privileges, you may only have access to view & configure one particular Telephony Server entry. Refer back to the application administrator that created your particular User account in order to gain additional privileges.

# The Common Devices Partition

Whenever a new Telephony Server configuration entry is created, a default common devices Partition (tenant) is always created for it. The common devices Partition is where shared Devices should be created that all Partitions require access to, such as trunk gateway Devices, voice mail etc. The use & your API interaction for the common devices Partition differs slightly depending on whether the type configured against the corresponding owning Telephony Server is set to be for PBX or hosted telephony platforms as follows:

• PBX Environments: For PBX telephony environments, all Devices & ACD Agents are usually created & maintained within the single common devices Partition – no further Partition entries ordinarily need to be created.
• Hosted Environments However for hosted telephony environments, the common devices Partition should only contain the special “pseudo” Devices such as the [Trunk],[Conference], etc. Devices, which are required to model certain complex call scenarios where these Devices should never ever be removed. These pseudo Devices are created by default. The common devices Partition should also not require any further provisioning interaction on hosted environments, either manually invoked or programmatically via the Web Services API.

# Partition Usage Strategy

The way that Telephony Server component and Partition are configured to be associated with Customer telephony environments, depends on the particular telephony platform being employed as follows:

# PBX Platforms

# Hosted Platfroms

# Partition Configuration Synchronisation

A concept called configuration synchronisation can be performed for Partition components on hosted telephony platforms, where the Akixi Service’s Device & ACD Agent configuration is automatically updated by extracting it from the underlying telephony platform. This may be performed on-demand from within the Akixi Service user interface, or programmatically via PartitionAdd & PartitionChange requests by also specifically setting the SyncNow Property to True.

Note that the configuration synchronisation logic is performed asynchronously as a background task within the Akixi Service server-side, which can take 20s to several minutes to complete, depending on the size of the corresponding Customer telephony environment. The operation also does not “block” the original invoking operation (whether submitted via the user interface or programmatically via the Web Services API), which effectively would have originally updated the corresponding Partition’s SyncNow Property to True.

Additionally two types of configuration synchronisation can be performed which depends on the SyncType Property:

# Light Synchronisation (‘1’)

This performs the synchronisation process but without increasing monthly billing charges in any way. The Akixi Service configuration for non-billable Devices such as hunt groups, call centre queues, voice mail applications, automated attendants, etc. are added or updated. The descriptions and/or device numbers are also changed accordingly for existing billable Device & ACD Agent entries, should they be detected as having being modified since the last synchronisation invocation, but no new billable Akixi configuration elements are ever created. The “light” synchronisation is performed automatically as well for each Partition once per day out-of-hours, at a randomly chosen time between 10PM and 5AM.

# Full Synchronisation (‘2’ & ‘3’)

An incremental billing-affecting synchronisation operation is performed where all Devices & ACD Agents existing within the underlying telephony platform are all added and/or updated into the Akixi Service configuration.

It is not recommended to programmatically invoke the full synchronisation using PartitionAdd or PartitionChange operations, since all Device/Agent items would get added regardless, where the associated Customer may not want to pay for reporting data collection across all those elements anyway. Instead, you should programmatically add the Akixi Service billing affecting extension Device & ACD Agent configuration using other WS API operations as required.

# Partition Request Parameters

As previously mentioned, some PartitionAdd & PartitionChange parameters are telephony platform-specific - therefore, you must be entirely sure that your request includes all parameters required to create and/or modify a Partition for the telephony platform type set against the corresponding Partition’s owning Telephony Server component.

Please note that you cannot add further Partition entries when the maximum number of allowed Partitions has already been reached for the owning Telephony Server, as defined by its PartitionCountMax setting within the TelSysAdd/TelSysChange requests. When this occurs, you should create a brand-new Telephony Server entry in order to add newly created Partitions under.

Parameters used within PartitionAdd and PartitionChange requests can be found in the table below. You can use this table to check whether a parameter is supported by a certain telephony platform.

To learn more about Partition parameters, please refer to the “Partition Properties” sub-section.

# Read-Only Properties After Initial Creation

# Fully Updatable Properties

# PartitionAdd

Partition components are added via the PartitionAdd request. The main purpose of this request is to effectively create a new reporting scope container.

Additionally on hosted telephony platforms, configurational parameters must also be specified that explicitly depict the Customer environment on the underlying telephony platform itself that real-time reporting call & ACD state data will be collected for.

For example on BroadSoft M6 environments, the NameOnTelSys Property should be exactly specified (with matching character case and whitespace usage) as the name of the corresponding partition/tenant within the underlying telephone platform configuration. Alternatively the IDOnTelSys parameter can be set instead to the M6 partition’s OID value, which is 6 multiples of 16 bit (word) values encoded as hex text separated by a full-stop character (e.g. “0000.feda.eda9.da98.a987.9876”). The InternalDigitLen Property should also be set to a number that represents the internal digit length used when dialling devices internally – this is usually a value of 3 or 4.

For Cisco BroadWorks® platforms, the IDOnTelSysOwner value should be set as the BroadWorks EnterpriseID for the corresponding Customer. Additionally when the TelSysComponentType parameter depicts the Enterprise Group mapping (the “BroadWorks Enterprise Group” value), then the IDOnTelSys parameter should also contain the BroadWorks Enterprise GroupID value for the corresponding site. The InternalDigitLen Property should also be set to a number that represents the internal digit length used when dialling devices internally – this is usually a value of 3 or 4.

# PartitionAdd Request

As mentioned above, PartitionAdd requests are platform-specific. Therefore, you will need to provide request parameters that are relevant to your telephony platform.

Below shows an example of a platform-specific Partition creation operation. This request includes all parameters supported by PartitionAdd operation invoked in order to create a new Partition for a Cisco BroadWorks® telephony platform.

Depending on your initial requirements, your actual request might be shorter than the sample request below.

<Request Operation="PartitionAdd">
    <InvokeID>00009</InvokeID>
    <SessionID>EFA4902A7F61D03E42BF3222B0A246BF</SessionID>
    <OperationPayload>
        <Property Name="TelSysID">100100</Property>
        <!-- PartIDInTelSys value can be specified manually, but in most cases a -->
        <!-- default server-side value is used instead. -->
        <Property Name="PartIDInTelSys">2</Property>
        <Property Name="Description">London Branch</Property>
        <Property Name="TimeZone">Europe/London</Property>
        <Property Name="StartOfDay">00:00:00</Property>
        <Property Name="TelSysComponentType">BroadWorks Enterprise Group</Property>
        <Property Name="IDOnTelSysOwner">ACMETireCoA0005</Property>
        <Property Name="IDOnTelSys">ACMETireCo-London-001</Property>
        <Property Name="LicensedForRptUserType">Akixi 2000</Property>
        <!-- Property to control whether the Partition is in-service or out-of-service. -->
        <Property Name="CommsEnabled">True</Property>
        <!-- Custom tag value that is depicted against the new Partition component -->
        <!-- by the Akixi Service billing output. -->
        <Property Name="BillingTag">A0005-001</Property>
        <!-- Configuration synchronisation related Properties. -->
        <Property Name="SyncNow">True</Property>
        <Property Name="SyncType">1</Property>
        <Property Name="MaintainParity">True</Property>
        <!-- Other configuration Properties. -->
        <Property Name="InternalDigitLen">4</Property>
        <Property Name="CountryCode">44</Property>
        <Property Name="CTILogEnabled">False</Property>
        <Property Name="IsGlobal">False</Property>
    </OperationPayload>
</Request>

# Delayed Or Forced Configuration Synchronisation

When using the PartitionAdd operation on hosted telephony platforms, there are effectively two SyncNow Property value alternatives that can be used in order to choose how the Akixi Service performs configuration synchronisation with the telephony platform afterwards for the corresponding Partition, which downloads the corresponding telephony environment’s device configuration from the telephony platform:

# Delayed Configuration Synchronisation

Create a new Partition, where a “light” configuration synchronisation is automatically delayed by default for about 15-30s (occurs when the SyncNow Property is set to False or isn’t provided at all). Synchronisation can also be subsequently performed for the Partition at any time by setting the SyncNow parameter to True via a separate PartitionChange request.

No billing affecting changes are made to the Akixi Service when performing the delayed & automatic configuration synchronisation logic.

# Forced Synchronisation (Recommended)

Create a new Partition and perform immediate configuration synchronisation for it, which is done by setting the SyncNow Property to True.

Note that unless the SyncType Property is specifically set to ‘2’ (“One Time Full”) or ‘3’ (“Full”) for the request, no incremental billing affecting changes (auto-addition of extension Devices and/or ACD Agent configuration entries) is/are made to the Akixi Service when performing the configuration synchronisation logic.

It is recommended instead to programmatically add the Akixi Service billing affecting extension device and ACD agent configuration using other WS API operations, and not to rely on these elements being created by the “full” synchronisation logic which would add all items regardless, where the associated Customer may not want to pay for reporting data collection across all the items anyway.

# PartitionAdd Response

If your operation was successful, you will receive a response similar to the following:

<Response Result="Success">
    <InvokeID>00009</InvokeID>
</Response>

You will now be able to access the newly created Partition by invoking other Partition-related requests. The Partition can also be viewed & modified in the “Administration -> Partitions” tab of the Akixi Web Application.

If the request was unsuccessful (i.e. the response’s Result attribute depicts the “Fail” value), then the response’s error code and the message description values should be parsed by the client application and then handled accordingly. Some common errors returned by this operation are provided in the table below:

Errors marked with (*) are only returned for Partitions mounted for Cisco BroadWorks® telephony environments.

Please refer to the “Error Codes” chapter for further details on specific error codes and their meaning.

# PartitionChange

Partitions are changed via PartitionChange request.

# PartitionChange Request Parameters

Some PartitionChange parameters are platform-specific - therefore, you must be entirely sure that parameters used within your request are supported by the corresponding telephony platform type set against the corresponding Partition’s owning Telephony Server component. Supported parameters used within the PartitionChange request can be found within the table previously given within the “Partition Request Parameters” sub-section. You can use this table to check whether a parameter is supported by a certain telephony platform. To learn more about PartitionXXX parameters, please refer to the “Partition Properties” sub-section.

# PartitionChange Request

As mentioned above, PartitionChange requests are platform-specific. Therefore, you will need to provide request parameters that are relevant to your telephony platform.

Additionally though in order to change an existing Partition component, one needs to specify its corresponding identifier value(s), which can be done in two different ways:

• By providing the TelSysID and PartIDInTelSys parameters.
• By providing a PartitionGUID parameter.

Normally, the Partition’s PartitionGUID Property value is automatically generated by the server- side logic during PartitionAdd operations. Therefore, one might not even know what the actual value of this is unless the Property had been specifically retrieved afterwards using a PartitionList or PartitionInfo request.

Accordingly based on your particular requirements, you can choose from one of the following request variants below, but we strongly recommend Developers use the first request variant (as it is generally considered the most straightforward one):

# Request Variant 1 (Recommended)

<Request Operation="PartitionChange">
    <InvokeID>00011</InvokeID>
    <SessionID>EFA4902A7F61D03E42BF3222B0A246BF</SessionID>
    <OperationPayload>
        <!-- Properties that identify the Partition component to modify. -->
        <Property Name="TelSysID">100100</Property>
        <Property Name="PartIDInTelSys">2</Property>
        <!-- Properties to update... -->
    </OperationPayload>
</Request>

# Request Variant 2 (By Partition GUID)

<Request Operation="PartitionChange">
    <InvokeID>00011</InvokeID>
    <SessionID>EFA4902A7F61D03E42BF3222B0A246BF</SessionID>
    <OperationPayload>
        <!-- Property that identifies the Partition component to modify. -->
        <Property Name="PartitionGUID">d7be7ef8bf56edca:-1a290a1c:134a9de036c:-7ef1</Property>
        <!-- Properties to update... -->
    </OperationPayload>
</Request>

The following request example shows a full platform-specific Partition update operation using the first request variant method. This request includes all parameters supported by the PartitionChange operation when invoking a change on an existing Cisco BroadWorks® Partition.

<Request Operation="PartitionChange">
    <InvokeID>00010</InvokeID>
    <SessionID>EFA4902A7F61D03E42BF3222B0A246BF</SessionID>
    <OperationPayload>
        <!-- Properties that identify the Partition component to modify -->
        <Property Name="TelSysID">100100</Property>
        <Property Name="PartIDInTelSys">2</Property>
        <!-- Properties to update. -->
        <Property Name="Description">London Branch</Property>
        <Property Name="TimeZone">Europe/London</Property>
        <Property Name="StartOfDay">00:00:00</Property>
        <Property Name="TelSysComponentType">BroadWorks Enterprise Group</Property>
        <Property Name="IDOnTelSysOwner">ACMETireCoA0005</Property>
        <Property Name="IDOnTelSys">ACMETireCo-London-001</Property>
        <Property Name="LicensedForRptUserType">Akixi 2000</Property>
        <!-- Property to control whether the Partition is in-service or out-of-service. -->
        <Property Name="CommsEnabled">True</Property>
        <!-- Custom tag value that is depicted against the corresponding Partition -->
        <!-- component by the Akixi Service billing output. -->
        <Property Name="BillingTag">A0005-001</Property>
        <!-- Configuration synchronisation related Properties. -->
        <Property Name="SyncNow">True</Property>
        <Property Name="SyncType">1</Property>
        <Property Name="MaintainParity">True</Property>
        <!-- Other configuration Properties. -->
        <Property Name="InternalDigitLen">4</Property>
        <Property Name="CountryCode">44</Property>
        <Property Name="CTILogEnabled">False</Property>
        <Property Name="IsGlobal">False</Property>
    </OperationPayload>
</Request>

Depending on your particular requirements, your actual request might be shorter than the request example given above.

# PartitionChange Response

If your operation was successful, you will receive a response similar to the following:

<Response Result="Success">
    <InvokeID>00010</InvokeID>
</Response>

If the request was unsuccessful (i.e. the response’s Result attribute depicts the “Fail” value), then the response’s error code and the message description values should be parsed by the client application and then handled accordingly. Some common errors returned by this operation are provided in the table below:

Errors marked with (*) are only returned for Partitions mounted for Cisco BroadWorks® telephony environments.

Please refer to the “Error Codes” chapter for further details on specific error codes and their meaning.

# PartitionDelete

Akixi Service Partition components can be removed via PartitionDelete requests. Please note that you cannot delete Partition entries unless they are configured to be "out-of-service" by ensuring that their CommsEnabled parameter is specifically set to False (e.g. by submitting appropriate PartitionChange request(s) first).

Unless specifically directed to by your System or Application Provider, you should be particularly careful not to delete the default common devices Partition containing the special Devices such as the [Trunk], [Conference], etc. entries, which are required to model certain call scenarios on most telephony platforms and should never ever be removed.

# PartitionDelete Request

PartitionDelete requests are quite minimalistic. In order to delete a Partition, you must simply specify its identifier value(s), similar to PartitionChange requests. This can be done in two ways:

• By providing the TelSysID and PartIDInTelSys parameters.
• By providing a PartitionGUID parameter.

Normally, the Partition’s PartitionGUID Property value is automatically generated by the server-side logic during PartitionAdd operations. Therefore, one might not even know what the actual value of this is unless the Property had been specifically retrieved afterwards using a PartitionList or PartitionInfo request.

According to your particular requirements, you can choose from one of the request variants below, but we strongly recommend to use the first variant (as it is generally considered the most straightforward one):

# Request Variant 1 (Recommended)

<Request Operation="PartitionDelete">
    <InvokeID>00011</InvokeID>
    <SessionID>EFA4902A7F61D03E42BF3222B0A246BF</SessionID>
    <OperationPayload>
        <!-- Properties that identify the Partition component to modify. -->
        <Property Name="TelSysID">100100</Property>
        <Property Name="PartIDInTelSys">2</Property>
        <!-- Additional special Properties that control how deletion is performed. -->
        <Property Name="AutoDeleteUsers">True</Property>
    </OperationPayload>
</Request>

# Request Variant 2 (By Partition GUID)

<Request Operation="PartitionDelete">
    <InvokeID>00011</InvokeID>
    <SessionID>EFA4902A7F61D03E42BF3222B0A246BF</SessionID>
    <OperationPayload>
        <!-- Properties that identify the Partition component to modify. -->
        <Property Name="PartitionGUID">d7be7ef8bf56edca:-1a290a1c:134a9de036c:-7ef1
        </Property> <!-- Additional special Properties that control how deletion is performed. -->
        <Property Name="AutoDeleteUsers">True</Property>
    </OperationPayload>
</Request>

# PartitionDelete Response

If your operation was successful, you will receive a response similar to the following:

<Response Result="Success">
    <InvokeID>00011</InvokeID>
</Response>

If the request was unsuccessful (i.e. the response’s Result attribute depicts the “Fail” value), then the response’s error code and the message description values should be parsed by the client application and then handled accordingly. Some common errors returned by this operation are provided in the table below:

Errors marked with (*) are returned when the response’s Result attribute depicts the “PartialFail” value.

Please refer to the “Error Codes” chapter for further details on specific error codes and their meaning.

# PartitionList

The PartitionList operation can be used to list all Partitions that are configured against a certain Telephony Server component within the Akixi Service.

# PartitionList Request

By default, the body of PartitionList requests is quite minimalistic: you can simply specify the Telephony Server Identifier in order to obtain the list of all underlying Partitions (as well as some commonly used Partition-related parameter values).

If you want to list parameters that are not returned when you invoke a default “minimalistic” request, you can request additional values via PartitionFields Property:

<Request Operation="PartitionList">
    <InvokeID>00012</InvokeID>
    <SessionID>EFA4902A7F61D03E42BF3222B0A246BF</SessionID>
    <OperationPayload>
        <!-- Specify a Telephony Server component Identifier to list its Partitions. -->
        <Property Name="TelSysID">100100</Property>
        <!-- Can be used to list additional parameters of each Partition. -->
        <Property Name="PartitionFields">LicensedForRptUserType,CommsStatus</Property>
    </OperationPayload>
</Request>

The PartitionList operation can only return the following Partition-related parameters:

• PartIDInTelSys *
• Description *
• TelSysID
• PartitionGUID
• LicensedForRptUserType
• CommsStatus

Parameters marked with an asterisk (*) are returned by default (i.e. it is not required to specify them via the PartitionFields Property).

# PartitionList Response

If a PartitionList operation is successful, then you’ll receive a list of Partitions and their Properties. If additional parameters were not provided within your request, you will receive default Properties of all Partitions (i.e. PartIDInTelSys and Description values). If additional fields were requested via PartitionFields Property, then corresponding values will also be returned within the operation’s response:

<Response Result="Success">
    <InvokeID>00012</InvokeID>
    <Success>
        <Container>
            <!-- Only PartIDInTelSys and Description parameters are returned by default.-->
            <Property Name="PartIDInTelSys">2</Property>
            <Property Name="Description">[Common Devices Partition]</Property>
            <!-- Parameters below were requested via PartitionFields Property-->
            <Property Name="PartitionGUID">97456e9207d85af8:32dcce85:15592616831:-ff2e</Property>
            <Property Name="TelSysID">100100</Property>
            <Property Name="LicensedForRptUserType">Akixi 2000</Property>
            <Property Name="CommsStatus">Running</Property>
        </Container>
        <Container>
            <!-- Only PartIDInTelSys and Description parameters are returned by default.-->
            <Property Name="PartIDInTelSys">0</Property>
            <Property Name="Description">London Branch</Property>
            <!-- Parameters below were requested via PartitionFields Property-->
            <Property Name="PartitionGUID">f850b6719f95d98f:79b51bff:149bc2efbcb:-7e08</Property>
            <Property Name="TelSysID">100100</Property>
            <Property Name="LicensedForRptUserType">Akixi 2000</Property>
            <Property Name="CommsStatus">Running</Property>
        </Container>
    </Success>
</Response>

If the request was unsuccessful (i.e. the response’s Result attribute depicts the “Fail” value), then the response’s error code and the message description values should be parsed by the client application and then handled accordingly. Some common errors returned by this operation are provided in the table below:

Please refer to the “Error Codes” chapter for further details on specific error codes and their meaning.

# PartitionInfo

The PartitionInfo request can be used in order to obtain information related to a certain specific Partition component.

# PartitionInfo Request

The PartitionInfo request is quite minimalistic like PartitionChange & PartitionDelete requests - you only need to specify the corresponding Partition’s identifier value(s) in order to obtain its parameters. Similarly like for PartitionChange & PartitionDelete & requests, this can be done in two ways:

• By providing the TelSysID and PartIDInTelSys parameters.
• By providing a PartitionGUID value.

As previously mentioned, the Partition’s PartitionGUID Property value is automatically generated by the server-side logic during PartitionAdd operations. Therefore, one might not even know what the actual value of this is unless the Property had been specifically retrieved afterwards using a PartitionList or PartitionInfo request.

Accordingly based on your particular requirements, you can choose from one of the request variants below, but we strongly recommend to use the first variant (as it is generally considered the most straightforward one):

# Request Variant 1 (Recommended)

<Request Operation="PartitionInfo">
    <InvokeID>00013</InvokeID>
    <SessionID>EFA4902A7F61D03E42BF3222B0A246BF</SessionID>
    <OperationPayload>
        <Property Name="TelSysID">2</Property>
        <Property Name="PartIDInTelSys">2</Property>
    </OperationPayload>
</Request>

# Request Variant 2 (By Partition GUID)

<Request Operation="PartitionInfo">
    <InvokeID>00013</InvokeID>
    <SessionID>EFA4902A7F61D03E42BF3222B0A246BF</SessionID>
    <OperationPayload>
        <Property Name="PartitionGUID">f850b6719f95d98f:79b51bff:149bc2efbcb:-7e08</Property>
    </OperationPayload>
</Request>

# PartitionInfo Response

If PartitionInfo operation was successful, you will receive a list of the corresponding Partition’s Property values that are specifically supported for the telephony platform type assigned to that Partition’s owning Telephony Server component:

<Request Operation="PartitionInfo">
    <InvokeID>00013</InvokeID>
    <SessionID>EFA4902A7F61D03E42BF3222B0A246BF</SessionID>
    <OperationPayload>
        <Property Name="PartitionGUID">f850b6719f95d98f:79b51bff:149bc2efbcb:-7e08</Property>
        <Property Name="TelSysID">100100</Property>
        <Property Name="PartIDInTelSys">2</Property>
        <Property Name="Description">London Branch</Property>
        <Property Name="TimeZone">Europe/London</Property>
        <Property Name="StartOfDay">00:00:00</Property>
        <Property Name="TelSysComponentType">BroadWorks Enterprise</Property>
        <Property Name="IDOnTelSysOwner">ACMETireCoA0005</Property>
        <Property Name="IDOnTelSys">ACMETireCo-London-001</Property>
        <Property Name="LicensedForRptUserType">Akixi 2000</Property>
        <Property Name="CommsEnabled">True</Property>
        <Property Name="BillingTag">A0005-001</Property>
        <Property Name="SyncNow">True</Property>
        <Property Name="SyncType">1</Property>
        <Property Name="MaintainParity">False</Property>
        <Property Name="IsGlobal">False</Property>
        <Property Name="InternalDigitLen">4</Property>
        <Property Name="CountryCode">44</Property>
        <Property Name="TrunkCapacity">50</Property>
        <Property Name="TrunkCapacityBurst">0</Property>
        <Property Name="CTILogEnabled">False</Property>
    </OperationPayload>
</Request>

If the request was unsuccessful (i.e. the response’s Result attribute depicts the “Fail” value), then the response’s error code and the message description values should be parsed by the client application and then handled accordingly. Some common errors returned by this operation are provided in the table below:

Please refer to the “Error Codes” chapter for further details on specific error codes and their meaning.