Implementing a new device adapter type
You can implement a new custom adapter by using the following methods:
- Exporting an existing adapter, modifying it, and then importing the modified adapter into BMC Network Automation
- Using a device type map entry template, customizing it, and then importing the modified adapter into BMC Network Automation
To implement a new adapter type by using a device type map entry template
- Create a new device type file on your client workstation.
For example, DTM-Name.xml, where DTM indicates that it is a device type file and Name indicates the device type. Copy one of the following device type map entry template into the file depending on the device type (HTTP- or terminal-oriented). These templates are the starting points for defining a new device type.
Click here to view the Device Type map entry template for a terminal-oriented device type containing a few possible fields.
<!-- ============================================================= -->
<!-- Template for a new terminal-oriented device type. -->
<!-- Any attribute set to its default can be left out. -->
<!-- NOTE: Customer-defined device types should use a generated GUID -->
<!-- =========================================================== -->
<!-- ============================================================= -->
<deviceTypeMap xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<deviceType>
<!-- Use the create_guid script to generate a new guid value -->
<!-- Example - <guid>2F621789-B4CF-426D-9188-BA4BFFF8AC9B</guid> -->
<guid>XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX</guid>
<name>A unique device type name</name>
<!-- A valid vendor GUID value from the DeviceTypeMap.xml file -->
<!-- Example - <vendor>072DB2D7-48AA-4616-B9FA-7547726EE91D</vendor> -->
<guid>XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX</guid>
<!-- The supported models. This is just hard-coded documentation for reporting
purposes. BMC does not validate that a logged in device is one of these
models, nor this is stated from actual discovered models. -->
<supportedModelInfo>modelNo</supportedModelInfo>
<!-- The supported OS versions. This is just hard-coded documentation for
reporting purposes. BMC does not validate that a logged in device is
one of these OS versions, nor this is stated from actual discovered
OS versions. -->
<supportedOsVersionInfo>OSVersioNo</supportedOsVersionInfo>
<!-- Used when deciding OS image names when the name reported by a device
is not quite useful (such as "12.3"). For example, "IOS " prefix will
create an OS image named "IOS 12.3". -->
<imageNamePrefix>imagePrefix</imageNamePrefix>
<!-- If set to true, indicates that this device type extends an existing
one with the same GUID. An extended device type is used, for instance,
to encapsulate custom device commands that you want to add to a
particular device type. An extended device type is defined in a
separate DeviceTypeMap-*.xml file and gets merged into the existing
device type when loaded. It will be an incomplete device type
specification until it is merged. -->
<extension>false</extension>
<!-- The proxy server used. Default is none. -->
<proxy>none</proxy>
<!-- Flags that when comparing a configuration against a template, the
"diff" method, not any custom method, be used. Some devices support
a merge; but the file must contain a complete configuration (not just
relevant change snippets). Or, if not a complete configuration, then
the file must contain a large portions of it. For these devices,
template vs configuration comparisons look a lot better when
passed through "diff", since the two will have very much in common. -->
<alwaysUseDiff>false</alwaysUseDiff>
<!-- Flags that blanks and tabs should be ignored in the configuration files
when calculating differences. Some devices (e.g. HP 24xx) have
syntax where blanks don't matter and they don't appear predictably.
BMC Network Automation does not want to flag a discrepancy just
because of these blanks. -->
<ignoreBlanks>false</ignoreBlanks>
<!-- When set to true, sorts the contents of the entire configuration, except
for any lines that match a negated list defined in SmartMerge settings.
This flag is useful when a device orders its lines randomly, or when you
remove and then add a line again and the device always adds it to the end
(such as Juniper JunOS in set command mode). -->
<sortEntireConfig>false</sortEntireConfig>
<!-- Holds the GUID of the device command used to merge scripts that are not
a configuration marked with a trail (such as templates and target
configurations). Can be set to null when merge is not supported at all. -->
<defaultMergeCommandGuid>5421B3AE-2C94-0519-5D07-B4971BB15C7D</defaultMergeCommandGuid>
<!-- Holds the GUID of the device command used to restore scripts that are
not a configuration marked with a trail (such as templates and target
configuration). Can be set to null when restore is not supported at all. -->
<defaultRestoreCommandGuid>61A43CB3-2D57-66F7-32E3-59A1A1CD291E</defaultRestoreCommandGuid>
<!-- Flags whether this device type supports telnet connection access. Default
is true. -->
<supportsTelnetAccess>true</supportsTelnetAccess>
<!-- Flags whether this device type supports ssh2 connection access. Default is
false. -->
<supportsSsh2Access>false</supportsSsh2Access>
<!-- Flags whether this device type supports interactive SSH authentication.
Default is false. This tag is needed for some SSH servers
(e.g. Cisco4400, CSS) that prompt for a user name or password in spite of
that information already being passed in the protocol. When true, the xml
file must handle user name and password as part of the login device
command. -->
<supportsInteractiveSshAuth>false</supportsInteractiveSshAuth>
<!-- Flags whether this device type supports https 1.1 connection access. Default
is false. -->
<supportsHttps11Access>false</supportsHttps11Access>
<!-- Flags whether this device type supports https 1.0 connection access. Default
is false. -->
<supportsHttps10Access>false</supportsHttps10Access>
<!-- Flags whether this device type supports http 1.1 connection access. Default
is false. -->
<supportsHttp11Access>false</supportsHttp11Access>
<!-- Flags whether this device type supports http 1.0 connection access. Default
is false. -->
<supportsHttp10Access>false</supportsHttp10Access>
<!-- Flags whether this device type supports access via web services. Default is
false. -->
<supportsWebServiceAccess>true</supportsWebServiceAccess>
<!-- A terminal type, needed for some SSH servers (e.g. Nokia). Set this tag to
something like "dumb" or "vt100". SSHConnection will use it to request
a pseudo terminal. When set to null (default), SSHConnection won't prompt
for a pseudo terminal type. If your connection seems to be sending and
executing commands, but not getting back any responses, you probably need
to set this tag. -->
<sshPseudoTty>dumb</sshPseudoTty>
<!-- A terminal type, needed for some Telnet servers (e.g. Windows). Set this
to something like "dumb" or "vt100". TelnetConnection will use it to set
the telnet terminal type option if it is specified. If your connection
seems to be sending and executing commands, but not getting back any
responses, you probably need to set this tag.-->
<telnetPseudoTty>dumb</telnetPseudoTty>
<!-- Allows you to specify a non-default terminal width for SSH connections.
For a few devices (specifically F5 BigIP TMSH), a long prompt might wrap
at 80, which could be in the middle of the prompt, causing you to miss
reception of the prompt. These devices do not have any method to set the
terminal width after login. This tag enables you to set the SSH terminal
width in the adapter. -->
<sshTerminalWidth>90</sshTerminalWidth>
<!-- Allows you to specify a non-default terminal width for Telnet connections.
For a few devices (specifically MRV OptiSwitch), a long prompt might wrap
at 80, which could be in the middle of the prompt, causing you to miss
reception of the prompt. These devices do not have any method to set the
terminal width after login. This tag enables you to set the Telnet terminal
width in the adapter. -->
<telnetTerminalWidth>80</telnetTerminalWidth>
<!-- Flags whether to enable the FIPS mode while using SSH connection. Default
is false. When set to true, it enables FIPS-compatible algorithms and
disables any other non-compatible algorithms. So, while using SSH
connection in FIPS mode, it uses key exchange algorithm and ciphers which
are supported by FIPS only. For example, KEX_DIFFIE_HELLMAN_GROUP14_SHA1,
CIPHER_AES128_CBC, CIPHER_AES192_CBC, CIPHER_AES256_CBC,
CIPHER_TRIPLEDES_CBC, HMAC_SHA1,HMAC_SHA256, etc. When FIPS mode is enabled
on a device, you can set this flag to true to connect the device from BMC
Network Automation. -->
<enableFIPSModeForSsh>false</enableFIPSModeForSsh>
<!-- Flags whether this device type supports tunneled file transfer inside the
connection protocol. Default is false. -->
<supportsTunneledTransfer>false</supportsTunneledTransfer>
<!-- When using file transfer, specifies the filename extension for the
temporary files sent to or received from a device. Typically, the temp
files are called ena-#.tmp or agent-#.tmp. However, a few devices
generate or allow files named with specific extensions (such as .zip).
The specified extension will replace the normal .tmp extension. You must
include the dot (.) to make it a true extension. -->
<transferredFilenameExtension>.tmp</transferredFilenameExtension>
<!-- When true, BMC Network Automation removes the extension from the
transfer filename in the commands. This tag is used in conjunction with
the transferredFilenameExtension tag, when device's file transfer commands
assume a particular extension and do not work if you try to give it your
own extension (for example, MRV LX device). When set to false (default),
commands include the filename with its extension. -->
<stripFilenameExtensionFromCmds>false</stripFilenameExtensionFromCmds>
<!-- Flags whether this device type supports tftp file transfer. Default is
true. -->
<supportsTftpTransfer>true</supportsTftpTransfer>
<!-- Flags whether this device type supports ftp file transfer. Default is
false. -->
<supportsFtpTransfer>false</supportsFtpTransfer>
<!-- Flags whether this device type supports scp file transfer. Default is
false. -->
<supportsScpTransfer>false</supportsScpTransfer>
<!-- Indicates the sleep time between the time BMC Network Automation
reboots a device and the time it makes the first connection attempt,
to allow the device to shut down completely. By default, sleep time is
ImportedGlobals.DEVICE_REBOOT_SLEEP_SECONDS (which defaults to
15 seconds). If this is not enough time for the device to fully shut
down, BMC Network Automation might log into it again prematurely. If you
set this attribute to a greater value than the default value, the
sleep time is rebootSleepSeconds instead (that is, sleep time is the
greater of the two values). -->
<rebootSleepSeconds>15</rebootSleepSeconds>
<!-- If true, then the device automatically reboots as a side effect of the
performing a restore operation. This flag could control whether the reboot
option is presented or not in the GUI when you have chosen to perform a
restore. However, it is currently used only by FileConnection during
simulated restores; has absolutely no effect otherwise. -->
<rebootsAfterRestore>false</rebootsAfterRestore>
<!-- Indicates the sleep time between a device becoming partially and fully
connectible. Some of the devices (e.g. CatOS) are initially only partially
connectible after a reboot, in that they present single-user connectivity.
A few seconds later, they present the expected multi-user connectivity. -->
<securitySleepSeconds>0</securitySleepSeconds>
<!-- Flags whether the device will prompt you before rebooting when there are
unsaved changes in the memory. If true, the saveChoice property will need
to be set so that BMC Network Automation knows how to respond. Defaults
to false. -->
<promptsUnsavedChanges>false</promptsUnsavedChanges>
<!-- When set to a string, sends that string to the device whenever BMC Network
Automation fails to receive a response in the allotted time. This presents
a workaround for a crazy issue with devices ,such as Foundry NetIron,
where, completely at random, it decides to ignore a command sent by
BMC Network Automation and if BMC Network Automation sends it a newline
after waiting for a minute, it then accepts the command and proceeds
normally. -->
<kickAtResponseTimeout>none</kickAtResponseTimeout>
<!-- Flags whether this device type supports multiple security contexts
(such as the Cisco ASA, FWSM, and ACE devices). -->
<supportsMultipleSecurityContexts>false</supportsMultipleSecurityContexts>
<!-- Flags whether this type supports separate configuration files per security
context (such as Cisco ASA, FWSM, & ACE devices). -->
<supportsConfigPerSecurityContext>true</supportsConfigPerSecurityContext>
<!-- Flags whether this device type can be a virtual machine (e.g. Cisco VSG for
NexusOS). It does not indicate it has to be a virtual machine, however. -->
<virtualMachine>true</virtualMachine>
<!-- If true, irrespective of the transfer mode of the device, the transfer mode
will be forced to be tunneled transfer during merge action. The flag is
purely used in context of container configuration merge actions. -->
<requiresTunnelingForContainerMerge>false</requiresTunnelingForContainerMerge>
<!-- If true, device transfer mode will be forced to be tunneled transfer for
devices having user-defined security context. -->
<requiresTunnelingForUserContexts>false</requiresTunnelingForUserContexts>
<!-- When set to true, a configuration can be merged to the device in
tunneled mode; that is, a line-by-line merge of a complete configuration or
lines computed from one will work, since the configuration contains commands
the device will understand in the tunneled loop. When set to false
(as for F5 and JunOS), a configuration cannot be tunneled out; that is, the
lines in the configuration are not executable commands understood in the
tunneled loop; a template containing executable commands can however be
tunneled out.-->
<supportsTunnelMergeForConfigurationFile>true</supportsTunnelMergeForConfigurationFile>
<!-- Name of the security context which BMC Network Automation will automatically
switch to in order to create (or destroy) a new guest context on a load
balancer or firewall host during container configuration. This value is
"system" for the FWSM device type. You can also set it to null. When
populated, it will get assigned to the TARGET_SECURITY_CONTEXT_NAME
connection property and passed in to the action to merge the template to
the host device to create (or destroy) the new context during container
configuration. This allows the DTM logic to automatically switch to the
target context rather than having to embed the context switch command in
the template, since that leads to awkward contortions in the logic. -->
<creatorSecurityContextName>system</creatorSecurityContextName>
<!-- If device supports the image deletion command, this tag flags
whether it supports the forward (prior to image deploy(load)) or
backward (after image deploy(load)) style deletion. -->
<supportsForwardImageDeletion>false</supportsForwardImageDeletion>
<!-- Flags whether this device type supports management by serial terminal
servers. Note that all device types are assumed to automatically support
the connection proxy terminal servers, since no new interaction logic is
required for it. -->
<supportsSerialTerminalServerManagement>false</supportsSerialTerminalServerManagement>
<!-- Regular expression specifying the filename pattern which indicates an
archive style image file. This is used in Cisco IOS to distinguish between
the tar style and binary style image deploy (load). -->
<imageArchiveFilename>^(.+\.tar|.+/.+).*</imageArchiveFilename>
<!-- List of illegal characters (with no delimiters and enclosed in square
brackets) that need to be stripe out from port-type name configured
in a hypervisor switch. -->
<illegalPortTypeNameCharacters>[ ]</illegalPortTypeNameCharacters>
<!-- When true, indicates that the original filename should be used when
performing file transfer during image deploy (load); that is, do not use
files named ena-*.tmp on the server side, but write to a file that is
named the same as the source file selected for image deploy (load). For
example, Extreme XOS will only transfer files that are named the right way,
with .xos or .xmod extensions, not randomly named files. -->
<preserveFilenameOnImageLoad>true</preserveFilenameOnImageLoad>
<imageLoaderClassName>
com.bmc.bcan.engine.network.devices.XYZImageLoader
<!-- Name of the class that will be used for loading images on this device
type. -->
</imageLoaderClassName>
<!-- Specify the file systems supported for OS image deploy (load) action. -->
<supportedFileSystems>
<fileSystem>primary</fileSystem>
<fileSystem>secondary</fileSystem>
</supportedFileSystems>
<osImageInformation>
<osImageType order="1" name="system" primary="true"/>
<osImageType order="2" name="kickstart"/>
</osImageInformation>
<!-- When this device type supports discovery of the detailed information
about the hardware components that make a device, this tag contains this
information. -->
<hardwareInventoryClassName>
com.bmc.bcan.engine.network.devices.XYZHardwareInventory
</hardwareInventoryClassName>
<!-- Whether or not this device emits a syslog message suitable for use as
an auto-archive trigger. This can be a syslog emitted message when
configuration mode or edit mode is exited, or when a user logs out. The
syslog has to include text that indicates this event, and the text must
include the IP/host of the user who did it (so user can identify syslogs
that BMC Network Automation generated and ignore them, to avoid
self-triggered auto-archive loops). -->
<supportsSyslogAutoArchiveTriggerInfo>true</supportsSyslogAutoArchiveTriggerInfo>
<!-- Indicates which functions (to be used in ${eval} substitution parameter
resolution) generate properly-encrypted passwords. This is used only for
reporting and documentation purposes. -->
<passwordEncryptionFunctionInfo>encrypt_md5_hex</passwordEncryptionFunctionInfo>
<!-- SNMP Object IDs (OIDs) and corresponding device categories that are
reported by this device type.
Map
key: String START of an OID that will match
value: Integer device category -->
<snmpOids>
<snmpOid>oid string</snmpOid>
</snmpOids>
<!-- For a particular device type, defines the configuration trail and its
type. -->
<supportedConfigurationTrailDeclarations>
<!-- Running -->
<supportedTrail>
<!-- Supported configuration trail -->
<guid>02C89A1F-A5D2-44B0-AE1E-B714EB0E3FAF</guid>
<!-- Data format in a configuration in this trail. It can be ascii (default)
or binary. -->
<format>ascii</format>
<!-- The guid of the DeviceCommand that backs up this trail. -->
<backupCommandGuid>388DFC1D-2DF0-D833-5762-F5121A797069
</backupCommandGuid>
<!-- The guid of the DeviceCommand that merges this configuration. Imports
deviceCommands from an alienType into the deviceCommands container. If
the command in question already exists in a container, it will be
overwritten in this process. Note that this mechanism is used, for
instance, when merging content from DeviceTypeMap-*.xml extension files,
for custom device commands or overridden device commands.
@param alienType alien DeviceType to import DeviceCommands from -->
<mergeCommandGuid>5421B3AE-2C94-0519-5D07-B4971BB15C7D
</mergeCommandGuid>
</supportedTrail>
<!-- Startup -->
<supportedTrail>
<guid>1D168B48-15CC-416E-AB4A-88E2E7104E2D</guid>
<format>ascii</format>
<backupCommandGuid>4E005EF8-BAC1-BD15-EF63-DDC6D2547FFE
</backupCommandGuid>
<restoreCommandGuid>61A43CB3-2D57-66F7-32E3-59A1A1CD291E
</restoreCommandGuid>
</supportedTrail>
</supportedConfigurationTrailDeclarations>
<!-- Any line in the configuration file that should be treated as comments
and should not be used for comparing the configuration with other
configurations. -->
<commentLines>
<!-- Constructor.
@param line compiled and used to set pattern attribute
@param scope sets scope attribute
@param context sets context attribute
@param caseSensitive whether comparisons are case sensitive -->
<line context="global" scope="02C89A1F-A5D2-44B0-AE1E-B714EB0E3FAF,
1D168B48-15CC-416E-AB4A-88E2E7104E2D" caseSensitive="false">
regular expression</line>
</commentLines>
<!-- A block of lines with a beginning and an end line that should be treated as
comments and should not be used for comparing the configuration with
other configurations. -->
<commentBlocks>
<block context="global" scope="02C89A1F-A5D2-44B0-AE1E-B714EB0E3FAF,
1D168B48-15CC-416E-AB4A-88E2E7104E2D" caseSensitive="false">
<!-- Flags whether the begin line should be considered part of the
comment block or not. -->
<begin inclusive="false">regular expression</begin>
<!-- Flags whether the end line should be considered part of the comment
block or not. -->
<end inclusive="false">regular expression</end>
<!-- Optional compiled regex pattern defining an intermediate line which
must be present in the block in order for it to qualify as a comment
block. -->
<include>regular expression</include>
<!-- Optional compiled regex pattern defining an intermediate line which
must NOT be present in the block in order for it to qualify as a
comment block. Note that if both the includePattern and excludePattern
are matched, the block will not qualify as a comment block. -->
<exclude>regular expression</exclude>
<!-- Flags whether the maskPattern should be used to qualify (default)
or disqualify intermediate lines as comments. -->
<mask invert="false">regular expression</mask>
</block>
</commentBlocks>
<!-- Strings that should be disregarded when they appear at the START of a line.
Used only when comparing a configuration against a template to get better
matches; lines that start with a string in this list (case-insensitive)
get the string removed to improve the chances of a proper match. For
example, you could include "no " here to account for the IOS/PIXOS
configuration commands having a positive and negative version distinguished
by a leading "no" (e.g. "no snmp-server location").
<disregardLeadingWord>
<word>leading word to strip off (e.g. "no")</word>
</disregardLeadingWord>
<!-- Commands or blocks that should be sorted together, keyed by trail ID -->
<sortedCommands>
<line type="single" caseSensitive="false" trails="0,1">
regular expression</line>
</sortedCommands>
<!-- List of SortedParameter, for commands whose parameters need to be sorted
prior to making change comparisons, since those parameters can be randomly
re-ordered by the device. -->
<sortedParameters>
<sortedParameter>
<!-- Java regular expression for matching command line of interest. -->
<command>regular expression</command>
<!-- Format for locating the parameters you want to sort. -->
<format>parsing format</format>
<!-- The number of parameters that should be grouped and sorted together. -->
<numberParamsInGroup>1</numberParamsInGroup>
</sortedParameter>
</sortedParameters>
<!-- List of zero or more TextProcessor instances (keyed by trail) identifying
search patterns and corresponding replacement strings to make in received
configuration file contents before using them to construct a configuration
instance. -->
<configProcessors>
<!-- Encapsulates logic to perform a regex search and replace operation.
This is currently used for massaging the contents of the configuration
files received from a device (e.g. Cisco css) that contain particular
characters BMC Network Automation must squash out before being able to
save the contents successfully to the database in a configuration object
(e.g. for Cisco css, BMC Network Automtion squashes out CR-null sequences).
Note that it is possible for a given TextProcessor instance to be used in
both the incoming and outgoing directions if desired. -->
<!-- Constructor. Note that BMC Network Automation converts any embedded
"\xddd" sequences to their ascii characters here before performing
the attribute assignments.
@param search sets search attribute
@param replace sets replace attribute
@param incoming whether to apply process to incoming text files
@param outgoing whether to apply process to outgoing text files
@param fileTransfer whether to apply process to file transfers
@param tunneledTransfer whether to apply process to tunneled
transfers -->
<textProcessor search="regex" replace="string" incoming="false"
outgoing="false" fileTransfer="false" tunneledTransfer="false"
trails="0,1"/>
</configProcessors>
<!-- List of zero or more "sensitive" regex patterns. This list is used for
hiding sensitive configuration content. Each pattern can include one or
more capture groups. These groups define the portion(s) within which the
matched text will be hidden from display. If no capture groups are defined,
the entirety of the matched text will be hidden. -->
<sensitiveLines>
<line>regular expression</line>
</sensitiveLines>
<!-- List of ResponseBlockDeclaration instances (if any) defined for this
device type. These instances can be referenced from various Interactions
within the DeviceCommands, allowing them to be reused easily. -->
<responseBlockDeclarations>
<responseBlockDeclaration name="My Response Block">
<response>response string 1</response>
<response>response string 2</response>
</responseBlockDeclaration>
</responseBlockDeclarations>
<!-- List of ErrorBlockDeclaration instances (if any) defined for this
device type. These instances can be referenced from various Interactions
within our DeviceCommands, allowing them to be reused easily. -->
<errorBlockDeclarations>
<!-- Encapsulates a collection of Interaction errors that can be defined once
at the top of a DeviceType, and referenced from multiple Interactions
for easy reuse. Note that this style of reuse cannot be done by using the
XInclude mechanism, since such reuse requires that the XML snippet being
included is itself a well-formed XML document with a single root, which
is not the case here where you have a collection of tags we want to reuse.
This represents the "errorBlockDeclaration" tags used in
DeviceTypeMap.xml. -->
<errorBlockDeclaration name="My Error Block">
<!-- Ordered list of Interaction Error instances contained within this
block. -->
<error>error string 1</error>
<error>error string 2</error>
</errorBlockDeclaration>
</errorBlockDeclarations>
<!-- Map of DeviceCommands, keyed by DeviceCommand.guid. Contains both canned
and custom commands (if any). Note that if a given device type does not
implement a particular command, it can be absent from this map. It's also
possible, for historical reasons, that a particular command may be present
but empty, which also indicates that the device type does not implement
it. -->
<deviceCommand>
<!-- login -->
<!-- A unique ID consisting of 36 characters used to uniquely define a
device command. -->
<guid>0E8DB22F-DEF8-987E-1AFB-7BE8BBCC9BEA</guid>
<!-- Flags whether this command should be retried if it times out initially.
This was necessary, for instance, with the Nortel login sequence, in
which the 'bcc' command occasionally hangs after a reboot, but usually
works on retry. -->
<retry>false</retry>
<!-- Encapsulates one interaction with a device command. -->
<interaction>
<!-- A pattern that BMC Network Automation will look for before executing a
command -->
<prompt>string</prompt>
<!-- Java regular expression for matching command line of interest. -->
<command>string</command>
<pauseSeconds>0</pauseSeconds>
<!-- A pattern that BMC Network Automation will look for after executing a
command -->
<response>string</response>
<responseBlockReference name="My Response Block"/>
<!-- Ordered list of Interaction Error instances contained within this block. -->
<error>string</error>
<errorBlockReference name="My Error Block"/>
<!-- Holds all capture related interaction specifications as a list of Capture
elements. Will be empty if no capture has been specified. -->
<capture>
<property name="string"/>
</capture>
<!-- Tests the syntax scan operation's failure conditions. -->
<syntaxScanInteraction lineErasure="never" useCtrlU="false"
replaceCtrlCWith=" help=">
<prompt>)prompt string</prompt>
<command omitEOL="false">not used</command>
<!-- The time BMC Network Automation will wait to match the response. -->
<pauseSeconds>0</pauseSeconds>
<!-- Ordered list of Interaction.Response instances contained within
this block -->
<response>response string</response>
<!-- If a particular error string is received as a response, set the
response property. -->
<response property="syntax.error.%lineNumber%">)error string</response>
<!-- Flags whether to include or exclude the specified suffix from the
property text to be captured. Default is false (exclude). -->
<capture includeSuffix="false">
<property name="syntax.response.%lineNumber%"/>
</capture>
<blockEntryError>error string</blockEntryError>
</syntaxScanInteraction>
<!-- Encapsulates a sequence of DeviceCommandElements that should be
iterated over after the DeviceCommand has been executed, whether
that execution was successful or unsuccessful. This represents the
"finallyBlock" tags used in DeviceTypeMap.xml. -->
<finallyBlock></finallyBlock>
<interaction></interaction>
<!-- The prompt string to be displayed to the user. -->
<prompt>string</prompt>
<command>string</command>
<!-- Ordered list of Interaction.Response instances contained within
this block. -->
<response>string</response>
</interaction>
</finallyBlock>
</interaction>
</deviceCommand>
<!-- discover core -->
<deviceCommand>
<guid>1E91FAD6-FBB7-5D7C-120F-ABD77583A086</guid>
</deviceCommand>
<!-- discover image details -->
<deviceCommand>
<guid>2993A257-F634-4FFA-560F-B921EE64D6AC</guid>
</deviceCommand>
<!-- copy running to net (R2N) -->
<deviceCommand>
<guid>388DFC1D-2DF0-D833-5762-F5121A797069</guid>
</deviceCommand>
<!-- copy startup to net (S2N) -->
<deviceCommand>
<guid>4E005EF8-BAC1-BD15-EF63-DDC6D2547FFE</guid>
</deviceCommand>
<!-- copy net to running(N2R) -->
<deviceCommand>
<guid>5421B3AE-2C94-0519-5D07-B4971BB15C7D</guid>
</deviceCommand>
<!-- copy net to startup(N2S) -->
<deviceCommand>
<guid>61A43CB3-2D57-66F7-32E3-59A1A1CD291E</guid>
</deviceCommand>
<!-- copy running to startup(R2S) -->
<deviceCommand>
<guid>7023D2D2-1A14-7DB8-14F6-8B8485C5015E</guid>
</deviceCommand>
<!-- copy image to net(I2N) -->
<deviceCommand>
<guid>89F733B6-4C59-CF2B-BD10-CD9EA41BA6DB</guid>
</deviceCommand>
<!-- copy net to image(N2I) -->
<deviceCommand>
<guid>905E3CF3-2DAE-2FBE-D466-B933FB675F5D</guid>
</deviceCommand>
<!-- declare image -->
<deviceCommand>
<guid>A11600D7-30A0-4378-6B50-A7449E2AAE9A</guid>
</deviceCommand>
<!-- delete image -->
<deviceCommand>
<guid>B1B1198E-FF0E-7791-D77C-32901BC11901</guid>
</deviceCommand>
<!-- activate image -->
<deviceCommand>
<guid>C86240C6-54EF-F268-6242-BDC42F74E7C8</guid>
</deviceCommand>
<!-- reboot -->
<deviceCommand>
<guid>0DD240D0-5C2E-C943-CBE9-88E2E58F9454</guid>
</deviceCommand>
<!-- logout -->
<deviceCommand>
<guid>E6C631FC-33CA-812E-55D5-6CF772428705</guid>
</deviceCommand>
<!-- syntax scan -->
<deviceCommand>
<guid>0F008DB4-DCDB-FE9E-BE50-24A86F88FBE2</guid>
</deviceCommand>
<!-- verify image -->
<deviceCommand>
<guid>AA954719-1830-4C31-EEA8-F0D9CC7982D9</guid>
</deviceCommand>
<!-- get next switch -->
<deviceCommand>
<guid>FB13C6B2-D973-A0F1-1E46-0AA438834D3E</guid>
</deviceCommand>
<!-- discover acl details -->
<deviceCommand>
<guid>CC467978-4675-AEA9-A6D1-95A14D51D656</guid>
</deviceCommand>
<!-- Optional attribute to hold the GUID of the device type that can be used
as the manager for workers of this type. This is used, for instance, in
the VNMC-VSG relationship, where the VSG device type (Nexus) declares
the VNMC device type GUID in this field. -->
<managerGuid>C4C0120B-31E1-4536-938A-F9AE8DF30D03</managerGuid>
<!-- Flags that the managerGuid must be populated for devices of this
type. -->
<managerRequired>false</managerRequired>
<!-- Flags that our manager will perform a trailing backup of this device
after it merges changes to it. If set to false, the expectation is
that syslog will be used to perform the trailing backup on the worker
device instead. This is necessary, for instance, in the VNMC-VSG case
because of unpredictability in the time the VNMC will take to flush
changes to the VSG in the background. -->
<managerBackup>false</managerBackup>
</deviceType>
</deviceTypeMap>Click here to view the Device Type map entry template for an HTTP-oriented device type containing a few possible fields.
<!-- ============================================================= -->
<!-- Template for a new HTTP-oriented device type. -->
<!-- Any attribute set to its default can be left out. -->
<!-- NOTE: Customer defined types should use a generated GUID -->
<!-- =========================================================== -->
<!-- ============================================================= -->
<deviceTypeMap xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<deviceType>
<!-- Use the create_guid script to generate new guid value -->
<!-- Example - <guid>2F621789-B4CF-426D-9188-BA4BFFF8AC9B</guid> -->
<guid>XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX</guid>
<name>A unique device type name</name>
<!-- Valid vendor GUID value from DeviceTypeMap.xml file -->
<!-- Example - <vendor>072DB2D7-48AA-4616-B9FA-7547726EE91D</vendor> -->
<guid>XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX</guid>
<!-- The supported models. This is just hard-coded documentation for reporting
purposes. BMC does not validate that a logged in device is one of these
models, nor this is stated from actual discovered models. -->
<supportedModelInfo>modelNo</supportedModelInfo>
<!-- The supported OS versions. This is just hard-coded documentation for
reporting purposes. BMC does not validate that a logged in device is
one of these OS versions, nor this is stated from actual discovered
OS versions. -->
<supportedOsVersionInfo>OSVersioNo</supportedOsVersionInfo>
<!-- Used when deciding OS image names when the name reported by a device
is not quite useful (such as "12.3"). For example, "IOS " prefix will
create an OS image named "IOS 12.3". -->
<imageNamePrefix>imagePrefix</imageNamePrefix>
<!-- If set to true, indicates that this device type extends an existing
one with the same GUID. An extended device type is used, for instance,
to encapsulate custom device commands that you want to add to a
particular device type. An extended device type is defined in a
separate DeviceTypeMap-*.xml file and gets merged into the existing
device type when loaded. It will be an incomplete device type
specification until it is merged. -->
<extension>false</extension>
<!-- The proxy server used. Default is none. -->
<proxy>none</proxy>
<!-- Flags that when comparing a configuration against a template, the
"diff" method, not any custom method, be used. Some devices support
a merge; but the file must contain a complete configuration (not just
relevant change snippets). Or, if not a complete configuration, then
the file must contain a large portions of it. For these devices,
template vs configuration comparisons look a lot better when
passed through "diff", since the two will have very much in common. -->
<alwaysUseDiff>false</alwaysUseDiff>
<!-- Flags that blanks and tabs should be ignored in the configuration files
when calculating differences. Some devices (e.g. HP 24xx) have
syntax where blanks don't matter and they don't appear predictably.
BMC Network Automation does not want to flag a discrepancy just
because of these blanks. -->
<ignoreBlanks>false</ignoreBlanks>
<!-- When set to true, sorts the contents of the entire configuration, except
for any lines that match a negated list defined in SmartMerge settings.
This flag is useful when a device orders its lines randomly, or when you
remove and then add a line again and the device always adds it to the end
(such as Juniper JunOS in set command mode). -->
<sortEntireConfig>false</sortEntireConfig>
<!-- Holds the GUID of the device command used to merge scripts that are not
a configuration marked with a trail (such as templates and target
configurations). Can be set to null when merge is not supported at all. -->
<defaultMergeCommandGuid>5421B3AE-2C94-0519-5D07-B4971BB15C7D</defaultMergeCommandGuid>
<!-- Holds the GUID of the device command used to restore scripts that are
not a configuration marked with a trail (such as templates and target
configuration). Can be set to null when restore is not supported at all. -->
<defaultRestoreCommandGuid>61A43CB3-2D57-66F7-32E3-59A1A1CD291E</defaultRestoreCommandGuid>
<!-- Flags whether this device type supports telnet connection access. Default
is true. -->
<supportsTelnetAccess>false</supportsTelnetAccess>
<!-- Flags whether this device type supports ssh2 connection access. Default is
false. -->
<supportsSsh2Access>false</supportsSsh2Access>
<!-- Flags whether this device type supports interactive SSH authentication.
Default is false. This tag is needed for some SSH servers
(e.g. Cisco4400, CSS) that prompt for a user name or password in spite of
that information already being passed in the protocol. When true, the xml
file must handle user name and password as part of the login device
command. -->
<supportsInteractiveSshAuth>false</supportsInteractiveSshAuth>
<!-- Flags whether this device type supports https 1.1 connection access. Default
is true. -->
<supportsHttps11Access>true</supportsHttps11Access>
<!-- Flags whether this device type supports https 1.0 connection access. Default
is true. -->
<supportsHttps10Access>true</supportsHttps10Access>
<!-- Flags whether this device type supports http 1.1 connection access. Default
is false. -->
<supportsHttp11Access>false</supportsHttp11Access>
<!-- Flags whether this device type supports http 1.0 connection access. Default
is false. -->
<supportsHttp10Access>false</supportsHttp10Access>
<!-- Flags whether this device type supports access via web services. Default is
false). -->
<supportsWebServiceAccess>true</supportsWebServiceAccess>
<!-- A terminal type, needed for some SSH servers (e.g. Nokia). Set this tag to
something like "dumb" or "vt100". SSHConnection will use it to request
a pseudo terminal. When set to null (default), SSHConnection won't prompt
for a pseudo terminal type. If your connection seems to be sending and
executing commands, but not getting back any responses, you probably need
to set this tag. -->
<sshPseudoTty>dumb</sshPseudoTty>
<!-- A terminal type, needed for some Telnet servers (e.g. Windows). Set this
to something like "dumb" or "vt100". TelnetConnection will use it to set
the telnet terminal type option if it is specified. If your connection
seems to be sending and executing commands, but not getting back any
responses, you probably need to set this tag.-->
<telnetPseudoTty>dumb</telnetPseudoTty>
<!-- Allows you to specify a non-default terminal width for SSH connections.
For a few devices (specifically F5 BigIP TMSH), a long prompt might wrap
at 80, which could be in the middle of the prompt, causing you to miss
reception of the prompt. These devices do not have any method to set the
terminal width after login. This tag enables you to set the SSH terminal
width in the adapter. -->
<sshTerminalWidth>90</sshTerminalWidth>
<!-- Allows you to specify a non-default terminal width for Telnet connections.
For a few devices (specifically MRV OptiSwitch), a long prompt might wrap
at 80, which could be in the middle of the prompt, causing you to miss
reception of the prompt. These devices do not have any method to set the
terminal width after login. This tag enables you to set the Telnet terminal
width in the adapter. -->
<telnetTerminalWidth>80</telnetTerminalWidth>
<!-- Flags whether to enable the FIPS mode while using SSH connection. Default
is false. When set to true, it enables FIPS-compatible algorithms and
disables any other non-compatible algorithms. So, while using SSH
connection in FIPS mode, it uses key exchange algorithm and ciphers which
are supported by FIPS only. For example, KEX_DIFFIE_HELLMAN_GROUP14_SHA1,
CIPHER_AES128_CBC, CIPHER_AES192_CBC, CIPHER_AES256_CBC,
CIPHER_TRIPLEDES_CBC, HMAC_SHA1,HMAC_SHA256, etc. When FIPS mode is enabled
on a device, you can set this flag to true to connect the device from BMC
Network Automation. -->
<enableFIPSModeForSsh>false</enableFIPSModeForSsh>
<!-- Flags whether this device type supports tunneled file transfer inside the
connection protocol. Default is false. -->
<supportsTunneledTransfer>false</supportsTunneledTransfer>
<!-- When using file transfer, specifies the filename extension for the
temporary files sent to or received from a device. Typically, the temp
files are called ena-#.tmp or agent-#.tmp. However, a few devices
generate or allow files named with specific extensions (such as .zip).
The specified extension will replace the normal .tmp extension. You must
include the dot (.) to make it a true extension. -->
<transferredFilenameExtension>.tmp</transferredFilenameExtension>
<!-- When true, BMC Network Automation removes the extension from the
transfer filename in the commands. This tag is used in conjunction with
the transferredFilenameExtension tag, when device's file transfer commands
assume a particular extension and do not work if you try to give it your
own extension (for example, MRV LX device). When set to false (default),
commands include the filename with its extension. -->
<stripFilenameExtensionFromCmds>false</stripFilenameExtensionFromCmds>
<!-- Flags whether this device type supports tftp file transfer. Default is
true. -->
<supportsTftpTransfer>true</supportsTftpTransfer>
<!-- Flags whether this device type supports ftp file transfer. Default is
false. -->
<supportsFtpTransfer>false</supportsFtpTransfer>
<!-- Flags whether this device type supports scp file transfer. Default is
false. -->
<supportsScpTransfer>false</supportsScpTransfer>
<!-- Indicates the sleep time between the time BMC Network Automation
reboots a device and the time it makes the first connection attempt,
to allow the device to shut down completely. By default, sleep time is
ImportedGlobals.DEVICE_REBOOT_SLEEP_SECONDS (which defaults to
15 seconds). If this is not enough time for the device to fully shut
down, BMC Network Automation might log into it again prematurely. If you
set this attribute to a greater value than the default value, the
sleep time is rebootSleepSeconds instead (that is, sleep time is the
greater of the two values). -->
<rebootSleepSeconds>20</rebootSleepSeconds>
<!-- If true, then the device automatically reboots as a side effect of the
performing a restore operation. This flag could control whether the reboot
option is presented or not in the GUI when you have chosen to perform a
restore. However, it is currently used only by FileConnection during
simulated restores; has absolutely no effect otherwise. -->
<rebootsAfterRestore>false</rebootsAfterRestore>
<!-- Indicates the sleep time between a device becoming partially and fully
connectible. Some of the devices (e.g. CatOS) are initially only partially
connectible after a reboot, in that they present single-user connectivity.
A few seconds later, they present the expected multi-user connectivity. -->
<securitySleepSeconds>0</securitySleepSeconds>
<!-- Flags whether the device will prompt you before rebooting when there are
unsaved changes in the memory. If true, the saveChoice property will need
to be set so that BMC Network Automation knows how to respond. Defaults
to false. -->
<promptsUnsavedChanges>false</promptsUnsavedChanges>
<!-- When set to a string, sends that string to the device whenever BMC Network
Automation fails to receive a response in the allotted time. This presents
a workaround for a crazy issue with devices ,such as Foundry NetIron,
where, completely at random, it decides to ignore a command sent by
BMC Network Automation and if BMC Network Automation sends it a newline
after waiting for a minute, it then accepts the command and proceeds
normally. -->
<kickAtResponseTimeout>none</kickAtResponseTimeout>
<!-- Flags whether this device type supports multiple security contexts
(such as the Cisco ASA, FWSM, and ACE devices). -->
<supportsMultipleSecurityContexts>false</supportsMultipleSecurityContexts>
<!-- Flags whether this type supports separate configuration files per security
context (such as Cisco ASA, FWSM, & ACE devices). -->
<supportsConfigPerSecurityContext>true</supportsConfigPerSecurityContext>
<!-- Flags whether this device type can be a virtual machine (e.g. Cisco VSG for
NexusOS). It does not indicate it has to be a virtual machine, however. -->
<virtualMachine>true</virtualMachine>
<!-- If true, irrespective of the transfer mode of the device, the transfer mode
will be forced to be tunneled transfer during merge action. The flag is
purely used in context of container configuration merge actions. -->
<requiresTunnelingForContainerMerge>false</requiresTunnelingForContainerMerge>
<!-- If true, device transfer mode will be forced to be tunneled transfer for
devices having user-defined security context. -->
<requiresTunnelingForUserContexts>false</requiresTunnelingForUserContexts>
<!-- When set to true, a configuration can be merged to the device in
tunneled mode; that is, a line-by-line merge of a complete configuration or
lines computed from one will work, since the configuration contains commands
the device will understand in the tunneled loop. When set to false
(as for F5 and JunOS), a configuration cannot be tunneled out; that is, the
lines in the configuration are not executable commands understood in the
tunneled loop; a template containing executable commands can however be
tunneled out.-->
<supportsTunnelMergeForConfigurationFile>true</supportsTunnelMergeForConfigurationFile>
<!-- Name of the security context which BMC Network Automation will automatically
switch to in order to create (or destroy) a new guest context on a load
balancer or firewall host during container configuration. This value is
"system" for the FWSM device type. You can also set it to null. When
populated, it will get assigned to the TARGET_SECURITY_CONTEXT_NAME
connection property and passed in to the action to merge the template to
the host device to create (or destroy) the new context during container
configuration. This allows the DTM logic to automatically switch to the
target context rather than having to embed the context switch command in
the template, since that leads to awkward contortions in the logic. -->
<creatorSecurityContextName>system</creatorSecurityContextName>
<!-- If device supports the image deletion command, this tag flags
whether it supports the forward (prior to image deploy(load)) or
backward (after image deploy(load)) style deletion. -->
<supportsForwardImageDeletion>false</supportsForwardImageDeletion>
<!-- Flags whether this device type supports management by serial terminal
servers. Note that all device types are assumed to automatically support
the connection proxy terminal servers, since no new interaction logic is
required for it. -->
<supportsSerialTerminalServerManagement>false</supportsSerialTerminalServerManagement>
<!-- Regular expression specifying the filename pattern which indicates an
archive style image file. This is used in Cisco IOS to distinguish between
the tar style and binary style image deploy (load). -->
<imageArchiveFilename>^(.+\.tar|.+/.+).*</imageArchiveFilename>
<!-- List of illegal characters (with no delimiters and enclosed in square
brackets) that need to be stripe out from port-type name configured
in a hypervisor switch. -->
<illegalPortTypeNameCharacters>[ ]</illegalPortTypeNameCharacters>
<!-- When true, indicates that the original filename should be used when
performing file transfer during image deploy (load); that is, do not use
files named ena-*.tmp on the server side, but write to a file that is
named the same as the source file selected for image deploy (load). For
example, Extreme XOS will only transfer files that are named the right way,
with .xos or .xmod extensions, not randomly named files. -->
<preserveFilenameOnImageLoad>true</preserveFilenameOnImageLoad>
<!-- Name of the class that will be used for loading images on this device
type. -->
<imageLoaderClassName>
com.bmc.bcan.engine.network.devices.XYZImageLoader
</imageLoaderClassName>
<!-- Specify the file systems supported for OS image deploy (load) action. -->
<supportedFileSystems>
<fileSystem>primary</fileSystem>
<fileSystem>secondary</fileSystem>
</supportedFileSystems>
<osImageInformation>
<osImageType order="1" name="system" primary="true"/>
<osImageType order="2" name="kickstart"/>
</osImageInformation>
<hardwareInventoryClassName>
com.bmc.bcan.engine.network.devices.XYZHardwareInventory
<!-- When this device type supports discovery of the detailed information
about the hardware components that make a device, this tag contains this
information. -->
</hardwareInventoryClassName>
<!-- Whether or not this device emits a syslog message suitable for use as
an auto-archive trigger. This can be a syslog emitted message when
configuration mode or edit mode is exited, or when a user logs out. The
syslog has to include text that indicates this event, and the text must
include the IP/host of the user who did it (so user can identify syslogs
that BMC Network Automation generated and ignore them, to avoid
self-triggered auto-archive loops). -->
<supportsSyslogAutoArchiveTriggerInfo>true</supportsSyslogAutoArchiveTriggerInfo>
<!-- Indicates which functions (to be used in ${eval} substitution parameter
resolution) generate properly-encrypted passwords. This is used only for
reporting and documentation purposes. -->
<passwordEncryptionFunctionInfo>encrypt_md5_hex</passwordEncryptionFunctionInfo>
<!-- SNMP Object IDs (OIDs) and corresponding device categories that are
reported by this device type.
Map
key: String START of an OID that will match
value: Integer device category -->
<snmpOids>
<snmpOid>oid string</snmpOid>
</snmpOids>
<!-- For a particular device type, defines the configuration trail and its
type. -->
<supportedConfigurationTrailDeclarations>
<!-- Running -->
<supportedTrail>
<!-- Supported configuration trail -->
<guid>02C89A1F-A5D2-44B0-AE1E-B714EB0E3FAF</guid>
<!-- Data format in a configuration in this trail. It can be ascii (default)
or binary. -->
<format>binary</format>
<!-- The guid of the DeviceCommand that backs up this trail. -->
<backupCommandGuid>388DFC1D-2DF0-D833-5762-F5121A797069</backupCommandGuid>
<!-- The guid of the DeviceCommand that merges this configuration -->
<mergeCommandGuid>5421B3AE-2C94-0519-5D07-B4971BB15C7D</mergeCommandGuid>
</supportedTrail>
</supportedConfigurationTrailDeclarations>
<!-- Extends DeviceCommand to include the logic specific to http-oriented
interactions. -->
<httpDeviceCommand>
<!-- login -->
<guid>0E8DB22F-DEF8-987E-1AFB-7BE8BBCC9BEA</guid>
<!-- Encapsulates one http-oriented interaction (send get/post request
and gather response) with the device's http server.
<httpInteraction>
<!-- Encapsulates specification of the post request to send. Can be null
if the interaction involves a get or delete rather than a post
request. -->
<post sensitive="true" sensitivePhrase="%password%"></post>
<!-- Caches response string (if any) matched during response
processing. -->
<response>200</response>
<!-- Optional attribute to specify a property into which the entire
transcript of the command's execution will be substituted. -->
<capture></capture>
<!-- Encapsulates all information about matching a particular RequestHeader
string in the device RequestHeader stream. Corresponds to an optional
<RequestHeader> element in the <HttpInteraction> element of the
DeviceTypeMap xml file. -->
<requestHeader></requestHeader>
<!-- Encapsulates all information about matching a particular RequestBody
string in the device RequestBody stream. Corresponds to an optional
<RequestBody> element in the <HttpInteraction> element of the
DeviceTypeMap xml file. -->
<requestBody></requestBody>
</httpInteraction>
</httpDeviceCommand>
<!-- discover core -->
<httpDeviceCommand>
<guid>1E91FAD6-FBB7-5D7C-120F-ABD77583A086</guid>
</httpDeviceCommand>
<!-- copy running to net -->
<httpDeviceCommand>
<guid>388DFC1D-2DF0-D833-5762-F5121A797069</guid>
</httpDeviceCommand>
<!-- copy net to running -->
<httpDeviceCommand>
<guid>5421B3AE-2C94-0519-5D07-B4971BB15C7D</guid>
</httpDeviceCommand>
<!-- logout -->
<httpDeviceCommand>
<guid>E6C631FC-33CA-812E-55D5-6CF772428705</guid>
</httpDeviceCommand>
</deviceType>
</deviceTypeMap>Notes
- Include the definition of the vendor at the top.
- If your device type is from a vendor that is not already present in your system, assign a new GUID to the vendor. Use the BCAN_HOME/tools/create_guid.sh script to generate a new device type GUID.
- Use the analysis performed in the Considerations-when-adding-a-new-device-type section to begin the development of the device type.
- Use the XML syntax and examples on the Device-type-command-content page to further develop and tweak the device type.
Capture all quirks relating to the XML interactions as XML comments by using the <commentBlocks> tag at the bottom of the command concerned.
Click here to view the child tags of this tag
Tag
Description
block scope="trail1,trail2"Scope limits which trail comparisons should consider this a comment block.
block context="x"Context limits when the comment block should apply (discrepancy checking, compliance checking, and so forth).
block caseSensitive="true or false"Determines whether the contents of the block are treated in a case-sensitive manner or not. The default if this tag is omitted is false.
begin inclusive="true or false"Regular expression that indicates the start of the comment block. When inclusive is true, the begin line is part of the comment.
end inclusive="true or false"Regular expression that indicates where the comment block stops. When inclusive is true, the end line is part of the comment.
includeRegular expression that indicates a line that the block must contain in order for the block to be considered a comment. So only blocks containing this line would be considered as a comment.
excludeRegular expression that indicates a line that the block must not contain in order for the block to be considered a comment. So no block containing this line would be considered as a comment. If both the include and exclude are matched, include takes precedence and the block qualifies as a comment block.
match invert="true or false"Regular expression that defines which lines inside the block should be comments. This tag allows you to comment out sections of blocks. When invert is true, then lines not matching the regular expression will be considered as comments.
- (Optional) Internationalize the device type map files.
- Import the file that contains your device type.
Related BMC Communities video
The following BMC Communities video (6:22) describes how to create a REST-based device adapter in BMC Network Automation.
https://www.youtube.com/watch?v=UnIEPelChgc&list=PLr4ck07lc-F8iEOqfe2sYqkR5LBYo1WKI&index=5