Utility Connectors Documentation
Next, I’m going to look at utility connectors. So as I explained earlier, these are connectors they use for internal use cases.
These add extra utility into a cycle and into Cyclr. That, by default may be a bit more difficult to manage. So as we go down this list, you’ll see that sort of some of them are named more conceptually, some of them are named basically as what they are so across, update and prevent them.
In this scenario, or in any use case, essentially, if you want to keep two systems in sync, what you need to be aware of, especially if one system or both systems are listening to an update is getting yourself caught in a loop. So one system updates itself, that information gets pushed to the next system, the next system is marked as updating itself. And that information would then get pushed back to the first system. And that can cause a lot of issues, you can end up making a lot of calls to the API, as it doesn’t specify what’s changed what is changing. And if it’s something new to the cross updating preventer.
In the scenario, you set it up so that it makes a check against what was last change between the systems. If it matches, and if it’s the same thing, then the template stops and you won’t get calls constantly going back and forth. If it’s something new, then that information is passed through to the second system. So from system a to system be the storage connectors so we have cycled base storage and object storage and then we have global data storage and if I just expand this here, we also have have global objects stored.
So these connectors work in a way, but for the data storage, it’s as simple as a key value pair. Now, the difference between cycle and global data storage will be one is accessible and tied entirely to the cycle that it is installed in. Or that that object is second. So let’s say I set a key value pair of name and ID in a cycle. If I tried that cycle data storage into another cycle, I wouldn’t be able to access those key value pairs. As far as Cyclr is concerned, those are in separate buckets. So it’s an isolated locations.
Now, if I had done that with global data storage, I would be able to pull that information that I set in cycle one, and use it in cycle to the object storage works much in the same way in terms of where you can access it. But the object storage is a bit more complicated, you can build up an entire JSON object within the object storage. And you can then use that either in another cycle or in the same cycle. After a tool like a wait or call, for example, you might have loads of separate information coming through and you want to build that up into one larger file one larger item.
And that’s where the object storage goes into play, especially if you know what the format of that information needs to be in for the JSON file or the JSON object. That’s where you’d use that Cyclr tools. So this is like a step on from our decision tool. And here, you can do things like regex, as well. So you can correct fields, you can validate data, you can even shorten or concatenate various fields using a cycle tool. And you can use regex, to make sure that everything is working fine, or everything appears as it should do.
The entity cross reference storage, if you have information in one system, and it’s tied to information in another system, and there’s something common between them, instead of having to make a call each time, you can use the cross reference storage to say item one in System A is the same as Item nine in system B. And it will match those based on either the name or if it’s people, it might do it based on the email. But it needs to be something fundamentally unique in both systems that appears in both and that way you can keep that information together. If it doesn’t appear at both, what you can also do is upload a CSV via a generic file, push that into the cross reference storage, if you have a CSV and you know what items title where, or if you have special codes that are expanded upon in your system, you can put that in the entity cross reference storage, and then when you are calling from System A, and you need the value for system B, you just make a call against the cross reference storage to get that item and get the correct object.
The generic file. So this is just for building out either CSV, a CSV, any type of basic file, essentially. So you can either build those out, or you can break those down and transform them into JSON so that it can be used further down the line.
Generic Form and Generic Webhook. So these are just generic calls, that generic form allows you to receive form data or push out form data.
Generic Webhook is an entire suite of essentially empty connectors or empty steps that allow you to make calls to a system. So that’s just the standard rest protocols, all of them in a different colour. And then you have webhook receivers and synchronous responses for those web hooks as well.
Now, I skipped over the arrow webhook. And that’s because that one’s a bit unique in that the error web hook listens internally for any errors that go on in a cycle now or in your account, actually.
Now, it could be the case that you want to push that information somewhere else. You need to be notified when there is an error. And that’s what the error webhook allows you to do that will say, look, there’s been an error in this cycle.
So what we need now is to pass this on to a Gmail account or a Slack channel just to notify someone that there’s been an error here, and they can come back and look at it. And the error webhook can be customised it has. They can listen to specific accounts, they can listen to specific cycles and it will just provide your transaction information or where the error has occurred.