PPT - Creating Professional Integration Architecture Diagrams Using PowerPoint

Creating Professional Integration Architecture Diagrams Using PowerPoint

When Visio Isn’t Available, PowerPoint Becomes Your Best Friend

In many enterprise projects, solution architects and integration developers must document system flows clearly. While tools like Visio or Lucidchart are commonly used, they are not always available in corporate environments due to licensing or security restrictions.

In such situations, Microsoft PowerPoint becomes a powerful and reliable alternative for creating clean, professional architecture and integration diagrams.

This blog demonstrates a real integration use case and shows how PowerPoint can be used to design high-quality diagrams.

Use Case: Source System to Target System File Integration

Business Scenario

A payment file is generated by a Source System and manually uploaded to the OIC SFTP location. Oracle Integration Cloud processes the file and finally uploads it into a Target System for downstream financial processing.

The business requires:

• Clear process visibility
• Batch job tracking
• Error monitoring

A simple but professional architecture diagram

Integration Flow Overview

The integration follows these steps:

• File is generated by the Source System.
• File is manually uploaded to OIC SFTP.
• OIC Scheduler picks the file.
• File is transformed into Target System format.
• File is uploaded to OCI Object Storage.
• Faults are logged in monitoring tools.

Solution: Creating This Diagram Using PowerPoint

Step 1: Create Swimlane Structure

• Use Insert → Table (1 row, 3 columns) to represent:
• Source System
• Oracle Integration Cloud
• Target System
• Format the header row with a blue background and white text.

This instantly creates a swimlane layout similar to professional architecture tools.

From Table design >> take a standard table style.

Step 2: Add Process Blocks

Use Rounded Rectangles for each processing step:

• Scheduler
• Get file from OIC SFTP
• Transform to Target format
• Upload to OCI Object Storage

Use light orange or yellow color for process clarity.

Step 3: Add System Objects

Use distinct colors:

Green → Input File 

Orange → Target System 

Color coding improves readability.

Step 4: Use Connectors (Not Lines)

Always use:

Insert → Shapes → Connector → Right Angle Arrow

This ensures connectors stay attached when shapes move.

Step 5: Add Supporting Notes

Use text boxes for:

“Manually uploaded by business team”

“Upload file to Target System”

These clarify ownership.

Step 6: Add Fault Handling Layer

At the bottom, insert a full-width rectangle:

Fault Handler – Monitoring Tool

This highlights error handling.

Step 7: Align & Distribute

Select shapes → Align → Align Center → Distribute Vertically

This gives a Visio-quality look.

Best Practices

Use consistent colors per layer

Keep uniform shape sizes

Follow swimlane structure

Avoid crossing arrows

Keep text action-oriented

Conclusion

PowerPoint is more than a presentation tool. With the right techniques, it becomes a powerful architecture diagramming solution that works perfectly for integration, data flow, and system design documentation.

This approach is ideal for:

Integration solution design

Technical documentation

Client walkthroughs

Knowledge transfer sessions

Microsoft Excel - working with excel's lookup function

📘 Working with Excel Lookup Functions

🔹 Microsoft Excel VLOOKUP() Function

VLOOKUP always searches in the first (leftmost) column of the table_array

It then returns a value from a column to the right of that first column

Widely used but has limitations (left-to-right only): “Left-to-right only” means VLOOKUP can return values only from columns that are to the right of the lookup column, never from the left.

Syntax:

=VLOOKUP(lookup_value, table_array, col_index_num, [range_lookup])

📌 Best for simple vertical lookups

🔹 Microsoft Excel HLOOKUP() Function 

Searches for a value in the first row of a table

Returns data from rows below

Less commonly used than VLOOKUP

Syntax:

=HLOOKUP(lookup_value, table_array, row_index_num, [range_lookup])

📌 Best for horizontally structured data

🔹 Microsoft Excel INDEX() Function 

Returns a value from a cell based on row and column number. Very powerful and flexible

Syntax:

=INDEX(array, row_num, [column_num])

📌 Does not perform lookup by itself

🔹 Microsoft Excel MATCH() Function 

Finds the position of a value in a row or column

Often used with INDEX

Syntax:

=MATCH(lookup_value, lookup_array, [match_type])

📌 Returns position, not the value

🔹 INDEX() + MATCH() Combined

A powerful alternative to VLOOKUP

Can lookup left, right, up, or down

Example:

=INDEX(B2:B10, MATCH(E1, A2:A10, 0))

📌 More flexible and efficient than VLOOKUP

🔹 Dynamic HLOOKUP() using MATCH() — Advanced

MATCH dynamically identifies the row number

Prevents formula breakage when structure changes

Example:

=HLOOKUP(A1, A1:D10, MATCH("Sales", A1:A10, 0), 0)

📌 Makes HLOOKUP adaptable and robust

✅ Summary Table

OIC - Processing Files Larger Than 1 GB in Oracle Integration Cloud (OIC)

Processing large files (greater than 1 GB) in Oracle Integration Cloud (OIC) requires a well-thought-out design. OIC is an integration and orchestration platform, not a bulk file-processing engine. Therefore, the recommended approach is to offload heavy file handling and let OIC coordinate the process.

This blog covers the most effective and supported patterns to handle large files in OIC reliably.

Core Strategies for Large File Processing

1. Chunking (Segmentation)

File Chunking involves splitting a large file into smaller chunks and processing them one by one.

How It Works

The source system divides the file into smaller parts (for example, 50–100 MB chunks) 

Each chunk is sent separately 

OIC processes or routes each chunk

The target system reassembles the chunks into the original file

Benefits

Reduces memory pressure on OIC

Supports retries at chunk level instead of reprocessing the whole file

Improves reliability over unstable networks

Enables parallel processing if required

OIC Usage Notes

Pass chunk metadata (file name, chunk number, total chunks)

Use asynchronous integrations

Store chunk status externally if reassembly is required

2. Streaming

Streaming processes large files without loading the entire content into memory.

Benefits

Highly memory efficient

Faster processing start time

Suitable for continuous or large data flows

OIC Perspective

OIC does not support full custom streaming logic

Adapters such as FTP Adapter and OCI Object Storage Adapter internally stream files

Avoid mapping large payloads into integration variables

Best practice: Let adapters stream the file; keep OIC orchestration lightweight.

3. Cloud Object Storage (Preferred Pattern)

Using OCI Object Storage (or similar cloud storage) is the recommended approach for handling very large files.

Pattern Overview

Source uploads the file directly to Object Storage

OIC receives only file metadata (object name, bucket, URL)

OIC orchestrates downstream processing

Target system downloads the file directly from Object Storage

Benefits

Designed for multi-GB and TB-scale files

Built-in multipart upload support

High durability and scalability

Keeps OIC payload sizes small

Additional Recommended Approaches

4. OCI SDK / REST API (Multipart Uploads)

To bypass OIC’s payload size limitations:

Use OCI SDKs or OCI REST APIs

Perform multipart uploads directly to Object Storage

OIC only triggers or monitors the process

Benefits

No 1 GB payload limitation

Better performance and reliability

Ideal for custom upload/download logic

5. Oracle Functions for File Handling

Oracle Functions can act as a lightweight processing layer between systems.

Typical Use Case

Oracle Function downloads a large file from source

Performs validations or transformations if needed

Uploads the file to Object Storage using multipart upload

OIC is notified after completion

Benefits

Serverless and scalable

Keeps OIC free from heavy processing

Ideal for pre-processing or post-processing large files

Recommended Architecture

Source System → Object Storage / OCI SDK / Oracle Functions → OIC (Orchestration) → Target System

OIC’s role should be:

Triggering integrations

Orchestrating workflows

Handling errors and notifications

Tracking metadata (not file content)

Conclusion

When dealing with files larger than 1 GB in Oracle Integration Cloud:

✔ Use Object Storage as the central file repository

✔ Prefer chunking or streaming over full payload loads

✔ Leverage OCI SDKs, REST APIs, or Oracle Functions

✔ Keep OIC focused on orchestration, not file movement

Following these patterns ensures scalability, reliability, and compliance with OIC best practices.

OIC - Oracle Integration Cloud (OIC): Design Best Practices & Common Pitfalls to Avoid

Introduction

Oracle Integration Cloud (OIC) is a powerful platform for connecting cloud and on-premises applications. However, poor integration design can lead to performance issues, timeouts, backlogs, and scalability problems.

