Happy to walk through workflows, architecture, or demo components

🧾 Steps to Schedule a Batch File in Windows Task Scheduler

Step 1: Create Your Batch File

1. Open Notepad.

2. Type your batch commands, for example:

   @echo off
   echo Running monthly maintenance...
   :: Add your commands here
   pause
   

3. Save the file as monthly_task.bat (example name).
   📁 Save it in a folder like: C:\Scripts\monthly_task.bat

---

Step 2: Open Task Scheduler

1. Press Windows + R → type taskschd.msc → press Enter.

2. The Task Scheduler window will open.

---

Step 3: Create a Basic Task

1. Click “Create Basic Task…” on the right side.

2. Enter a name (e.g., “Run Monthly Batch File”).

3. Click Next.

---

Step 4: Set the Trigger (Schedule)

1. Select “Monthly” → click Next.

2. Under Months, select All months.

3. Under Days, enter 1 (this means 1st day of each month).

4. Set the Start time (e.g., 10:00 AM).

5. Click Next.

---

Step 5: Set the Action

1. Select “Start a program” → click Next.

2. In the Program/script field, click Browse.

3. Locate and select your .bat file (C:\Scripts\monthly_task.bat).

4. Click Next.

---

Step 6: Finish the Setup

1. Review the summary page.

2. Click Finish.

---

Step 7: (Optional) Run as Administrator

If your batch file needs admin permissions:

1. Right-click the created task → choose Properties.

2. In the General tab, check “Run with highest privileges.”

3. Click OK.

---

Step 8: Test the Task

1. Right-click your task → click Run.

2. Confirm your batch file executes properly.

---

✅ Result:
Your batch file will now automatically run on the 1st of every month at the time you set.

Trigger in Azure Functions

🟢 What is a Trigger in Azure Functions?

• An Azure Function is a small piece of code that runs only when something happens.

• That “something” is called a trigger.

• Trigger = automatic starter for your function.

Example:
If you want a function to run every day at 9 AM, a Timer trigger starts it for you.

---

🧩 Key Idea

• Each function must have exactly one trigger.

• The trigger decides:

  1. When the function runs.

  2. What input data is passed to it.

---

🔑 Common Trigger Types (with Examples)

Below are the most used Azure Function triggers and what they do.

Trigger Type	What Starts the Function	Simple Example
HTTP Trigger	An HTTP request (like a web API call)	Someone sends a GET/POST request to a URL such as https://myfunc.azurewebsites.net/api/hello
Timer Trigger	A scheduled time (like a cron job)	Run cleanup every night at 2 AM
Blob Trigger	A file is added or updated in Azure Blob Storage	Automatically resize an image after it’s uploaded
Queue Storage Trigger	A new message is put in an Azure Storage Queue	Process new orders added to a queue
Service Bus Trigger	A message arrives in an Azure Service Bus queue or topic	Handle incoming payment notifications
Event Grid Trigger	An Azure event occurs (e.g., new file in a storage account, resource change)	Send a Slack message when a new file arrives
Event Hub Trigger	A batch of event-stream data arrives (IoT or telemetry)	Analyze live sensor data
Cosmos DB Trigger	A document changes in a Cosmos DB collection	Update a cache or run analytics whenever a record changes
SignalR Trigger (rare)	A SignalR event happens	Send real-time messages to connected clients

---

🛠️ How It Works Step by Step

