So, if you're here, you're wondering how this matters to you on the daily....
Currently, there are four --yes, four --teams working on API design, specifically targeting journal entries. There is also a project underway to integrate with an external iPaaS (Integration Platform as a Service) for integrations --integrations just like the example that was just covered. (Feel dumb to anyone else?)
NOTE: HubSpot has a nice little summation here.
Let's go back to the example for the email flow that we just created. Edit the flow and this time, choose to expand the step/trigger of When a new email arrives. From there, click the Advanced options link. In the expanded list, you see all of the potential filters and inputs.
If we had instead chosen an example using Outlook 365 or Outlook.com, we would have the following options, respectively.
Outlook 365:
Outlook.com:
So, they are all pretty similar in the options, which would be expected, as they are all the same type provider as far as functionality is concerned.
If you noticed the ellipses in the top right corner of each screen, you are able to access the following submenu:
From there, you can choose to Rename your step to something more specific --especially useful in the case that you have multiple steps of the same name. You can Add a comment for additional context, also. The potential option of most interest is Peek code. In the course of developing your own API, you may want to see what is being used "behind the scenes." It is always useful, as well, to view the details of an approach taken by an enterprise-level company as a model to follow or understand.
If I "peek" here, I will see the following:
Review the information provided here on your own. Take note of the parameters included, versioning, authentication, delineations in the data, etc. Again, this is clean, easy-to-read, and easily implemented.
Given all of that, step back, and let's return to our current world...
Abstract these concepts to apply to journal entries. Take a minute to get your head around it...
The product team is requesting an integration for journal entries. If you think of this automated and abstracted approach, while we will have login/credential information through a connection, that is not enough to retrieve journal entries.
NOTE: If you haven't been through my lecture on the differences in "authentication" versus "authorization," you're in for a treat that day. As always, Microsoft describes it better than I can, here.
The connection is an authentication to use our API. That is not the same thing as authorizing a user to see certain information at a company level. We can choose to implement our authentication to INCLUDE authorization, but that is something to be designed later. Regardless, especially in the case of an administrator, the connection alone is not going to be enough for context.
This is where, in the API design, we would have identified and then surfaced the solicitation of the information necessary to find those journal entries, as well as the dates to span.
In iterating, we could create a dummy API that returns the same information given, and be able to illustrate progress in a demo, allowing testing, connectivity, and value, while supporting the sprint/Scrum requirement of not having stories reliant on other stories within the same iteration.
This can also be tested in any environment and not violate compliance regulations by exposing production data in lower level systems.
Because of the nature of the integration, we are ensuring statelessness and allowing for scalability.
NOTE: If you have not yet realized, Power Automate is also an iPaaS.
FUN DAYDREAM/DIGRESSION: Imagine being on a shared screen during one of our "show and tell" meetings. Going to this website, and choosing Data, then Custom connector, Create custom connector, then Import OpenAPI from URL. Then you could go to create a new flow from scratch and add your connection. Log in, and say that you wanted to generate your journal entries and save them to your OneDrive. Add in your OneDrive connection, configure your login, and then just ask anyone what one they wanted. Voila. Done.
--Skipping ahead to on the next post, you could also walk through the Flow Checker and Test flow options.
If your mind is like mine, then you've already jumped forward to a solution for CJEs in the same way. If CS or a developer had a templated flow --not to be confused with "template" in the way that is currently described in the backlog --and just had to give it a different parameter and it automatically did them within 5 minutes, do you think anyone would complain? I certainly wouldn't. Plus, it can put the control of it, the testing, and the debugging into the hands of the business, CS, or even the client. They could figure out whatever pricing model they wanted. Ultimately, we could just throw the same endpoint into the existing code and be done.
Just like that... CJEs became fun to work on, and can be an opportunity to move the platform forward. --It also doesn't hurt that anyone working on them could add at least 4 things to their resumes (iPaaS, OpenAPI, systems design, cloud development, integrations, authentication, Power Automate, etc.).
--Christopher knows that I can tie a revenue percentage to that work as well in ROI, which also looks great on a resume.
This is why Microsoft is moving to the citizen developer model.
For even more opportunities in Power Automate, there are monitoring options, analysis on the data, building AI models, and end-to-end solution templates.
But first, we need to get everyone THINKING this way. If we don't, we'll continue doing bug fixing and maintenance work.
Comments