Fix links to images in WSO2 specific patterns

vendor-specific/wso2/patterns/API-manager-3rd-party-KM-integration.md

@@ -10,7 +10,7 @@ If the requirement is just to share the same user base with the API platform, go
 ## Architecture
 WSO2 API Manager comes with a componentized architecture where each component can be deployed separately if required. Even within a single runtime, these components run with clear separation by communicating over well defined APIs. This API driven product design allows the product to be extended by using these interfaces. Using an external IdP as the key management component of the WSO2 API Manager is possible with this design. Let’s take a look at how this can be achieved.
 
-![WSO2 APIM 3rd party KM](images/WSO2APIM-3rdParty-Authorization-Server-Integration.png)
+![WSO2 APIM 3rd party KM](../images/WSO2APIM-3rdParty-Authorization-Server-Integration.png)
 Figure 1: WSO2 API Manager 3rd party key manager integration
 
 The above figure depicts the standard integration of an external Identity Provider as the 3rd party key manager for WSO2 API Manager. There are 4 main components of API Manager is depicted here along with the users of those profiles.
@@ -47,7 +47,7 @@ In a typical workflow of API management, here is how this custom implementation
 Note: In the above figure, it has connected the same user store (LDAP/AD/JDBC) to both WSO2 API Manager and the IdP. This will make the integration flowless since additional user-level information can be extracted for the users with this approach. If we don’t use the same user store, we can’t support scope validation and backend JWT with user claims. But this is optional and based on the grant type and the backend implementation, you can decide on whether to share the user store or not.
 A sequence diagram view of the above mentioned workflow (starting from login into API Store) is depicted in the below figure.
 
-![APIM 3rd party KM integration workflow](images/API-Store-integrate-with-3rd-party-KM.png)
+![APIM 3rd party KM integration workflow](../images/API-Store-integrate-with-3rd-party-KM.png)
 Figure 2: Sequence diagram view of component interaction
 
 ## Reference implementation

vendor-specific/wso2/patterns/Cloud-Application-Security-Pattern.md

@@ -13,7 +13,7 @@ With the introduction of more and more cloud based applications, user management
 ## Architecture
 Using a centralized Identity Provider (IdP) is the solution to address the above challenges and come up with a user-friendly, scalable experience to identity admins as well as users. 
 
-![Cloud-Application-Security-Pattern](images/Cloud-Application-Security-Pattern.png)
+![Cloud-Application-Security-Pattern](../images/Cloud-Application-Security-Pattern.png)
 
 As depicted in the above figure, cloud applications are configured within the WSO2 Identity Server (or any IdP) as service providers. Based on the authentication mechanism supported by the relevant application (e.g. SAML2, OIDC, WS-Federation), WSO2 IS can be configured. In the meantime, WSO2 IS needs to be configured as an Identity Provider within the relevant cloud application side. Once these settings are done, when a user tries to log into the respective cloud application, it will be redirected to the WSO2 IS authentication endpoint. Now users can provide the credentials which are stored within the enterprise user store (AD, LDAP, JDBC) which is connected with the WSO2 IS. 
 

vendor-specific/wso2/patterns/Legacy-Platform-Modernization-with-WSO2.md

@@ -11,7 +11,7 @@ If you think just about the tasks and responsibilities you already have similar
 ## Existing legacy platform (Step 0)
 Let’s come back to the ground and try to understand the current legacy enterprise platform you are having in your enterprise along with the challenges it has.
 
-![Legacy platform](images/modernize-legacy-platforms-with-wso2-0.png)
+![Legacy platform](../images/modernize-legacy-platforms-with-wso2-0.png)
 
 Figure: Legacy enterprise platform — challenges and expectations
 
@@ -40,7 +40,7 @@ As I mentioned at the beginning of this post, addressing these challenges is nec
 ## Start the modernization (Step 1)
 Once the existing challenges and the broader picture is identified and convinced to at least some of the stakeholders (sometimes you can’t convince everyone to get things started), you should start somewhere. One important aspect of doing any migration or modernization is to do that with minimum impact on existing users. This is the reason why we should bring in a layer at the highest point of interaction to the customer just below the load balancer or proxy.
 
