VMware Cloud Community
TheVMinator
Expert
Expert
Jump to solution

Orchestrator and Plug-In development

I need orchestrator to talk to a number of third party systems for which no plug-in has been developed yet.  This is all part of a single Vm provisioning process.  Should I create a separate plug-in for each system for which no plug-in exists, or should I create one giant "Vm provisioning" plugin that can talk to multiple systems?

1 Solution

Accepted Solutions
iiliev
VMware Employee
VMware Employee
Jump to solution

It depends; both variants have pros and cons.

I'd go for one-plugin-per-system approach as it is more flexible (eg. if a new system appear in the future, you'll only need to write a plug-in for it and add it to the picture instead of updating the giant fits-them-all plug-in).

Also you may want to consider using the existing Dynamic Types plug-in. At the beginning, you could do a quick prototyping with it, and later, when you become more familiar/feel more comfortable with a given 3rd party system API, to implement a 'proper' plug-in for it.

View solution in original post

2 Replies
iiliev
VMware Employee
VMware Employee
Jump to solution

It depends; both variants have pros and cons.

I'd go for one-plugin-per-system approach as it is more flexible (eg. if a new system appear in the future, you'll only need to write a plug-in for it and add it to the picture instead of updating the giant fits-them-all plug-in).

Also you may want to consider using the existing Dynamic Types plug-in. At the beginning, you could do a quick prototyping with it, and later, when you become more familiar/feel more comfortable with a given 3rd party system API, to implement a 'proper' plug-in for it.

TheVMinator
Expert
Expert
Jump to solution

OK great thanks for the info.

0 Kudos