1. Binding in Code
   In the function’s code you specify the trigger type and connection details.

   [FunctionName("MyHttpFunction")]
   public static IActionResult Run(
       [HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequest req,
       ILogger log)
   {
       log.LogInformation("HTTP trigger fired.");
       return new OkObjectResult("Hello World!");
   }
   

2. Runtime Listens
   Azure Functions runtime listens for that event (HTTP call, queue message, timer schedule, etc.).

3. Event Happens
   When the event occurs, the runtime starts the function automatically and passes in the data (like the HTTP body, message text, or blob contents).

---

⚙️ Details About Each Trigger

1. HTTP Trigger

• Use for: APIs or webhooks.

• Input: Request body, query strings, headers.

• Return: HTTP response.

• Security: Set AuthorizationLevel (Anonymous, Function, Admin).

2. Timer Trigger

• Use for: Scheduled tasks like cleanup, backups.

• Schedule Format: CRON expression, e.g., "0 0 2 * * *" (2 AM daily).

• Example: Nightly email reports.

3. Blob Trigger

• Use for: Processing files.

• Works with: Azure Blob Storage containers.

• Example: Process a CSV when someone uploads it.

4. Queue Storage Trigger

• Use for: Simple messaging between services.

• Example: One system drops a message when an order is placed; the function picks it up and processes it.

5. Service Bus Trigger

• Use for: Enterprise messaging (queues or topics).

• Example: Payment gateway sends a Service Bus message when a payment succeeds.

6. Event Grid Trigger

• Use for: Reacting to Azure events in near real-time.

• Example: Notify a team when a new blob is created.

7. Event Hub Trigger

• Use for: High-volume event streams like IoT telemetry.

• Example: Analyze millions of device signals per minute.

8. Cosmos DB Trigger

• Use for: Reacting to database changes.

• Example: Automatically update a search index when a product record changes.

---

🧠 Best Practices

1. One Trigger per Function

   • Each function listens to exactly one event source.

2. Keep Functions Short

   • Do small tasks quickly to avoid timeouts.

3. Scale Automatically

   • Triggers like Queue, Event Hub, and Blob scale the number of function instances based on event volume.

4. Use Bindings for Input/Output

   • You can directly read or write to storage, queues, etc., with simple parameters—no extra code.

---

Quick Recap

• Trigger = automatic starter for your code.

• Common triggers: HTTP, Timer, Blob, Queue, Service Bus, Event Grid, Event Hub, Cosmos DB.

• Each function must have exactly one trigger.

• Azure Functions automatically listens for the event and runs your code when it happens.

In short:
Azure Function triggers let you run code automatically whenever a specific event (like a request, message, or file upload) occurs—no servers to manage, just write the function and choose the trigger.

CDC

ETF Job Creation: Problem & Solution Document

---

1. Problem Statement

Current Challenges in ETF Job Creation

• High Development Effort
  Creating new jobs, especially for new clients or new file formats, demands significant development time, including writing new scripts, packages, and stored procedures.

• Redundant and Repetitive Work
  Many jobs that are repetitive or similar require manual recreation, leading to repetitive coding and testing efforts.

• Limited Self-Service Capability
  Business or Operations (OPS) teams currently do not have the ability to configure or create jobs independently, making the process dependent on Development (Dev) and Quality Assurance (QA) teams and increasing turnaround time.

• Complex Job Modifications
  Changes to existing jobs, such as adding/removing fields or modifying configurations, involve manual updates to packages and stored procedures, impacting maintenance and agility.

• Scattered Configuration Management
  Job-related configurations (e.g., file paths, email distribution lists) are managed separately, increasing the risk of inconsistencies and complicating configuration updates.

---

2. Scope

In Scope

• Similar or repetitive reporting files for new Funds/Fund Families.
• Requests for a new type of file that is already generated for another Fund/Fund Family.

Out of Scope

• Addition of new fields in existing files for an existing Fund/Fund Family.
• Requests for reports with different field combinations, transformations, or formats than current reports.

---

3. Benefits of Current System Limitations

• Minimal changes to existing jobs reduce risk but limit agility.
• Business/OPS team lacks self-service capabilities for configuring jobs.
• Heavy reliance on Dev/QA teams for creation or replication of jobs.

---

4. Proposed Solution

Streamlined ETF Job Creation Process

To reduce development costs and repetitive work, the following improvements are proposed:

---

4.1 UI for Job Creation

• Develop a dedicated screen where Output ID/Job ID can be created directly via a user-friendly interface.
• This interface will replicate current SQL insert script functionality, eliminating manual script creation.
• It empowers Business/OPS teams to create or replicate job configurations quickly without Dev/QA involvement.

---

4.2 UI for SSIS Configuration Management

• Create a screen to centrally store all SSIS package-related configurations such as:

  • Output file paths
  • File names
  • Email distribution lists (DLs)
  • Other configurable settings

• SSIS packages will read configuration details directly from the database via this interface, replacing the need for multiple separate configuration files.

---

4.3 UI for Job Scheduling (Future Scope)

• Design a screen to allow job scheduling directly in SQL Server.
• This will require elevated permissions on the MSDB database.
• Enables Business/OPS teams to manage job schedules without manual SQL Server Agent setup.

---

5. Summary of Workflow Changes

Phase/Action	Current Process	Proposed Process
New Client Onboarding	Write DB scripts and packages manually	Use UI to insert Output ID & create job configurations
Job Creation for Existing Clients	Create packages, stored procedures, and configs manually	Use UI to select existing templates and configure jobs
Changes to Existing Jobs	Modify existing packages and update config files manually	UI allows configuration changes without code changes
Job Scheduling	Manual SQL Server Agent setup	UI-based scheduling for ease and automation

---

6. Expected Benefits of Proposed Solution

• Reduced Development Time: Automate repetitive steps and eliminate manual script creation.
• Empowered Business/OPS Teams: Enable non-technical users to configure and manage jobs independently.
• Consistency and Accuracy: Centralized configuration storage reduces errors and inconsistencies.
• Improved Agility: Faster onboarding for new clients and easier job modifications.
• Future Proof: UI-based scheduling adds flexibility and reduces dependency on DBAs.