-![Legacy modernization with APIs](images/modernize-legacy-platforms-with-wso2-1.png)
+![Legacy modernization with APIs](../images/modernize-legacy-platforms-with-wso2-1.png)
 
 Figure: Legacy modernization step 1
 
@@ -62,7 +62,7 @@ But still, there are a lot of issues, and challenges still exist in the overall
 ## Establish the new platform (Step 2)
 Even though the API management platform is capable of supporting certain aspects like automation, cloud-native, agile development, and improve monitoring aspects, the rest of the platform is still not ready to build that integrated experience. Because of that, we have to identify the next phase of the modernization effort carefully and execute without frustrating the stakeholders.
 
-![Legacy modernization establishing](images/modernize-legacy-platforms-with-wso2-2.png)
+![Legacy modernization establishing](../images/modernize-legacy-platforms-with-wso2-2.png)
 
 Figure: Legacy platform modernization — establishing
 
@@ -83,7 +83,7 @@ At this stage, the modernization effort is well established and most of the chal
 ## Improve user experience (Step 3)
 With the enterprise platform in better shape in terms of scalability, management, automation, and innovation, the next step would be to improve the overall user experience of the platform while applying the better security models for users and applications. Though it feels like we are considering security as a secondary matter since it appeared in step 4, it is not the right way to look at this approach. From the beginning, the security was handled by applications and they managed their own user stores and their own security protocols. Through the API management platform, certain aspects of security were modernized with the use of OAuth 2.0 tokens. But consolidating the various user bases which spanned across multiple applications needs to be done once the systems are properly implemented.
 
-![Legacy modernization user experience improvement](images/modernize-legacy-platforms-with-wso2-3.png)
+![Legacy modernization user experience improvement](../images/modernize-legacy-platforms-with-wso2-3.png)
 
 Figure: Legacy modernization — improve user experience
 
@@ -94,7 +94,7 @@ All is well up to this point and the system is providing more and more functiona
 ## Make it future proof (Step 4)
 If you look at the figure in the previous section, there are 2 white boxes still we need to make green. Those are the resource under-utilization and cloud-native aspects. Based on research done in recent times, it is evident that more and more enterprises are moving their workloads to the cloud already or planning to migrate their workloads to the cloud in the future. As an enterprise architect who is planning a modernization effort, not thinking about cloud migration is a big mistake. Because of that, we should make the modernized platform cloud-friendly so that when the overall organization decides to go down the cloud direction, the platform is ready to move on to the cloud.
 
-![Legacy modernization future](images/modernize-legacy-platforms-with-wso2-4.png)
+![Legacy modernization future](../images/modernize-legacy-platforms-with-wso2-4.png)
 
 Figure: Legacy modernization — future proof deployment
 

vendor-specific/wso2/patterns/Microgateway-Pattern1-Decentralized-Gateway.md

@@ -5,7 +5,7 @@ With the adoption of microservices style of architecture within the enterprise,
 
 ### Architecture
 
-![Decentralized API Gateway](images/Microgateway-Pattern1-Decentralized-Gateway.png)
+![Decentralized API Gateway](../images/Microgateway-Pattern1-Decentralized-Gateway.png)
 Figure 1: Decentralized API Gateway pattern
 
 As depicted in the above figure 1, In this deployment mode, api consumers can either use oauth2 tokens or jwt tokens. In the case of oauth2 tokens, microgateway will communicate with the key manager component. If there is a requirement to implement shared throttling across apis, microgateway will communicate with the external traffic manager. Analytics data will be published to the analytics runtime. In this deployment pattern, api publisher and store are deployed separately and will be exposed to api and application developers. These components will not have any interaction with microgateway components during the runtime. 

