# Create Third-Party Modules for MCS


You can create your own third-party MCS modules by following these steps:

 [Step 1: Design your Third-Party Module](step-1-design-you-third-party-module.md) 

 [Step 2: Create the CloudFormation template](step-2-create-the-cloudformation-template.md) 

 [Step 3: Create the assets referenced by the template](step-3-create-the-assets-referenced-by-the-template.md) 

 [Step 4: Create the module metadata](step-4-create-the-module-metadata.md) 

 [Step 5: Create the module manifest](step-5-create-the-module-manifest.md) 

 [Step 6: Create module intercommunication](step-6-create-module-intercommunication.md) 

 [Step 7: Create module instructions (optional)](step-7-create-module-instructions.md) 

# Step 1: Design your Third-Party Module


Beneath the surface, an MCS module is a CloudFormation stack defined by a CloudFormation template. When the module is registered with MCS, it is added to a product portfolio in Service Catalog.

MCS needs additional details about the module, such as the module type (for example, Network, Identity, Workstation Management, Storage, or Custom), revision, and dependencies on resources from other modules. This metadata is necessary for module discovery and registration.

To define a module, you need:
+ A CloudFormation template
+ Assets referenced by the template
+ Module metadata (as part of the CloudFormation template)
+ Module revision manifest file

Conceptually, registered module data is referenced as follows:

```
 Modular Cloud Studio on AWS
 \
 \ (Module)
 \-------------> Module Revision Manifest
|
|(1.0.0)
 +----------> AWS CloudFormation Template + Module Metadata
|\
|\---> CFN Resource Assets
|
|(2.0.0)
 +----------> AWS CloudFormation Template + Module Metadata
|\
|\---> CFN Resource Assets
|
|(2.1.0)
 +----------> AWS CloudFormation Template + Module Metadata
|\
|\---> CFN Resource Assets
|
|(3.0.0)
 +----------> AWS CloudFormation Template + Module Metadata
 Metadata
 \
 \---> CFN Resource Assets
```

# Step 2: Create the CloudFormation template


The CloudFormation template defines the infrastructure that makes up the module. When you register a new module, MCS uses [ValidateTemplate](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_ValidateTemplate.html) to validate the template and extract parameters. The template must be accessible so that MCS can fetch the template.

MCS fetches the CloudFormation template and generates a checksum to store along with the registration metadata. When the module is enabled, MCS verifies that the template still matches the checksum to ensure that it didn’t get corrupted or modified since it was registered. If the checksum doesn’t match, MCS reports the mismatch as an error, and the module isn’t enabled.

For instructions on how to create CloudFormation templates, see [Working with CloudFormation templates](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html) in the *AWS CloudFormation User Guide*.

# Step 3: Create the assets referenced by the template


The assets must be accessible so that the CloudFormation template can access the assets when deploying the stack. For example, the asset can be a public Amazon S3 object.

# Step 4: Create the module metadata


MCS needs additional metadata about a module that isn’t part of the native CloudFormation template. The module metadata is stored in the CloudFormation template in the [Metadata](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/metadata-section-structure.html) section. The metadata is stored with the template and no linkage is necessary with an external file.

The [module metadata schema](module-metadata-schema.md) requires the following additional information specific to MCS:
+ Module type
+ Module name
+ Dependencies on other modules
+ Module revision number

# Step 5: Create the module manifest


To track MCS module updates, you must list module revisions in an external [module manifest](module-manifest-schema.md) file. The module manifest must be accessible so that MCS can read it. There is only a single manifest file per module. When you publish a new revision of a module, update the manifest to reflect that a new revision is available.

The [module manifest schema](module-manifest-schema.md) must meet the following requirements:
+ Be in JSON format
+ Include the following:
  + Name of the module author/owner (company name)
  + Description text
  + Optional URL to the web page with more information about the module
  + Module name
  + Module category (Network, Identity, WorkstationManagement, Storage, PixelStreaming, or Custom)
+ Contain an array of revisions, each of which:
  + Specifies the URL(s) to the CloudFormation template:
    + Use `TemplateUrl` when the hub and spoke modules share the same template.
    + Use `TemplateUrls` when the hub and spoke modules have separate templates, or for hub-only modules.

**Note**  
 **Note:** These two fields are mutually exclusive.
+ Includes the revision number.
+ Includes compatibility information specifying which revisions of MCS it is compatible with.
+ Contains details about what’s new in the revision.

When registering a new external module, the MCS admin user only requires the URL of the module manifest file. Optionally, the user can also specify a revision number to access a specific revision of the module. If the revision is not supplied, MCS assumes that the user needs the latest compatible revision of the module.

# Step 6: Create module intercommunication


To facilitate a pattern known as dynamic dependency loading, the configuration data is stored on the Systems Manager Parameter Store so that it can be lazy-loaded exactly when it is needed by an MCS module.

The following is the structure of all parameters output by MCS:

```
/{deployment_id}/{module_type}/{component}
```
+  **deployment\$1id** - This value is generated when MCS is first deployed and is configured on the Lambda function serving API requests. When deploying any module (including Third-Party Modules), the `deployment_id` is provided as a CloudFormation parameter. The `deployment_id` is always prefixed with `mcs-`.
+  **module\$1type** - This value is the type of the module providing the output. The same type can be used by multiple mutually-exclusive modules that provide the same output such as AWS Managed Microsoft AD, compared to unmanaged Microsoft Active Directory.
+  **component** - The name of the component providing the output. There could be one or multiple paths as part of this value.

As an example, see the following Managed Active Directory module with its input and output parameters (created after completing the steps to [Create Third-Party Modules for MCS](create-third-party-modules-for-mcs.md)):
+ MCS Managed Active Directory module - inputs:

```
/{deployment_id}/Network/VpcId
/{deployment_id}/Network/PrivateSubnet1/AZ
/{deployment_id}/Network/PrivateSubnet1/SubnetID
/{deployment_id}/Network/PrivateSubnet2/AZ
/{deployment_id}/Network/PrivateSubnet2/SubnetID
```
+ MCS Managed Active Directory module - outputs:

```
/{deployment_id}/Identity/ActiveDirectoryId
/{deployment_id}/Identity/ActiveDirectoryServerIP1
/{deployment_id}/Identity/ActiveDirectoryServerIP2
/{deployment_id}/Identity/ActiveDirectoryDomainName
/{deployment_id}/Identity/ActiveDirectorySecretArn
/{deployment_id}/Identity/DefaultActiveDirectoryLoginCredentials
/{deployment_id}/Identity/StudioAdminDirectoryLoginCredentials
```

For more information on parameters, see the [Module parameters](module-parameters.md) section

# Step 7: Create module instructions (optional)


This step allows you to provide custom, user-friendly instructions within the MCS interface, enhancing the user experience by offering clear guidance on module usage after enablement.

To implement module instructions, you’ll need to create an AWS Lambda function that returns instruction content. The Lambda function must be named with the prefix `MCSInstructionGenerationLambda-` and be referenced in your CloudFormation outputs with the key `InstructionGenerationLambdaArn`. Append your stack id (without hyphens) to the Lambda function name is recommended to ensure unique naming across multiple deployment in the same region.

The function can return either a plain string or a JSON object formatted as `{"content": "your instruction string"}`. A basic example implementation for reference:

```
TEMPLATE_FILE_NAME = "template.html"
def handler(event, context):
 with open(
 TEMPLATE_FILE_NAME,
 "r",
 encoding="utf-8") as f:
 instructions = f.read()
 return {"content": instructions}
```

When formatting your instructions, note that inline CSS is supported, but external CSS is not. HTML tags will inherit Cloudscape default styling. The maximum size for the instruction string is **250 KB**.

You can verify successful implementation when a "View" link appears in the module’s row on the UI after deployment. This feature enhances usability by providing context-specific documentation directly within the MCS interface, helping users better understand and use the module’s feature.