What's new in MyST 5.0

In this release, we are bringing a lot of new features and improvements.

1. New Features

2. Improvements

3. Release Details

BAM Artifact Deployment

Deployment of BAM (12.2.x) Artifacts is now supported by MyST Studio and MyST CLI.

A BAM artifact is an export from a BAM server. The file extension is .zip, and might contain a MyST Generic Customization file inside the package.

We recommend the optional MyST configuration plan to be placed under META-INF/myst-config-plan.xml. Following this convention, enables MyST to pickup the configuration plan automatically without any additional configuration.

The MyST Config Plan is typically used to customize the resources at deployment time, with environment specific settings. The following snippet is just an example to demonstrate how the properties get replaced. It's basically replacing the content based on an XPath expression with a variable which has stored the WLS domain name.

<tns:configplan xmlns:tns="http://myst.rubiconred.com/configplan">
<update-list> <update> <fileset casesensitive="yes"> <include name="dataobject/OrderDO/DataObject.xml" /> </fileset> <search-replace-list> <search-replace> <xpath>simpleDataObject/displayName</xpath> <replace>${core.domain.name}</replace> <!-- Could be one of fail, warn or ignore --> <action-on-not-found>fail</action-on-not-found> </search-replace> </search-replace-list> </update> </update-list> </tns:configplan>

The Artifacts can either be defined as a third party artifacts, meaning that the artifact was pre-built, or it could be built by your CI server and have the artifact directives published to MyST Studio. In either cases, we integrated with standard binary repositories.

In the following screenshot, you can see a BAM artifact defined as a third party artifact.

MFT, B2B Artifact Deployment

MFT and B2B artifact deployment is now supported in MyST Studio. Previously this feature was available only from the MyST CLI.

The artifacts must be an export from a server (typically automated), and the capability is the same as the BAM deployment capability.

Archiva is now supported

We have certified support for Archiva Binary Repository in MyST Studio. We now have support for the three main Maven repositories in the market: Archiva, Artifactory and Nexus.

All you need to do is to define which Binary repository you want to use, the URL and credentials. That's enough for MyST to retrieve the artifacts from that repository during deployment.

Artifact Deployment Configuration Plan improvement

What does this mean to me? You now have to specify less metadata at the artifact level to apply customizations at deployment time. MyST will automatically detect if there is a customization plan, based on naming conventions. You can always override them if required.

Context MyST supports the following configuration plans, which are applied at artifact deployment time:

  • OFMW component customization file provided by Oracle for the following artifact types:

    • Oracle Service Bus: If the metadata field customization-file is left empty, MyST will attempt to apply the customization file if present inside the OSB package artifact, located either under: /OSBCustomizationFile.xml or inside <OSBPROJECT>/OSBCustomizationFile.xml

    • SOA Composite: If the metadata field composite.configuration-plan is left empty, MyST will attempt to apply the customization file if present inside the SCA package artifact, under /cfgplan.xml

  • Generic Customization plan, which can be applied to any resources within an artifact, and provides great flexibility. Supports for the following artifact types:

    • ADF
    • B2B
    • BAM
    • Java Apps (WAR, EAR, JAR shared libraries)
    • Oracle Service Bus
    • MFT
    • SOA Composite

If the metadata field myst-config-plan-apply is empty, the default value will be true.

If the metadata field myst-config-plan-location is left empty, MyST will try to apply the customization plan file inside the artifact package, under: META-INF/myst-config-plan.xml

Following an example when defining an MFT artifact:

RCU Drop connections on AWS RDS

What does this mean to me? If you are using AWS RDS, and in some edge cases where the database connection is not closed on the DB at the time of a platform termination, MyST will handle that for your, rather than returning an error.

Context: As part of the platform lifecycle, there are some use cases where MyST is requested to drop the database schemas. That happens for example when the user requests for a OFMW platform to be terminated, which means that the platform is no longer required.

Prior to dropping the database schemas by invoking RCU, MyST checks if there is any client connected to the database, and if there is a connection, it forces a drop connection on the database.

This feature now supports AWS RDS. MyST automatically detects if the Oracle database is running on RDS, and applies the correct drop DB connection mechanism, in order to conform with the privilege constraints.

Custom settings.xml support for Binary repository

What does this mean to me? You can now define your Maven settings.xml file in MyST Studio, and MyST will take care of using it in order to retrieve your artifacts at deployment time.

This gives more control, especially if you have a few customizations you want to do in the settings.xml and don't want to distribute them manually.

Context: In order for MyST to deploy an artifact, MyST needs to know which Binary repository to connect to. Also, might need to know about credentials and other repository settings.

Up to MyST 4.0.x, you had to define these details in the Maven settings.xml in the remote OFMW machines, for each of the OFMW platforms.