vendor-specific/wso2/patterns/Microgateway-Pattern2-Locked-Down-Gateway.md

@@ -5,7 +5,7 @@ Sometimes applications needs to be deployed in environment where there are no co
 
 ### Architecture
 
-![Locked-down API gateway pattern](images/Microgateway-Pattern2-Locked-Down-Gateway.png)
+![Locked-down API gateway pattern](../images/Microgateway-Pattern2-Locked-Down-Gateway.png)
 Figure 1: Locked-down API Gateway pattern
 
 As depicted in the above figure 1, WSO2 API Microgateway has the ability to run in this type of environment with it’s built in security (JWT based), rate limiting (local) and offline-analytics capabilities. The applications and microservices will get the same set of capabilities from the API Microgateway, though there is no connection at all with the rest of the components of the API Manager. The Analytics data will be collected into files and will be uploaded to the analytics runtime when there is a connection established with that component.

vendor-specific/wso2/patterns/Microgateway-Pattern3-Seasonal-Gateway.md

@@ -5,7 +5,7 @@ If you have already deployed WSO2 API Manager (all-in-one) in a centralized mann
 
 ### Architecture
 
-![Seasonal API Gateway pattern](images/Microgateway-Pattern3-Seasonal-Gateway.png)
+![Seasonal API Gateway pattern](../images/Microgateway-Pattern3-Seasonal-Gateway.png)
 Figure 1: Seasonal API Gateway pattern
 
 With the API Microgatway, you can quickly set up a seasonal gateway with a selected set of APIs and scale them up and down as necessary without impacting the existing deployment. 

vendor-specific/wso2/patterns/Microgateway-Pattern4-Multi-Data-Center-Gateway.md

@@ -5,7 +5,7 @@ Large enterprises which has global operations requires their applications to be
 
 ### Architecture
 
-![Multi data center API gateway pattern](images/Microgateway-Pattern4-Multi-Data-Center-Gateway.png)
+![Multi data center API gateway pattern](../images/Microgateway-Pattern4-Multi-Data-Center-Gateway.png)
 Figure 1: Multi data center API gateway pattern
 
 As depicted in the above figure 4, the only component which shares data across data centers during the runtime is the analytics component which can connect to the other data centers in an offline manner. With the API microgateway, multi data center deployment has become much simpler and easier to implement and maintain. The above mentioned data centers can span across multiple cloud IaaS providers (Amazon, Google, Microsoft) as well.

vendor-specific/wso2/patterns/Microgateway-Pattern5-Service-Mesh-Sidecar-Gateway.md

@@ -4,7 +4,7 @@
 If your enterprise is deeply integrated with microservices and wanted a fully fledged microservices implementation, service mesh is a pattern which you cannot ignore. Service mesh defines a network to communicate between microservices with a similar level of protection on top of them as external communications. Some might think this as an overkill but there are enough practical examples where people has implemented microservices with service meshes for better security, visibility and management of the overall microservices implementation. WSO2 API Microgateway can be used as a sidecar proxy in a service mesh kind of microservices architecture. It provides capabilities like authentication, rate limiting, circuit breaker, timeouts as well as monitoring. 
 
 ### Architecture
-![Service Mesh sidecar API gateway pattern](images/Microgateway-Pattern5-Service-Mesh-Sidecar-Gateway.png)
+![Service Mesh sidecar API gateway pattern](../images/Microgateway-Pattern5-Service-Mesh-Sidecar-Gateway.png)
 Figure 1: Service Mesh sidecar API gateway pattern
 
 In this deployment pattern, each microservice has an API Microgateway running alongside it in the same localhost. In kubernetes, both microservice and the API microgateway runs in the same pod (can be in different containers). All the communications across microservices will go through API microgateway for ingress and egress traffic. WSO2 API Manager analytics component can be used to analyze the interactions happening through the sidecar gateway.

vendor-specific/wso2/patterns/Microgateway-Pattern6-Hybrid-API-Gateway.md

