Automate Google News Digests with n8n: Free Workflow for Gmail Approvals

Business automation is an essential part of modern businesses, and it does not have to be hard!

Several automation tools exist, such as Zapier, Make, n8n that allow automations between systems, services, databases, you name it!

I recently created and published a n8n workflow to deliver Google News to your Gmail inbox.
This template serves business leaders and marketers and anyone who wants to track industry developments without wasting their weekly time on endless feed browsing.

 

Overview

The workflow fetches daily GoogleNews digest based on your selected topics, before sending them to your Gmail inbox for verification, allowing you to select appropriate stories to share.

NOTE: The workflow operates through community nodes which function exclusively on n8n self-hosted platforms.

If you want to know how to easily run a self-hosted n8n instance it on your infrastructure, I will be happy to help you in a free call.

 

Why this matters

The fast pace of news development creates challenges for executives and content teams who need to maintain strategic focus while handling client work and operational responsibilities. The workflow simplifies this process. The system delivers AI-generated news summaries which are ready for immediate use in social media content and newsletter creation and blog post publication.

The system functions as a research assistant which removes unnecessary information from news articles before presenting you with a simplified summary for easy approval or next batch retrieval.

 

How it works

⏰ Set your schedule – Decide when the digest lands in your inbox (daily, weekly, or custom).

🔎 Curate your focus – Define your topic or keyword, and the workflow fetches trending Google News stories.

🤖 AI formatting – Articles are polished into professional HTML for easy reading.

📧 Inbox delivery – A curated digest arrives directly in your Gmail, ready for review.

❌ Decline & refine – If it’s not what you need, decline it and the workflow automatically fetches the next batch of curated stories.

 

Tools used

The following accounts are required to configure the workflow:

• AirTable

• Gmail

• SerpApi

• OpenAI

 

Customization options

The workflow can be customized to tailor operations according to your business requirements.

• You can modify the schedule to match your content distribution frequency.

• You can specify different keywords to obtain the right information.

• You can modify the number of articles in each batch (default is 10) to match your review preferences.

• You can personalize the approval email design to match your company branding elements.

 

Final thoughts

The n8n workflow enables content pipeline managers to eliminate the process of news collection and preparation. The system enables you to make important decisions about content distribution to your audience while eliminating time spent on news collection and formatting.

 

You can download the template for free here and run it on your n8n instance.

 

Book a call to learn more about n8n automation workflows and tools.

 

Learn more about n8n:

massimobensi.com

Frequently Asked Questions (FAQ)

Q: What is the workflow described in this post?

A: The article explains how to use n8n (a self-hosted automation tool) to set up an automated process that fetches daily digests from Google News based on your selected topics or keywords, formats the results (including AI-summaries) and then sends them to your Gmail inbox for approval or publication.

Q: Who can benefit from using this Google News digest workflow?

A: Content managers, marketing teams, business executives, bloggers or anyone who wants to stay on top of news in their industry without manually scanning dozens of feeds can benefit. The workflow works as a research assistant that reduces noise, delivers curated summaries and saves time.

Q: What tools or services are required to implement this workflow?

A: According to the blog post, you’ll need accounts or APIs from:

• Airtable (for metadata/storage)

• Gmail (for email delivery/approval)

• SerpApi (to pull Google News data)

• OpenAI (for summarising or polishing the content)

Q: Does this workflow work on a cloud instance of n8n or only self-hosted?

A: You’ll need a self-hosted n8n instance (not just the cloud-hosted one) in order to run it properly.

Q: How customizable is the workflow?

A: Quite customizable. You can:

• Define when the digest is sent (daily, weekly or custom schedule)

• Pick your keywords/topics for the news fetch

• Set how many articles are included in each batch (default is 10)

• Edit the approval email design (branding, layout, etc)

Q: How does the approval process work?

A: Once the articles are fetched and summarised, the digest is delivered to your Gmail inbox. You review the set of stories and can approve or reject them. If you reject the batch, the workflow automatically fetches the next set of curated stories so you get more usable content.

Q: What are the main benefits of automating Google News digests with n8n?

A: Key benefits include:

• Saving time on manual news-monitoring and feed browsing

• Getting ready-to-use summaries (AI-powered) instead of raw articles

• Maintaining content flow for newsletters, blogs, social posts without constant manual effort

• Ensuring you stay updated on industry developments without being overwhelmed

Q: Are there any prerequisites or things to check before starting?