Now you can manage the settings.xml centrally in MyST Studio, and MyST will take care of distributing it and using whenever needed.

You can simply define the settings.xml by accessing Infrastructure -> Continuous Delivery Profiles -> Default -> Binary Repository Details, as follows:

Platform Lifecycle when using AWS On-demand instances

The following improvements are in place when provisioning a model based on AWS On-demand

  • When provisioning a platform model, you have now the option for MyST to either terminate or leave the instances running in case of a provisioning failure, as follows:

  • When terminating a platform model, you have the option to either terminate the EC2 instances, or leave them running.

  • Note: At the moment, the re-provisioning option will always create new EC2 instances. We will improve this behaviour in future.

Migratable targets are now supported for Weblogic resources update

Any target can be set to a migratable component.
e.g. soa_server1 (migratable)

Per-host Node Manager can now be enabled using MyST

By default, when you define a Platform in MyST for OFMW 12c, MyST will configure the Node Manager co-located with the Weblogic domain.

In case you want to define a per-host Node Manager, you need to set the following property under Products -> Oracle Weblogic -> Name-value parameters:

per-host-nm-enabled=true

Custom nodemanager.properties can now be set using MyST

You can customise any Node Manager property. Follow these steps:

  • You need to first navigate to Products -> Oracle Weblogic
  • Add a new Name-value parameter Key with the following convention: nm-<PropName>
  • Define the property value
  • Save

In the example below, we defined nm-SecureListener=false. This means that a property called SecurityListener=false will be set in the nodemanager.properties

Custom OHS logging now supported

MyST now supports custom log formats and configuration with the following Webtier product parameters:

  • core.product[webtier].param[custom-log-format] - which controls the setting of the OHS httpd.conf LogFormat directive.
  • core.product[webtier].param[custom-log-config] - which controls the setting of the OHS httpd.conf CustomLog directive
LogFormat Example

Setting LogFormat to the NCSA extended/combined log format would look like this:

core.product[webtier].param[custom-log-format]="%h %l %u %t \"%r\" %>s %b \\"%{Referer}i\\" \\"%{User-agent}i\\"" ncsa_combined

Note especially that any double-quote in the log format must be escaped with double forward slash '\\' rather than a single slash '\' due to MyST interpreting the string at runtime.

The name of the format (ncsa_combined) is arbitrary, but all other information is specific to Oracle HTTP Server's LogFormat directive, and in this case providing the following information:

  • %h - remote hostname issuing request
  • %l - remote logname (RFC 1413-compliant username or -, typically)
  • %u - remote username if request was authenticated
  • %t - time the request was received
  • %r - first line of request
  • %>s - final status of request
  • %b - size of response in bytes
  • %{Referer}i - referer of request, or -
  • %{User-agent}i - user agent value provided by client in request header

For more detail on the information available to be logged in Oracle HTTP Server custom log file formats, refer to Apache HTTP Server's LogFormat documentation.

CustomLog Example

The CustomLog directive works in conjunction with the LogFormat directive in OHS configuration, specifying the file location for access logs, rotation parameters and indicating one of a number of potential log formats identified via LogFormat directives to use for the server's access logs. (while MyST only allows specifying a single custom format, one is all you can use at the end of the day!)

Setting CustomLog to use the ncsa_combined format identified in the last example, rotating log files at 10M each and allowing 300M total for access logs would look like this:

core.product[webtier].param[custom-log-config]="||\\$\\{PRODUCT_HOME\\}/bin/odl_rotatelogs \\$\\{ORACLE_INSTANCE\\}/servers/\\$\\{COMPONENT_NAME\\}/logs/access_log 10M 300M" ncsa_combined

Note especially the leading '||' at the start of the configuration string, and the '\\' escaping of any $, { or } character to prevent MyST interpreting environment variables used by Oracle HTTP Server at runtime.

For more information on the parameters supported by odl_rotatelogs, refer to Oracle Webtier's documentation as a starting point.

Configuring custom logging in MyST Studio

To configure these parameters in MyST Studio, perform the following steps:

  1. Open the blueprint or model using Webtier.
  2. Navigate to Products / Oracle Webtier in the left-hand tree menu
  3. Click the Edit Configuration button (at the top-right of the screen)
  4. Click the Edit button at the centre bottom of the screen.
  5. Click the + Add One button to add a name-value parameter entry for each product parameter (shown in the screenshot above)
  6. Provide the name and value for each product parameter. Note in the screenshot shown that the value entered for both custom-log-format and custom-log-config includes the double-quotes shown earlier.

Lifecycle improvements for OAG and OTD

MyST now takes extra care to ensure that all components comprising an OAG or OTD environment are shut down or started correctly as part of the standard MyST start and stop commands.