# Exploring CyberArk (now Idira) Central Policy Manager's WSChains
If you have downloaded newer CPM plug-ins from the CyberArk (now Idira) Marketplace, you may have noticed that some deviate from the typical TPC or C#-based implementations and instead leverage a new WSChains DLL with an accompanying XML file. From the plug-in descriptions and the XML file content, WSChains is used when communicating with a REST API.
Scouring the CyberArk technical community and official documentation results in practically zero information about WSChains but studying the XML files of the Marketplace plug-ins utilizing it provides a fair amount of information about this extremely powerful and flexible plug-in type.
# First look at WSChains
Like the Secure Web App Framework, WSChains is declarative in nature. It consists of two files: an XML file and the WSChains DLL that acts on it and the contents within.
In the XML, there are four top elements:
* GlobalSettings
* Requests
* Fails
* Chains
![](https://cdn.hashnode.com/res/hashnode/image/upload/v1693337186551/40b587a9-9d66-44f4-99ed-7f268e1703c8.png align="center")
## GlobalSettings
Of the three plug-ins I looked at, only one had a child `GlobalSetting` elements in `GlobalSettings`.
In the [Cisco ISE Internal Users via API](https://cyberark-customers.force.com/mplace/s/#a352J0000003MQpQAM-a392J000002KqxrQAC) plug-in, the `GlobalSetting` element and the comment imply that the `Address` property of the account is used as the base URL for all the subsequently defined `Request` elements.
![](https://cdn.hashnode.com/res/hashnode/image/upload/v1693331980239/9f5fbbef-6f7e-48f9-aeb6-064505587e71.png align="center")
## Requests
The `Requests` section is made up of `RequestWrapper` child elements with each `RequestWrapper` element representing an API call that can be made as part of a later-defined chain.
Within each `RequestWrapper` there is a `Request` element where the relative URL, HTTP method, headers, and request body can be defined as child elements. Seemingly, the base URL and the relative URL are automatically concatenated to create the full URL.
Account properties -- including those of the linked logon and reconcile accounts -- are available to use inside the elements of the `Request` element.
![](https://cdn.hashnode.com/res/hashnode/image/upload/v1693332383760/aa201e1f-6211-4632-9372-066ce035fe22.png align="center")
The [Tenable.io - CPM](https://cyberark-customers.force.com/mplace/s/#a352J000000WUKqQAO-a392J0000013eWLQAY) plug-in shows that the body can contain JSON when inside a `json` element.
![](https://cdn.hashnode.com/res/hashnode/image/upload/v1693334512457/c22b6a37-dc74-47f1-91b0-d52241461b43.png align="center")
When the `HTTP POST` request sends form data and not `json`, the `Request` element can look like:
```xml
2
/authentication/users/{{username}}
POST
application/x-www-form-urlencoded
Basic {{username}}:{{pmpass}}
oldpassword={{pmpass}}&password={{pmnewpass}}
```
It is important to remember when sending multiple key-value paris in the `body` element, that the ampersand must be escaped as `&`!
## Fails
The `Fails` section is made up of one or more child `Fail` elements, which are similar to what you would find in a TPC-based plug-in's Process file.
![](https://cdn.hashnode.com/res/hashnode/image/upload/v1693332738718/1c8d2820-d78c-4c07-831b-d2772bed635e.png align="center")
## Chains
The `Chains` section is where it all comes together.
Each CPM operation has its own `Chain` element consisting of one or more child `Link` elements. Each `Link` element has `name` and `request` attributes, where the `request` attribute's value is the name of a `Request` element to be executed.
`Link` elements contain child `StatusCode` elements, each with a `value` attribute whose value corresponds to a HTTP status code and a `next` attribute's value that corresponds to the name of a `Fail` element or a sibling `Link` element in the same `Chain` to be executed when the HTTP status code is matched.
In the case that the value for `next` is `END`, similar to a Process file, the operation is considered to have been completed successfully.
![](https://cdn.hashnode.com/res/hashnode/image/upload/v1693335436466/e991657a-fdf0-4936-858c-037e640b8c2e.png align="center")
### StatusCode
The `StatusCode` elements are particularly interesting.
The content returned in a response's body can be parsed and stored as a variable to be used in `Request` elements, such as in the case where a session token must first be generated and used as part of subsequent requests.
![](https://cdn.hashnode.com/res/hashnode/image/upload/v1693335606201/d5d70579-8f0a-4546-9873-e32d73bd5763.png align="center")
![](https://cdn.hashnode.com/res/hashnode/image/upload/v1693335693321/60315a9a-df24-489f-a581-828f9c26b96c.png align="left")
In the case that the next `Link` depends not just on the HTTP status code returned but also on the content of a response's body, `StatusCode` elements can have child `Parse` elements that in turn have child `Equals` elements. The `Equals` elements have `next` attributes that operate the same as they do with `StatusCode` elements.
![](https://cdn.hashnode.com/res/hashnode/image/upload/v1693335976356/9491decc-c7d1-4591-a5df-2773eed07977.png align="center")
`Equals` elements are also powerful as the [Hitachi Administrator Link CS](https://cyberark-customers.force.com/mplace/s/#a35Ht000001VhyWIAS-a39Ht0000032Gw5IAE) plug-in shows that they can be used to query an asynchronous job's status.
```xml
```
# Wrap-up
With an understanding of CPM plug-ins and REST APIs, it is relatively easy to create your own WSChains-based plug-ins using existing plug-ins as references, even without official documentation. However, since it appears to be an internal-use-only framework for CyberArk, it is not suitable for use in a production setting.
Hopefully, CyberArk will choose to support WSChains in the same way they do TPC and the Web App Frameworks, and provide official documentation. WSChains is powerful in its current state and could potentially replace the need for C# or TPC-based plug-ins developed to interact with REST APIs.