There are several ways to configure the device. The solution requirements dictate your method to configure the device. They consist of graphical tools and automated/scripted and programmatic processes. You can use these methods in combination, and all methods result in a similar implementation on the device.
The WebGUI and the CLI through Secure Shell (SSH) are the two major ways of administering configurations. For every operation that can be done in the WebGUI, there is a corresponding operation in the CLI.
Regardless of the configuration method used, the end result of each operation is a modification to the onboard device configuration. This data is expressed as an ASCII file resident on the device’s encrypted RAM file system, and this data contains a list of CLI commands. If the WebGUI or XML Management Interface was used, the execution of the interface is translated into the corresponding CLI commands. Upon the restart of the device, the designated configuration file is loaded, and services and objects are reconstructed from its content and references to external resources. This on board configuration file can be downloaded, edited, and reloaded on to the device.
The WebGUI interface is the simplest management interface to use. On most pages, a help link provides online help through a pop-up browser window. Most fields also provide in-line help when selected. Lastly, the two-step process for committing configuration changes provides an opportunity to discard changes.
Command line interface
The command line interface (CLI) provides a simple but powerful management interface. Its syntax is familiar to terminal users on a UNIX®-like environment. Unlike the WebGUI, configuration changes are immediately committed. An undo command allows administrators to revert to a previous configuration. All administrators need to be familiar with basic CLI commands, because this management interface is the only interface that is available on first use to enable one of the other management interfaces by using the configure terminal command.
The CLI is a streamlined yet powerful system for controlling every facet of the appliance. Although it looks like a command shell, there is no compiler or interpreter to run arbitrary code. The alias function is a macro for multiple CLI commands, and the exec function executes configuration scripts that are limited to the device itself.
In the global configuration mode, the administrator can create, modify, or remove any DataPower service or interface that can be found in the WebGUI.
The CLI is not a true scripting facility, such as Perl, Tcl, or ANT. The alias CLI command does allow a simple form of defining a set of commands to execute. Automating the repetition of tasks in a scripting language is much easier than using a Web GUI. Scripting in this sense is the sequencing of commands. CLI shell file that imports a WS-Proxy to the Demo application domain of the device.
CLI shell file
Tasks executed in Web GUI require the user to remember what they performed, especially when they need to undo actions. Administrators can create an undo script to ensure that changes are undone.
Many options exist for migrating changes from development to production. For example, using the Web GUI, administrators can create the domain configuration and store it on a Web server. The domain on the appliance can reference this configuration on startup. Another option for importing shared objects into a domain is to use packages. The package contains the set of shared objects used by several domains.
These methods can be used to migrate changes from development to production. They might not be the preferred methods, because they cannot be audited and the consistency in the files cannot be guaranteed.
XML Management Interface
You can also use the XML Management Interface (MI).
XML Management Interface description
The XML Management Interface provides a structured language for sending a batch of configuration commands. This interface allows for the rapid automated configuration of new application domains or entire DataPower service-oriented architecture (SOA) Appliances.
The XML Management Interface allows appliance management using different XML-based interfaces and specifications. The SOAP Management URI (SOMA) interface enables management using SOAP over HTTPS. The SOMA interface provides advantages over other approaches. Because it is programmatic, it can be used to build a custom management application using a programming language, such as Java. Also, it executes remotely without any tools as compared to the WebGUI, which requires a Web browser, and CLI, which requires an SSH client.
The SOAP interface extends its functionality to third-party Web service clients. It involves the programmatic modification of configuration data and can be based on external conditions and events. For example, a brokerage organization can define a service level agreement (SLA) that limits the number of trades that a client can execute in a given time frame. However, based on market conditions, the parameters of this SLA can change.
The SOAP interface demonstrates a potential use of the XML Management application programming interface (API). This facility allows for the authenticated real-time modification of configuration data via SOAP messages sent over a secured HTTPS interface. All the functions of the WebGUI and CLI are supported using the XML Management API. Each request is packaged as a SOAP message.
Formatting of request SOAP documents is derived via the Web Services Description Language (WSDL) and XML Schema Definition (XSD) documents available from the store directory of the device. It also provides configuration management tools. For information regarding request formats, refer to the WebGUI documentation for your device.
In addition to the standard XML Management API, there are new functions that are tailored to B2B business scenarios. Creation of trading partner profiles, creation of partner profile groups, creation of B2B Gateways, and so forth are all functions that can be addressed programmatically via the XML Management Interface.
This flexibility, ease of use and decoupling from the WebGUI interface can have advantages for administrators who handle many partner profiles, for instance, the automated creation of hundreds of partner profiles as compared to the manual entering of each profile in the WebGUI.
Creating B2B profiles
The SOAP request this shows the creation of B2B partner profiles through the use of the XML Management Interface. This example creates two partner profiles called Test_Ext (external partner) and Test_Int (internal partner). These profiles are created in the domain called student07. Notice the student07 attribute in the dp:request element.
XML Management Interface request creating partner profiles
To invoke the the command in this through the XML Management Interface, we can issue the command using the cURL utility:
Add partner profiles to an existing B2B Gateway
The snippet of code in this shows how to add existing profiles to an existing B2B Gateway object. The profiles Partner_Int, Partner_Ext, and Partner2_Ext will be added to the existing B2B Gateway called MyTest.
Adding partners to an existing B2B Gateway
Advanced XML management concepts
WebSphere DataPower SOA Appliances contain a powerful management framework that is accessible through XML messages that are sent over HTTPS.
These messages can be chained and scripted in order to perform automated configuration management and operations on the device. In order to perform configuration management through the XML Management Interface, the interface must first be enabled through the CLI or WebGUI. After this enablement is done, the XML commands can be sent to the specified host/port/URL. we perform a substitution on the file to create a new domain with its own user and group defined.
Initial XML file
this is a shell script that can make the substitutions.
Shell script file
This newly created file (domain. xml) can then be sent to the XML Management Interface using the cURL utility:
In this statement, <IP> is the address of your DataPower device, and <pass> is your admin password for this device.
Note:In order to provide for a cleaner configuration that minimizes migration issues, we recommend that you use the host alias instead of the dot decimaladdress in services that expose external ports. Also, you need to use an environment-specific DNS when possible rather than a dot decimal address and use static hosts to handle DNS aberrations. In order to eliminate extra work, migrate only those objects that require migration.
IBM Websphere Related Tutorials
|IBM DB2 Tutorial|
IBM Websphere Related Interview Questions
|IBM DB2 Interview Questions||Weblogic Interview Questions|
|IBM WebSphere Datapower SOA Appliances Interview Questions||IBM WAS Administration Interview Questions|
|IBM Websphere Application Server Interview Questions||IBM WebSphere MQ Interview Questions|
|WebLogic Administration Interview Questions||IBM DataPower Interview Questions|
|Ibm Websphere Message Broker Interview Questions||Ibm Websphere Cast Iron Interview Questions|
|Ibm Websphere Process Server Interview Questions|
Ibm Websphere Tutorial
B2b Technologies And Standards
B2b Deployment Methodology
Aspects Of B2b Security
Websphere Datapower B2b Appliance Xb60
Device Setup And Administrative Tasks
B2b Configuration Options
Troubleshooting The Appliance
Xb60 And Wtx Integration For Hipaa
Xb60 With Transformation
Trading Outbound Binary Documents Using The B2b Gateway Service
Trading Binary Documents Using A Multi-protocol Gateway Service
Handling Soap Messages With Attachments In A B2b Environment
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.