A: Yes. You’ll want to ensure you have:

• A working self-hosted n8n instance up and running

• Access/credentials to the required services (Airtable, Gmail, SerpApi, OpenAI)

• Defined topics/keywords you want to monitor

• Some understanding of how to customise n8n workflows (adding nodes, modifying schedule, branding email)

Q: How can I get the workflow template?

A: You can download the free workflow template from n8n’s template library.

Q: Is this solution suitable for large enterprises or just small teams?

A: While the workflow is accessible and useful for individuals and small teams, the principles scale: you can define multiple keyword clusters, send digests to different teams, integrate further downstream automation (e.g., publish to CMS, schedule social posts). The blog suggests it is relevant for business leaders and marketers tracking industry development. (Massimo Bensi)

Q: How does using AI summarisation contribute in this workflow?

A: The workflow uses an AI (via OpenAI) to polish or summarise fetched news articles into professional HTML summaries that are easier to read and review. This means you skip the “raw article” step and get content that’s near ready for sharing or repurposing. (Massimo Bensi)

RAG Guardrails: Securing Enterprise AI Conversations

When we talk about Retrieval-Augmented Generation (RAG), we usually focus on accuracy: pulling the right documents, grounding responses, and ensuring users get reliable answers. But in enterprise settings, accuracy is only half the story. Guardrails—the policies and mechanisms that govern how AI systems handle inputs and outputs—are what make the difference between a safe, private system and a liability.

If you’ve ever chatted with an AI that refuses to give you certain answers, or rephrases toxic language, you’ve seen guardrails in action. In enterprise RAG, these guardrails aren’t just nice-to-haves—they’re essential for data privacy, compliance, and confidentiality.

In my previous post, Enterprise RAG: Turning Company Knowledge into an AI Assistant, I described how enterprises can safely expose their knowledge base through RAG. Guardrails are the next step: they ensure the AI assistant never leaks sensitive information, avoids compliance violations, and stays aligned with organizational values.

Why Guardrails Matter in RAG

Imagine a finance company using RAG to answer client queries. Without guardrails, the model might:

• Reveal sensitive competitor insights.

• Mis-handle confidential HR or legal documents.

• Produce toxic or inappropriate responses.

A single leak could be catastrophic. Guardrails enforce rules and boundaries to prevent such failures.

At their core, guardrails act as filters and validators:

1. Input guardrails – check what the user is asking, blocking unsafe prompts (e.g., phishing attempts).

2. Output guardrails – validate what the AI produces, ensuring it doesn’t contain banned terms, PII, or confidential info.

3. Flow guardrails – enforce conversational policies (e.g., redirecting instead of refusing outright).

Types of Guardrails (and Their Purpose)

1. Content Safety – prevent toxic, biased, or offensive language.

2. Confidentiality & Compliance – detect mentions of competitors, trade secrets, or personal data.

3. Factuality & Accuracy – validate responses against retrieved knowledge before sending them to users.

4. Policy Alignment – ensure outputs comply with corporate governance, ethics, and industry regulations.

For example, in healthcare RAG, HIPAA guardrails could automatically block outputs that contain unredacted patient identifiers.

Implementing Guardrails with Code

Several libraries make this straightforward, and Guardrails AI is a strong choice for Python developers. It provides reusable validators and lets you compose multiple guardrails together. Here’s a simple Python example:

from guardrails import Guard, OnFailAction
from guardrails.hub import CompetitorCheck, ToxicLanguage

guard = Guard().use_many(
    CompetitorCheck(["Apple", "Microsoft", "Google"], on_fail=OnFailAction.EXCEPTION),
    ToxicLanguage(threshold=0.5, validation_method="sentence", on_fail=OnFailAction.EXCEPTION)
)

guard.validate(
    """An apple a day keeps a doctor away.
    This is good advice for keeping your health."""
)  # Both the guardrails pass

try:
    guard.validate(
        """Shut the hell up! Apple just released a new iPhone."""
    )  # Both the guardrails fail
except Exception as e:
    print(e)

In this snippet:

• CompetitorCheck prevents the model from mentioning competitors.

• ToxicLanguage filters out offensive responses.
  Both guardrails throw exceptions if violated, keeping your AI assistant compliant.

Running Your Own Guardrail Server

For enterprises, integrating guardrails as a self-hosted service is a game changer. Instead of relying on third-party APIs (where sensitive data might leave your infrastructure), you can:

• Run guardrails on-premises or inside your private cloud.

• Fully control logs, monitoring, and policy updates.

• Tailor guardrails to your domain (finance, healthcare, legal).

This not only boosts security and privacy, but also aligns with strict compliance requirements (GDPR, HIPAA, SOC 2).

Diagram: Guardrails in the RAG Pipeline

Conclusion

Enterprise RAG unlocks enormous value by letting companies query their own data safely. But without guardrails, the risks outweigh the rewards. By adopting frameworks like Guardrails AI and even hosting your own guardrail server, organizations can maximize security, ensure compliance, and maintain user trust.

In short: RAG without guardrails is like driving a race car without brakes. Guardrails make Enterprise RAG safe, responsible, and enterprise-ready.

Ready to explore how Guardrails can secure your business AI conversations? 

Book a 15-minute call here

Watch a comprehensive video about AI Guardrails:

massimobensi.com

Frequently Asked Questions (FAQ)

Q: What does “RAG guardrails” mean in the context of enterprise AI?

A: In this context, “RAG” stands for Retrieval Augmented Generation — a technique where an AI model retrieves relevant documents or data chunks from a knowledge base, then uses them to generate responses. “Guardrails” refer to the safeguards (technical, policy, governance) that ensure the AI system behaves safely, complies with regulations, protects sensitive data, and avoids undesired or harmful outputs.

Q: Why are guardrails important for RAG systems in enterprise conversation settings?

A: Because enterprise conversational systems typically handle sensitive internal knowledge, regulatory-compliance information, and personal data. Without guardrails, the retrieval step may expose or misuse sensitive content and the generation step may “hallucinate” or produce incorrect or non-compliant replies. The blog post emphasises the risk of data leakage, policy violation and unmanaged AI behaviour when using RAG at scale.

Q: What are common types of guardrails needed for secure enterprise RAG?

A: According to best-practice sources, guardrails include:

• Data ingestion controls: sanitising sources, redacting PII before indexing. 
• Retrieval access controls: role-based access, metadata filtering, audit trails.
• Prompt and output constraints: validating inputs, schema checks for outputs, fallback systems.
• Monitoring, observability and feedback: tracking system use, measuring KPIs (e.g., accuracy, speed, policy violations), continuous improvement.

Q: What business risks arise from using RAG without proper guardrails?

A: Using RAG without proper safeguards can result in:

• Sensitive information being retrieved or exposed to unauthorised users.
• Regulatory non-compliance (e.g., GDPR, HIPAA), due to mishandled data or auditability gaps.
• Loss of trust from users or customers if the AI returns inaccurate or biased responses.
• Compromised system integrity and skyrocketing maintenance or failure costs due to technical debt.

Q: How can an organisation start implementing RAG guardrails effectively?

A: The blog suggests a step-by-step approach:

1. Map out data sources and categorize sensitivity levels (PII, regulated data, proprietary).
2. Build an ingestion pipeline that cleans, classifies, chunks and embeds documents securely.
3. Implement retrieval with access control, filtering and metadata tagging.
4. Define generation workflows with constraints, fallbacks, citations, and “I don’t know” responses when confidence is low.
5. Establish monitoring and feedback loops with KPI tracking (accuracy, latency, policy violations, user satisfaction).
6. Continuously iterate guardrails and governance as the system scales.

Q: Are there particular technical architectures for secure enterprise RAG?

A: Yes. It is common to use a layered architecture: ingest → index → retrieve → generate → monitor. For example, you might incorporate vector + keyword search hybrid retrieval, model gateways, safety filters, and audit logs.

Q: Can guardrails impact system performance or user experience?

A: Potentially yes, if implemented rigidly. However, the blog explains that well-designed guardrails can be largely invisible to users while protecting system integrity. For example, fallback responses or filtered retrieval can add minimal latency, but the trade-off is stronger compliance and reliability.

Q: How does this blog post help business leaders or non-technical stakeholders?

A: It frames the topic in terms of business value and risk: why conversational AI matters for operations, how uncontrolled RAG can introduce liability, and how guardrails become a competitive advantage (via trust, compliance and speed). So decision-makers can better assess investments and governance around conversational AI.

MCP: Unlocking Business Value with the Model Context Protocol

Artificial intelligence keeps advancing at a rapid pace yet most business leaders agree that AI systems function independently while being inflexible and cost-prohibitive to integrate within operational workflows. The Model Context Protocol (MCP) presents itself as a developing open standard which addresses this problem.

MCP operates as an essential translation system which enables AI models to exchange information with the tools and data and workflow systems organizations currently use. Through its standard interface MCP enables models to communicate uniformly with enterprise systems thus eliminating the need for unique connectors and customized integrations.

Why MCP Matters for Business Leaders

Executives require only the business outcomes of MCP instead of technical implementation details under the hood.

1. Faster Integration - The process of integrating AI pilots into company operations currently requires extensive time periods and substantial financial investments from businesses. The Model Context Protocol establishes a standardized method for AI models to establish connections with APIs and databases as well as applications. Organizations save time by skipping repetitive development work so they can focus on delivering valuable outcomes.
2. Vendor Flexibility - AI continues to experience rapid transformations in its development. Every executive avoids being confined to using only one vendor's products. MCP enables different models from OpenAI and Anthropic along with in-house teams to interface with the same infrastructure framework. Your organization gains better negotiating power and greater flexibility while also building stronger resistance capabilities.
3. Scalable Governance - Business organizations express valid concerns about maintaining compliance and managing risk. The standardization process of MCP simplifies AI system monitoring functions and access control capabilities. The standard interaction protocol enables IT teams along with compliance staff to establish oversight and safety measures that protect innovation.
4. Future-Proofing - Standards tend to win. Enterprise AI will likely depend on MCP as the fundamental protocol which unites all its components in the same way TCP/IP connects the internet and APIs link digital services. Companies which adopt early position themselves to achieve faster progress when the ecosystem develops.

A Practical Example

A financial services organization wants to use artificial intelligence for delivering client assistance. Each AI tool requires a custom-built bridge to connect with CRM data and transaction records and compliance filters when MCP is absent. The process of deployment becomes slower while additional maintenance expenses continue to arise.

The standardized exposure of resources becomes possible through MCP. All authorized models can execute CRM queries and compliance assessments and modify client information through this standardized communication protocol. The result: faster rollouts, lower integration costs, and tighter governance.

The Strategic Opportunity

Executives should focus on the question of how MCP will help them achieve their goals rather than what exactly MCP represents.

• Accelerate digital transformation: the implementation of digital transformation becomes easier when organizations reduce obstacles to AI operational adoption.
• Unlock new products: standardized access enables organizations to create and release AI-based products through simplified experimentation and deployment.
• Protect investments: Avoid costly rewrites as models and vendors evolve.
• Empower teams: Let technical and non-technical staff use AI tools that safely connect to enterprise systems.

MCP enables artificial intelligence to transition from isolated experimental phases to widespread enterprise-level usage.

What Leaders Should Do Now

Check with your organization if they possess MCP readiness capabilities. IT and innovation teams should monitor the MCP standard even though its adoption remains at an early stage.

Evaluate integration-heavy use cases. Customer service operations and knowledge management systems alongside compliance protocols show promise for rapid implementation.

Engage vendors on MCP. Request from your vendors that they support open standards to prevent you from becoming restricted to their products.

Plan for governance. Use MCP as a chance to set enterprise-wide rules for AI access and compliance.

Final Word

Every transformative technology wave—from the internet to cloud computing—was accelerated by common standards. MCP could be the same for AI. Executives who take proactive steps at present will be able to gain efficiency and adaptability along with resilience in the future.

The organizations which succeed will not pursue every new AI model but develop standards for fast adaptation. MCP stands as one of these essential standards.

Ready to see how MCP can improve your business? 

Book a 15-minute call here

Watch a simple video about MCP:

massimobensi.com

Frequently Asked Questions (FAQ)

Q: What is the Model Context Protocol (MCP)?

A: MCP is an open standard and protocol designed to let AI systems (especially large-language-model agents) connect in a standardized way to external data sources, tools, and services. 
It enables more modular, interoperable, and scalable AI architectures. 

Q: Why should businesses care about MCP?

A: Because many AI initiatives stall not due to model capability but due to poor integration, missing context or fragmented data. MCP addresses these issues by standardizing how context (data, tools, business logic) is supplied to AI agents. 
This means faster deployment, lower integration cost, and better reuse of AI across business units.

Q: What business-value benefits does MCP bring?

A: Key benefits include:

• Integration Efficiency: Converts the “M×N problem” of integrating M AI agents to N data sources into a simpler “M + N” scenario via standardization. 
• Reuse & Adaptability: Context frameworks become portable across models and use-cases, reducing duplication. 
• Operational Readiness: Agents can act on live data and tools rather than just static knowledge; this enables automation, decision-making, and action workflows. 
• Future-proofing: As AI environments evolve, a standardized protocol like MCP helps avoid being locked into custom integrations or monolithic systems. 

Q: How does MCP differ from popular AI techniques like RAG (Retrieval-Augmented Generation)?

A: While RAG focuses on retrieving knowledge (documents, context) and then using it in generation, MCP goes further by allowing agents to connect to live data sources and tools, not just static retrieval. In other words: RAG is about “what the model knows”, MCP is about “what the model can do (and access)”. 

Q: What kinds of use-cases are enabled by MCP in a business environment?

A: Some examples include:

• An AI agent that accesses real-time inventory, executes logistics updates, and triggers supplier orders. 
• A service bot that pulls live CRM data, uses a tool to update a record, and then responds to a client. 
• In healthcare: an assistant that queries internal records, applies logic via a tool, and produces actionable clinician advice (while respecting compliance). 

Q: What are the key architectural/prerequisite considerations when adopting MCP?

A: Key considerations include:

• Defining the tools, resources, and prompts as per the protocol (i.e., what the agent can call, what data it can access, and how those interactions are framed). 
• Ensuring proper access control, security, and governance around what the AI can access and do. 
• Starting with a pilot use-case, then scaling out to multiple sources and agents once the architecture is validated. 
• Considering the change management and organisational alignment: teams must think of context not just for one model but for a reusable protocol across models. 

Q: Are there trade-offs or limitations to using MCP?

A: Yes — while MCP provides many advantages, some trade-offs include:

• It requires discipline: defining the tools/resources/prompts in a reusable way takes effort and design.
• It may introduce initial architectural complexity (building MCP servers, integrating them securely with live systems).
• Not all systems or legacy tools may yet have ready-made MCP server implementations; custom connectors may still be required.
• Ensuring that context remains current, correct and secure is still an operational challenge. For example the ecosystem might still be evolving. 

Q: How should business leaders or non-technical stakeholders approach MCP adoption?

A: Business leaders should focus less on “which model” and more on “which contexts and tools” the model needs to deliver business value. They should ask:

• What live systems or data must the agent access to deliver value?
• What actions must the agent perform (e.g., update records, trigger workflows)?
• What governance/permissions must be enforced?
• How will we measure success (time-to-value, reuse, cost saved)?

Starting with a focused high-impact use-case and building a roadmap from there is advised.

Enterprise RAG: Turning Company Knowledge into a Strategic Advantage

Modern executives encounter a standard business problem because their organizations maintain vast amounts of data that employees and customers find difficult to obtain at the right time. Search tools are clunky, documents live in silos, and critical knowledge often gets buried.

Enterprise Retrieval-Augmented Generation (RAG) represents the solution to this problem.

Business organizations consider this AI architecture among the most vital because it revolutionizes their ability to access and utilize corporate knowledge.

What is RAG?

The RAG system unites two advanced technologies through its operations:

• Large Language Models (LLMs) including GPT demonstrate exceptional skills for processing and creating natural language content.
• Enterprise data retrieval functions as a system that retrieves information from authorized company sources.

RAG systems retrieve the most suitable documents from your organization before the model generates an answer. The system generates answers based on your company data so they remain accurate while maintaining security and traceability.

Why It Matters for Business

The implementation of RAG technology provides organizations with productivity enhancement alongside competitive advantage. Businesses that implement this solution achieve several advantages.

• Faster decision-making –Employees can use plain English to ask questions that produce direct source-backed answers in seconds.
• Stronger customer experiences –The delivery of precise responses from support teams and chatbots leads to improved customer satisfaction and enhanced customer loyalty.
• Lower risk – By keeping sensitive data inside company boundaries and enforcing access controls, RAG strengthens compliance and security.
• Scalable knowledge management –The system allows companies to manage knowledge at scale since new documents and products automatically become accessible without requiring model retraining.

RAG transforms excessive information into business benefits which create competitive advantages.

So Why Enterprise RAG

There is only one drawback with standard RAG implementations: your company data (private, sensitive, confidential, or even IP), is shared with major AI companies (such as Open AI, Anthropic, Google).

That's where Enterprise RAG comes into place, by providing several layers of Security and Reliability, necessary for a healthy and safe business.

The system operates with reduced risk through its capability to maintain sensitive data within company boundaries while implementing access control mechanisms for security.

Enterprises Need to Master Several Key Factors

Large-scale RAG deployment requires more than simple switch activation to achieve success. Successful companies pay attention to:

1. Data readiness – Cleaning, organizing, and updating content so AI retrieves the right information.
2. Performance – Optimizing speed and cost so RAG-powered tools can serve thousands of employees or customers in real time.
3. Governance – Applying strict security and compliance controls so only the right people see the right information.
4. Measurement – Tracking accuracy, user trust, and adoption to ensure real business value.

Where It’s Going

The field of Enterprise RAG continues to advance at a rapid pace. The next evolution of Enterprise RAG will include:

• Assistants that can read across multiple sources and draft reports or policies.
• Integration with structured data, like finance or supply chain systems, alongside unstructured text.
• Multi-modal capabilities, handling not just documents but also images, charts, and voice.
• Workflow automation, where AI doesn’t just provide insights but also takes action.

The Executive Takeaway

Enterprise RAG serves as more than a standard IT project. It’s a way to:

• Empower employees with instant access to knowledge.
• Deliver superior customer service.
• Strengthen compliance and reduce risk.
• Build a future-ready knowledge infrastructure.

Organizations that adopt RAG today will shape the highly competitive environment of tomorrow.

Ready to explore how Enterprise RAG can transform your business? 

Book a 30-minute strategy call here

Watch a comprehensive video about Enterprise RAG:

massimobensi.com

Frequently Asked Questions (FAQ)

Q: What is Retrieval Augmented Generation (RAG) in an enterprise context?

A: RAG is a technique that combines retrieval of relevant documents or data from enterprise knowledge sources with generation by large-language models (LLMs). It enables responses grounded in specific company data rather than relying solely on generic training. 

Q: How can enterprise RAG turn company knowledge into a competitive advantage?

A: By enabling employees, agents or systems to access tailored and up-to-date company-specific information (e.g., internal docs, customer records, policies) on demand, RAG supports faster decisions, fewer errors, improved productivity and better customer experiences.

Q: What kinds of business use-cases does enterprise RAG support?

A: Use-cases include:

• Internal knowledge search (e.g., “Where is the current pricing policy?”)
• Customer support automation (retrieving relevant FAQs or docs)
• Sales enablement (pulling case studies or product specs on the fly)
• Decision support (summarising internal reports for executives)

Q: What are the key architectural components of an enterprise RAG system?

A: Important components include:

• Data ingestion/Indexing of internal content into searchable form (e.g. vector embeddings)
• Retrieval engine that fetches relevant context for a query
• Generation module (LLM) that uses the retrieved context to produce an answer
• Security & governance mechanisms: access control, audit logging, compliance filtering

Q: What are the major challenges when adopting enterprise RAG?

A: Challenges include:

• Ensuring the internal data is cleaned, current, and structured for retrieval
• Managing permissions and governance so that sensitive data is not exposed inappropriately
• Avoiding hallucinations or incorrect outputs even when using retrieval-augmented context
• Scaling retrieval as the company’s data grows

Q: How does enterprise RAG differ from a standard search or chatbot?

A: Traditional search returns links or documents. A simple chatbot may generate responses based on training data. Enterprise RAG goes further: it retrieves context and uses it to generate a tailored response, making the result more accurate, context-aware, and specific to the organisation’s knowledge. 

Q: What metrics should organisations monitor to measure the success of an enterprise RAG rollout?

A: Metrics may include:

• Reduction in time employees spend searching for information
• Accuracy or user satisfaction of generated responses
• Number of users or departments adopting the system
• Frequency of incorrect or non-compliant outputs (errors/hallucinations)
• Security/compliance incidents related to knowledge retrieval

The blog post suggests monitoring both usage and reduction in friction as indicators of value.

Q: When should a business consider implementing enterprise RAG?

A: A business should consider enterprise RAG when:

• It has significant internal knowledge assets (documents, knowledge bases, case histories)
• Teams struggle with finding accurate internal information quickly
• Customer or employee self-service or productivity is being hampered by information silos
• The business seeks to scale knowledge access without continually retraining models

Q: Is enterprise RAG suitable only for large enterprises, or can smaller companies benefit too?

A: While large enterprises with vast knowledge bases may see the greatest benefit, smaller companies can also benefit — especially if they have complex internal documentation, customer databases or wish to empower employees with better information access. The key factor is whether there’s underlying knowledge to retrieve and use.

Automate Azure API Management: Backup and Restore

Once you setup the service in Azure and add all your APIs, you should make sure you have a good Backup strategy in place, in case things go wrong.

If you do regularly backup the service, then you can also use those backups for a couple of purposes:

you can for example deploy more than one instance and put a Traffic Manager in front of them, in order to handle geographical distribution.

But you can also restore a specific backup to a different Subscription, and create a separate environment, as per the DTAP street.

Azure API Management provides a REST API that you can use to automate things; unfortunately that works for most features and activities, but not for backing up and restoring the whole service.

For this you need to use the good "old" ARM, which also provides a REST API with specififc API Management operations.

By reading the article above, you might think that this is as easy as getting a token, backing up and restoring the service...

Well, not if you want an idempotent process; in such case, you are on the right post, so just keep reading.

Backing up the service is quite straightforward, as long as you have a good Retry strategy (I suggest Polly); in fact, since some API Management operations can take several minutes (see up to 45 minutes...), once you send a request to backup your service, you get a 202 Accepted HTTP Response, with a Location URL, that you can use to regularly check for the backup operation to be completed.

The same is true for restoring, as well as creating the service in the first place (and keep in mind that you need the service instance to be restored to to exist before you start restoring).

And what if something goes wrong while you wait for completion? Most likely you will lose the Locaion URL, making it harder to know when the process is done (unless manually checking the Azure Portal, which defies the automation).

So in a true DevOps manner, in the diagram here is the fully automated process for backing up and restoring an API Management service.

As you can see in the above picture, there are several steps just to make sure things won't break in different scenarios.

There is also an Azure Storage Table used for auditing (or saving the backup and restore status each time).

So here is the pseudo-code for the Backup operation:

ExecuteRestRequestReturnLocation()
AddBackupEntryToStorageTable()
CheckForOperationCompletion()
UpdateBackupEntryToStorageTable()


Where the most interesting part is the CheckForOperationCompletion(), using Polly and a RetryPolicy, as shown below here:

private async void CheckForOperationCompletion(string locationUrl, string token)
        {
            try
            {
                HttpStatusCode[] httpStatusCodesWorthRetrying = {
                   HttpStatusCode.Accepted, // 202
                };

                var policy = Policy
                  .HandleResult<HttpResponseMessage>(r => httpStatusCodesWorthRetrying.Contains(r.StatusCode))
                  .WaitAndRetryForeverAsync(retryAttempt => TimeSpan.FromMinutes(Math.Pow(_retryAfterMinutes, retryAttempt)));

                HttpResponseMessage result = null;
                result = await RestHelper.ExecuteRestRequestRetryResponseMessage(locationUrl, "Bearer", token, new RetryPolicy<HttpResponseMessage>[] { policy });
                if (result.StatusCode != HttpStatusCode.OK)
                {
                    Log.Error("Exiting CheckForOperationCompletion because of StatusCode: {StatusCode}", result.StatusCode);
                }
            }
            catch (Exception ex)
            {
                Log.Error(ex.Message + " " + ex.StackTrace);
            }
        }

Now, that was quite straightforward..

The Restore part itself is nearly identical to the Backup pseudo-code above, however, when put in the bigger picture of fully restoring an existing API Management backup, there is a bigger logic involved (as you can already see in the diagram above).

private static bool CreateNewApimService(string svcName, string destinationSubscriptionId, string destinationResourceGroupName, string appName)
        {
            //TODO: make async!!
            //1) check if svc already exists
            if (!armClient.VerifyApimServiceExists(svcName).Result)
            {
                //2) if not, check name availability
                if (armClient.CheckApimServiceNameAvailability(svcName, destinationSubscriptionId).Result)
                {
                    //3) then create svc
                    if (!armClient.CreateApimService(svcName, destinationSubscriptionId, destinationResourceGroupName, "West Europe", "Developer").Result)
                    {
                        Log.Error("The Service {0} was not created, something went wrong.", svcName);
                        return false;
                    }
                    
                    //4) Create App Registration (DevPortal) - AzureGraphClient
                    var res = azGraphClient.CreateAppRegistration("new-aad-app-registration", appName, serviceName).Result; 
                    if (String.IsNullOrEmpty(res) || res.StartsWith("Error"))
                    {
                        Log.Error("Cannot create App Registration for {0}", svcName);
                    }
                    else
                    {
                        var appId = res;
                        Log.Information($"API Management service {svcName} was succesfully created along with its AAD App Registration (AppId {appId}).");
                        Log.Information($"The App Registration needs to be authorized before it can be used. An Admin needs to Grant Permissions to it from the Azure portal.");
                    }
                }
                else
                {
                    Log.Error("The name {0} is not available for API Management.", svcName);
                    return false;
                }
            }
            return true;
        }

As you can see there is quite some logic involved when creating a new API Management service programmatically, such as:

1) Check if the service exists already,
2) Check service name availability,
3) Create APIM service,
4) Create App Registration for the APIM Developer Portal...

In particular, here I use Polly to retry after the API Management service creation, which unlike the Backup and Restore operations (where you get a 202 - Accepted until a 200 - OK), it always returns 200 - OK, and in the Response Content Body it contains a JSON field called provisioningState, which will be initially "Created", and only after several minutes (up to 45...) it will become "Succeeded".


Inside the CreateApimService method there is the Polly Retry Policy:

public async Task<bool> CheckForCreationCompletion(string url)
        {
            var response = await WaitForCreationCompletion(() => RestHelper.ExecuteRestRequest(url, "Bearer", _accessToken, HttpMethod.Get, ""));
            if (!response)
            {
                Log.Error("CheckForCreationCompletion failed");
            }
            return response;
        }

        private Task<bool> WaitForCreationCompletion(Func<Task<HttpResponseMessage>> requester)
        {
            var policy = Policy
                    .HandleResult<bool>(false)
                    .WaitAndRetryForeverAsync(retryAttempt => TimeSpan.FromMinutes(Math.Pow(_retryAfterMinutes, retryAttempt)));

            //var retryPolicy = new RetryPolicy<HttpResponseMessage>[] { policy };
            //you can subscribe to the RetryPolicy.Retrying event here to be notified 
            //of retry attempts (e.g. for logging purposes)
            return policy.ExecuteAsync(async () =>
            {
                HttpResponseMessage response;
                try
                {
                    response = await requester().ConfigureAwait(false);
                }
                catch (TaskCanceledException e) //HttpClient throws this on timeout
                {
                    //we need to convert it to a different exception
                    //otherwise ExecuteAsync will think we requested cancellation
                    throw new HttpRequestException("Request timed out", e);
                }
                //assuming you treat an unsuccessful status code as an error
                //otherwise just return the respone here
                return response.CheckForSucceededState();
            });
        }

And to check for the custom message returned, I use a C# Extension:

public static bool CheckForSucceededState(this HttpResponseMessage r)
        {
            if (r == null || !r.IsSuccessStatusCode) return false;
            var readResult = r.Content.ReadAsStringAsync().Result;
            JObject o = JObject.Parse(readResult);
            var provisioningState = (string)o["properties"]["provisioningState"]; //Created, Succeeded
            var targetProvisioningState = (string)o["properties"]["targetProvisioningState"]; //Activating
            return provisioningState == "Succeeded";
        }

And this is the ResilientHttpClient used for the regular Polly Retry in the CheckForOperationCompletion:

public class ResilientHttpClient<T> : HttpClient where T : class
    {
        private HttpClient _client;
        private RetryPolicy<T> _policy;

        public ResilientHttpClient(RetryPolicy<T>[] policies) 
        {
            _policy = policies[0];
            _client = new HttpClient();            
        }

        private Task<T> HttpInvoker(Func<Task<T>> action)
        {
            return _policy.ExecuteAsync(() => action());
        }

        public Task<T> SendAsync(string uri,
            HttpMethod method,
            string authorizationToken = null,
            string authorizationMethod = "Bearer")
        {
            return HttpInvoker(async () =>
            {
                var requestMessage = new HttpRequestMessage(method, uri);
                requestMessage.Headers.Authorization = new AuthenticationHeaderValue(authorizationMethod, authorizationToken);
                var response = await _client.SendAsync(requestMessage);
                return response as T;
            });
        }
        
    }

While for the CheckForOperationCompletion a standard HttpClient is used.

Now, as you might have noticed, I added a comment to make this code Async (right now this is a prototype Console App).

Also, ideally an Email should be sent to the user who starts those long running processes (such as creating API Management service or backing it up and restoring it),

And this code should probably reside inside a WebJob (or Service), so it can run on its own, no matter which client calls it.

But all that is out of scope for this prototype and blog post, so that's all for now!