Shell Adapter

Need some help? Contact us:

The SHELL adapter library is just intended to something you copy and rename and make it into a real adapter for a real system. It has all the boiler plate you need. I made it because I wanted to try to build a few adapters to Solve the calendar management problem.

I took the Slack Notifier Adapter and hollowed it out to make this empty adapter. Should help me write a few adapters fast (remove bottlenecks )

The shell adapter ships with Iguana just add the Shell Example - see Create a Component .

Let’s use the Shell Adapter to create an Atlassian adapter using the Atlassian APIs:

In IguanaX, an open system, we provide adapters as libraries to connect with various applications. These adapters are intentionally designed to be simple and intuitive, making them easily extendable by users to meet their specific needs. This approach contrasts with the complexity often found in open-source projects and the rigidness of complete platforms like Zapier. Iguana's inclusive environment, featuring a Translator, logging, queuing system, and dashboard, though convenient, requires users to invest effort in learning. Our goal is to empower users with adaptable tools, understanding that no adapter can be universally complete.

See:

and

The component aims to showcase the library's use, easing the learning process for users to integrate with systems efficiently. It's crafted to enable customers to quickly start without delving deep into documentation or seeking iNTERFACEWARE staff help. Therefore, it doesn't cover every detail of the problem but rather provides a clear direction, setting customers on their own path of exploration and discovery.

These parameters should not be hard coded into things like custom fields. This is because our customers may use these adapter libraries in components with others.

For each adapter, we create a custom method to avoid the need for a lot of copy-pasted code. This method contains all the essential code for connecting to a web API, eliminating the repetition of the same code for different API methods. We have one main custom method, with other specific APIs serving as wrappers around it. If we need to access an API method for which we haven't created a specific wrapper, we can simply call this custom method, specify the API path, and provide any necessary parameters. This approach makes using new API methods straightforward and minimizes the need for additional setup.

Each specific call does not typically have much code because most of the 'boilerplate' code is in the custom method, and it's nice that each of these methods has help. Doing things this way should make it quite clear to a user how they can extend each adapter.

See

Implementation Approach: