INCOGNITO

API Lifecycle - How to Manage Your APIs with IBM API Connect Workflow Ma...

noreply@blogger.com (Saptarshi Mandal) — Tue, 09 May 2023 10:12:00 +0000

Inside AWS Global Infrastructure: How the Cloud Giant Powers Your Apps a...

noreply@blogger.com (Saptarshi Mandal) — Tue, 02 May 2023 09:32:00 +0000

Simplifying Your AWS Workload with EC2 Auto Scaling: The Tech Think Tank...

noreply@blogger.com (Saptarshi Mandal) — Tue, 25 Apr 2023 08:39:00 +0000

Demystifying AWS Compute Resources: The Tech Think Tank Comprehensive Gu...

noreply@blogger.com (Saptarshi Mandal) — Tue, 18 Apr 2023 08:40:00 +0000

AWS Identity & Access Management (IAM) Explained: The Tech Think Tank Co...

noreply@blogger.com (Saptarshi Mandal) — Tue, 11 Apr 2023 15:01:00 +0000

Building Web Applications with Java Spring Boot: A Step-by-Step Guide - ...

noreply@blogger.com (Saptarshi Mandal) — Sun, 02 Apr 2023 14:42:00 +0000

Building Web Applications with Java Spring Boot: A Step-by-Step Guide - ...

noreply@blogger.com (Saptarshi Mandal) — Fri, 31 Mar 2023 14:34:00 +0000

An Overview of Data Science: What It Is And Why You Need It

noreply@blogger.com (Saptarshi Mandal) — Tue, 28 Mar 2023 10:36:00 +0000

Mastering Docker: Tips and Tricks for Containerising Your Applications

noreply@blogger.com (Saptarshi Mandal) — Wed, 22 Mar 2023 16:54:00 +0000

Revolutionizing Transportation: The Future of Autonomous Vehicle Technology

noreply@blogger.com (Saptarshi Mandal) — Mon, 20 Mar 2023 11:09:00 +0000

Kubernetes - A Deep Dive Introduction to Container Orchestration

noreply@blogger.com (Saptarshi Mandal) — Fri, 17 Mar 2023 15:46:00 +0000

Confirmation of Payee: Protect Your Money from Fraud!

noreply@blogger.com (Saptarshi Mandal) — Fri, 10 Mar 2023 09:56:00 +0000

Blockchain Explained: Understanding the Technology Behind Bitcoin

noreply@blogger.com (Saptarshi Mandal) — Wed, 08 Mar 2023 10:44:00 +0000

Exploring the Revolutionary World of Service Mesh: Everything You Need to Know

noreply@blogger.com (Saptarshi Mandal) — Mon, 06 Mar 2023 12:26:00 +0000

Multi-Cloud Explained: Benefits, Challenges, and Best Practices

noreply@blogger.com (Saptarshi Mandal) — Fri, 03 Mar 2023 16:19:00 +0000

Cloud Computing Demystified: Simplifying the Complex

noreply@blogger.com (Saptarshi Mandal) — Wed, 01 Mar 2023 11:00:00 +0000

OAuth Deep Dive: Exploring Grant Types, Components, and JWTs for Secure ...

noreply@blogger.com (Saptarshi Mandal) — Fri, 24 Feb 2023 10:50:00 +0000

OAuth Unleashed: The Surprising Truth About How Your Online Data is Prot...

noreply@blogger.com (Saptarshi Mandal) — Tue, 21 Feb 2023 10:22:00 +0000

Revolutionizing Finance: The Power of Decentralized Financial Systems

noreply@blogger.com (Saptarshi Mandal) — Fri, 17 Feb 2023 17:05:00 +0000

Cryptocurrency 101: Understanding the Basics of Digital Currency

noreply@blogger.com (Saptarshi Mandal) — Tue, 14 Feb 2023 19:52:00 +0000

Understanding Microservices: A Comprehensive Guide for Developers

noreply@blogger.com (Saptarshi Mandal) — Mon, 13 Feb 2023 12:29:00 +0000

Understand Open Banking: The Future of Financial Services

noreply@blogger.com (Saptarshi Mandal) — Fri, 10 Feb 2023 12:58:00 +0000

What is an AI and ML after all!

noreply@blogger.com (Saptarshi Mandal) — Wed, 08 Feb 2023 13:13:00 +0000

Encryption Decryption in DataPower

noreply@blogger.com (Saptarshi Mandal) — Thu, 21 Jan 2021 17:15:00 +0000

In todays post I will let you know how to work with encryption and decryption in DataPower. To do this we need two things, an algorithm and a shared secret key.

First, you need to choose an algorithm which you are going to use. I used "aes256-cbc". Google "encryption decryption algorithms" and you will find a suitable algorithm that suits you.

Now, lets see how to generate a secret key. There are loads of way you can create a secret key. There are plenty of websites available which can help you generate your secret key based on your algorithm. Search on google for "generating secret key for aes256 cbc", for getting such a website.

On the other hand you can also use openSSL to generate the secret key. Just type "openssl enc -aes-256-cbc -k secret -P -md sha256" in the command promt and it will generate the secret key for you. Example:

salt=A53C225C97FF9C8A

key=EA44A4CF852D1248111039CAF1F0F64D53AC15CE0A2EED491CA78DACA81F9090

iv =62FEE33867AB6EEEF55B9E79350D1743

Take the key value and append 0x to it to enable the hex encoding and save it to a .key file.

Now upload this key file into DataPower cert:/// folder and create a Crypto Secret Shared Key using this .key file.

Once this is done we need to write the code for encrypting and decrypting the data. Below are the sample codes which can help you to do the same. And that is it. You have now learned how to do encryption and decryption in DataPower (Of course you need to use these codes in the processing policy. I hope you know that. If not let me know.).

For encryption:

<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:json="http://www.ibm.com/xmlns/prod/2009/jsonx" xmlns:dp="http://www.datapower.com/extensions" extension-element-prefixes="dp" exclude-result-prefixes="dp" xmlns:dpconfig="http://www.datapower.com/param/config">

<xsl:output method="xml" version="1.0" encoding="utf-8" indent="yes"/>

<xsl:template match="/">

<xsl:variable name="algorithm" select="'http://www.w3.org/2001/04/xmlenc#aes256-cbc'"/>

<xsl:variable name="plainText" select="'plain text that needs to be encrypted'"/>

<xsl:variable name="secretKey" select="'name:SecretKey'"/>

<xsl:variable name="encryptedString">

<xsl:value-of select="dp:encrypt-string($algorithm,$secretKey,$plainText)"/>

</xsl:variable>

<xsl:value-of select="$encryptedString"/>

</encryptedString>

</Response>

</xsl:template>

</xsl:stylesheet>

For decryption:

<xsl:output method="xml" version="1.0" encoding="utf-8" indent="yes"/>

<xsl:template match="/">

<xsl:variable name="algorithm" select="'http://www.w3.org/2001/04/xmlenc#aes256-cbc'"/>

<xsl:variable name="encryptedString" select="//*[local-name()='encryptedString']"/>

<xsl:variable name="secretKey" select="'name:SecretKey'"/>

<xsl:variable name="decryptedString">

<xsl:value-of select="dp:decrypt-data($algorithm,$secretKey,$encryptedString)"/>

</xsl:variable>

<xsl:value-of select="$decryptedString"/>

</decryptedText>

</decryptedResponse>

</xsl:template>

</xsl:stylesheet>

APIGEE Terminology and Organizational Structure

noreply@blogger.com (Saptarshi Mandal) — Sun, 16 Feb 2020 13:23:00 +0000

Hello, welcome to the topology design lesson. In this lesson, we will explore key concepts related to designing the layout of Apigee components across your physical or virtual infrastructure. Let's jump into details. A clear understanding of the responsibilities of each Apigee component is required to successfully design your topology. We covered Apigee component responsibilities in detail as part of the technology stack lesson. If you haven't completed that lesson, please pause this video and complete it, prior to continuing with topology design. Apigee Edge components can be arranged into multiple groupings we call topologies. These topologies range from a single machine to many machines in different data centers. The Apigee Edge architecture is horizontally scalable. This is true for all components. On the diagram, nodes correspond to physical or virtual servers. Each node contains one or more Apigee components. Each component represents one or more processes hosted on those nodes. Depending on the requirements, nodes are added to the topology design to meet capacity, availability, resiliency, and network zoning requirements. A typical Apigee Edge topology looks like this. By typical, I mean the placement of components across nodes, not necessarily the number of nodes. Let's explore the diagram from left to right. Node 1 shows three components, UI, management server, and OpenLDAP. This is a common configuration option. These components are all associated with management functions, and it makes sense for them to be together on the same node. In these two region topology, we illustrate high availability for management functions. This is represented on node 11.

Each planet only needs one management server, but having two or more is possible. The need for more than one management server will be driven by requirements, such as availability and resiliency, for management capability. Nodes 2, 3, 4, 12, 13 and 14 hosts Cassandra and ZooKeeper components. Both Cassandra and ZooKeeper are clustered technologies. On this diagram, we illustrate a Cassandra ring composed of six nodes and a ZooKeeper ensemble with the same number of nodes. Any Apigee Edge topology beyond a single node all-in-one installation requires three Cassandra servers per region. This requirement is driven by then Cassandra replication factor and query read/write consistency configured in Apigee Edge. Since ZooKeeper and Cassandra share nodes, we recommend having the same number of Cassandra and ZooKeeper processes on each node. Making all datastore nodes containing Cassandra and ZooKeeper equal makes capacity planning, monitoring, and automation easier. In order to guarantee a consistent view of configuration data across the cluster, ZooKeeper uses a voting mechanism. We recommend having an odd number of ZooKeeper voters in the cluster. If you have an even number of ZooKeeper nodes, make one an observer. On the diagram, voters and observers are highlighted by the subscript found next to ZK. For example, ZKV represents a voter, while ZKO represents an observer. The ZooKeeper voting mechanism is described in more detail in the official ZooKeeper documentation. Nodes 5, 6, 7, 15, 16, and 17 correspond to the gateway. These nodes contain routers and message processors. A typical Apigee typology places both routers and message processors on the same server.