@@ -4,7 +4,7 @@
 In all the deployment patterns mentioned above, the management aspect of the deployment needs to be handled by the enterprise. It gives them the utmost flexibility and control over the platform. But sometimes, organizations with limited IT staff and skill set wants to outsource some of the management and hosting capabilties of the platform while keeping the important components. This is what exactly the hybrid API gateway pattern provides. 
 
 ### Architecture
-![Hybrid API Gateway pattern](images/Microgateway-Pattern6-Hybrid-API-Gateway.png)
+![Hybrid API Gateway pattern](../images/Microgateway-Pattern6-Hybrid-API-Gateway.png)
 Figure 1: Hybrid API gateway pattern
 
 In this deployment pattern, the critical runtime component of the API platform which is the gateway will be running under the control of the enterprise. It can be run on a private data center, public IaaS cloud or both. In the meantime, the management components of API publisher, Developer Portal, Analytics and Key manager will be hosted and maintained by WSO2 within their public API Cloud. 

vendor-specific/wso2/patterns/Modern-Brown-Field-Enterprise-WSO2.md

@@ -28,7 +28,7 @@ In addition to that, there can be newly built services which are developed as pa
 ## Solution Architecture
 Let’s take a look at how these requirements can be fulfilled with an architecture diagram.
 
-![Modern brown-field enterprise with WSO2](images/Modern-Brown-Field-Enterprise-WSO2.png)
+![Modern brown-field enterprise with WSO2](../images/Modern-Brown-Field-Enterprise-WSO2.png)
 
 Figure: Modern enterprise system with WSO2 technology
 

vendor-specific/wso2/patterns/WSO2-EI7-Solution-patterns.md

@@ -44,7 +44,7 @@ Let’s consider an organization that is not an early adopter of cutting edge te
 ### Synchronous Hybrid Integration Pattern
 If your enterprise offers data to external and internal consumers through web applications, mobile applications or terminal applications, most of the time, these communications happen through HTTP and are synchronous (request/response). If your backend systems or the systems of record also works in a similar manner (synchronous), then you can make integrations pretty straightforward using an integration runtime. For this purpose, you can use the Micro Integrator profile of the WSO2 EI7 as depicted in the below figure.
 
-![Synchronous Hybrid Integration](images/Synchronous-Hybrid-Integration-WSO2-EI7.png)
+![Synchronous Hybrid Integration](../images/Synchronous-Hybrid-Integration-WSO2-EI7.png)
 
 Figure: Synchronous Hybrid Integration Pattern
 
@@ -69,7 +69,7 @@ If we extend the previously mentioned organization with some additional requirem
 
 Now we have to use the asynchronous messaging pattern along with the synchronous messaging pattern which was used for previous integrations. Let’s see how this can be catered with WSO2 EI7 Micro Integrator runtime.
 
-![Sync-Async Hybrid Integration Pattern](images/Sync-Async-Hybrid-Integration-WSO2-EI7.png)
+![Sync-Async Hybrid Integration Pattern](../images/Sync-Async-Hybrid-Integration-WSO2-EI7.png)
 
 Figure: Sync-Async Hybrid Integration Pattern
 
@@ -96,7 +96,7 @@ As we mentioned at the beginning, WSO2 EI7 comes with another profile that fits
 
 Similarly, for the second use case which is to process a continuous set of events (stream) that has correlated data, SI can be used and generate valuable insights from the data and push those results to various event sinks. As an example, users can output these results as notifications or store them in summary databases for visualizations. Let’s see how this looks like architecturally.
 
-![Sync-Async-Eventing Hybrid Integration Pattern](images/Sync-Async-Eventing-Hybrid-Integration-WSO2-EI7.png)
+![Sync-Async-Eventing Hybrid Integration Pattern](../images/Sync-Async-Eventing-Hybrid-Integration-WSO2-EI7.png)
 
 Figure: Sync-Async-Eventing Hybrid Integration Pattern