In this blog, we’ll explore key design best practices recommended by Oracle and highlight common pitfalls you should avoid while designing integrations in Oracle Integration Cloud (OIC 3).

Why Integration Design Matters

A well-designed integration:

• Improves performance and scalability
• Prevents stuck instances and scheduler backlogs
• Reduces timeout and failure scenarios
• Ensures smooth interaction between systems

Poor design, on the other hand, can impact the entire OIC instance, not just a single integration.

Different Best Practices:

1. Create Scheduled Integrations Mindfully

The Problem

Having too many scheduled integrations running at the same time can:

• Exhaust scheduler resources
• Cause delays in execution
• Lead to integrations not starting on time
• Long-running scheduled integrations are especially dangerous.

Best Practices

✔ Avoid clustering multiple schedules at the same time 

✔ Do not create long-running scheduled integrations (for example, those running over 1 hour) 

✔ Spread schedules across different time slots

Recommended Design Pattern

Instead of doing heavy processing inside a scheduled integration:

Convert the scheduled integration into a REST Adapter–triggered integration

Create a lightweight scheduler that:

Triggers the REST-based integration asynchronously

Completes within milliseconds

Benefits

Scheduler starts on time 

Reduced resource contention 

Better scalability and reliability

📌 Tip: Start converting:

Longest-running schedules

High-frequency schedules (every 10 minutes or less)

2. Follow Guidelines for Synchronous Integrations

A synchronous integration should not depend on asynchronous request–response services.

• One-way (fire-and-forget) asynchronous calls are okay.
• Oracle Integration does not support true asynchronous request–response modeling. Since scheduled integrations internally work in an asynchronous manner, calling a scheduled integration from a synchronous flow is a bad design practice.
• If a synchronous integration calls multiple services and the total processing time goes beyond five minutes, OIC may mark it as a stuck thread.

Best Practices

✔ Keep synchronous integrations short and fast

✔ Avoid calling scheduled integrations from synchronous flows

✔ Fire-and-forget (one-way) asynchronous calls are acceptable

3. Design Long-Running Integrations as Asynchronous

The Golden Rule

If an integration takes more than 2 minutes, it should be asynchronous.

Why?

• Client applications may time out
• OIC has server-side timeout limits
• Long waits block system resources

Recommended Approach

✔ Expose long-running processes as asynchronous integrations 

✔ Return immediate acknowledgment 

✔ Continue processing in the background

This improves user experience and system stability.

4. Understand Timeouts in Synchronous Integrations

Timeout Reality in OIC

• Synchronous calls must complete within 300 seconds (5 minutes).

But there’s more:

• Oracle Public Cloud proxy default timeout: 120 seconds
• On-premise proxies/firewalls may have their own timeout values

Key Insight

If multiple layers have timeouts configured, the first timeout reached causes failure.

Best Practice

✔ Avoid chaining multiple synchronous calls

✔ Minimize dependency on slow external systems

✔ Use asynchronous patterns wherever possible

5. Send Data to Third-Party Systems Efficiently

The Challenge

Sending data to multiple third-party systems in parallel without hitting timeout limits.

Recommended Design Pattern: Parent–Child Integrations

Step 1: Parent Integration

Receives and processes data

No outbound calls

Step 2: Child Integrations

Handle individual outbound REST calls

Triggered asynchronously

Communication Options

✔ Asynchronous REST (fire-and-forget)

✔ Publish/Subscribe model (queues, events)

Benefits

Parallel processing

Reduced timeout risks

Better resource utilization

🚫 Avoid making all outbound synchronous calls in a single integration—it can easily exceed the 5-minute limit.

Common Design Pitfalls to Avoid

❌ Too many scheduled integrations at the same time

❌ Long-running synchronous integrations

❌ Using schedules for request-response patterns

❌ Chaining multiple synchronous service calls

❌ Ignoring proxy and firewall timeouts

Conclusion

Designing integrations in Oracle Integration Cloud is not just about making systems talk—it’s about performance, scalability, and reliability.

By following these best practices:

You reduce failures and stuck instance 

Improve scheduler efficiency 

Build integrations that scale with business growth

A small design decision today can prevent major production issues tomorrow.

Reference:

https://docs.oracle.com/en/cloud/paas/application-integration/integrations-user/common-integration-style-pitfalls-and-design-best-practices.html