It is possible for you to host routers and message processors on different machines. Separation of these processes is only needed if network zone requirements call for it. The number of routers and message processors is driven by requirements and capacity planning. The minimum requirement is one of each, but most production installations will have two or more per region. Routers and message processors are stateless and horizontally scalable. They can be added and removed quickly if necessary. Nodes 8, 9, 18 and 19 host Qpid and Qpid server components. A typical topology has two Qpid nodes per region. Adding more Qpids is possible, but rarely needed for most installations. Nodes 10 and 20 are the Postgres nodes. These nodes host PostgreSQL as well as the analytics aggregation process called the Postgres server. On the diagram, we indicate that the PostgreSQL master is located in region 1, the PostgreSQL standby is in region 2. This is indicated by the subscript shown next to each PG. Depending on your analytic capacity and network requirements, Qpid and Postgres components may be combined on the same server. This is typically the case for non-production planets. In production, most customers have Qpid service separate from Postgres servers. The green horizontal lines going across regions correspond to eventually consistent data replication. Please notice that the developer portal is not included in the diagram. An additional node to host developer portal and its PostgreSQL database may be required. The Apigee Edge installation guide, located at docs.apigee.com, describes multiple sample installation topologies and patterns you can use as a starting point when designing your topology. Apigee Edge is built to scale. The architecture and technology selected allow you to scale horizontally. Horizontal scalability applies not only to components in the same region but also across regions.

Apigee Edge planets can contain one, two, three or more regions. As you scale horizontally and add regions to a planet, remember that not all components need to scale equally. Adding components for a specific functional area must be driven by requirements associated with that area. For example, in the diagram we illustrate three regions. Regions 1 and 2 possess the same number of components. In both regions, we find UIs, management servers, OpenLDAP, and Postgres servers. Region N looks different. In this region, only specific components are present. The minimum set of components required in a region contains Cassandra, ZooKeeper, Qpid, and one or more routers and message processors. Having a clear understanding of components' roles and responsibilities, as well as the architecture characteristics of Edge, makes it easy to identify problems, plan for capacity needs, and monitor the platform. It is important to remember that most of the time components can horizontally scale across the functional group shown here, independently of each other. Depending on API traffic patterns and availability needs, you may need to add additional capacity to components in a different functional group as you grow the number of components in one group. For example, you can add routers and message processors without having to worry about management or developer components. If the number of message processors increases due to more API calls, at some point in time you may need to add capacity to PostgreSQL or revisit your analytics data retention period. We will discuss capacity planning in more detail later on. For now, remember the grouping of components. By design, Apigee Edge is active, active. Depending on your needs, you can decide to send API traffic to one or more regions. It is possible to route Apigee traffic using active, passive regions, active, active regions, or geolocation. Typically, global load balancing, or DNS resolution, will be used. Let's use the diagram to illustrate runtime API traffic data flow.

An API call initiated by a client application will be directed by the global load balancer to a specific region. All traffic arriving in the region typically passes through a local load balancer before hitting an Apigee router. Once API calls arrive at the router, they will remain in the same region. Apigee routers and message processors are configured to direct calls to only local resources within the same gateway pod. API calls that arrive at the router are directed to one of the available message processors. Message processors execute API calls. Depending on the API proxy implementation, APIs may call Cassandra to install or retrieve data, as well as call one or more backend systems. API proxies may call backend systems in the same region, or across regions. The decision is based on the API proxy implementation and target server configuration. Analytics data flow works as follows. Analytics events are generated by the message processors. Message processors asynchronously send these events to Qpid. Qpid servers read data from Qpid queues and write data to PostgreSQL. Notice that all Qpid servers connect to the PostgreSQL master, as only that database is writable. Standby databases are read-only. Over time, the PostgreSQL master replicates data to all standby databases. Analytics events are generated by the message processors contain raw data about each API request. This raw data is aggregated by the Postgres server. Apigee Edge allows you to query both raw and aggregated data. Most reports visualized in the UI are powered by aggregated data. Customer reports provided by Edge use raw data. As you design your topology, it is important to consider your organization and environment design. Organizations and environments can be added at any time. You can also allocate underlying resources to different organizations or environments at any time. We cover this topic in detail as part of the terminology and organizational structure lesson. On Apigee Edge it is possible to control environment scope.

Message processors are associated with environments. This association controls whether a given message processor will process API calls for a particular environment. Typically, all message processors are associated with each environment. In the diagram, we illustrate the association between environment A and all available message processors. As new environments are added, they can share the existing physical capacity on the system. In the second example, we show that environments A and B are associated with all available message processors. This is a common design option. Most customers share message processors across one or more environments. If required, it is possible to allocate a dedicated processing capacity to specific environments. In the third example, we illustrate dedicated processing capacity being allocated to environment A and B. You can associate and disassociate message processors with environments at any time using the management API.

The association between message processors and environments can be useful in scenarios where physical separation of internal and external API traffic is required due to network zoning requirements. If required, routers and message processors can be placed in different network zones. Environments can be used to separate API deployments and traffic. For more information on this topic, refer to our documentation. If you have any questions, please post them to the comment section.