DPOD: Simplifying DataPower Management
Key Points
- The DataPower Operations Dashboard (D‑Pod) provides a unified, web‑based console for managing and troubleshooting DataPower gateway environments across all form factors (physical, virtual, Linux, Docker) and firmware versions.
- Developers can quickly identify transaction failures; the dashboard surfaces detailed error information (e.g., schema validation mismatches) that lets them correct requests without needing admin assistance.
- D‑Pod supports role‑based view filtering, allowing users to see only the services they’re authorized to access, enabling a self‑service experience for both developers and operations teams.
- The tool shows real‑time metrics such as successful vs. error transaction counts and per‑request latency, helping ops detect performance problems like a 10‑second response time that would be unacceptable in production.
- By centralizing DevOps diagnostics and performance data, D‑Pod speeds up problem determination and reduces the need for manual log‑ins to individual DataPower GUIs.
Full Transcript
# DPOD: Simplifying DataPower Management **Source:** [https://www.youtube.com/watch?v=_mT8H--LFMI](https://www.youtube.com/watch?v=_mT8H--LFMI) **Duration:** 00:04:51 ## Summary - The DataPower Operations Dashboard (D‑Pod) provides a unified, web‑based console for managing and troubleshooting DataPower gateway environments across all form factors (physical, virtual, Linux, Docker) and firmware versions. - Developers can quickly identify transaction failures; the dashboard surfaces detailed error information (e.g., schema validation mismatches) that lets them correct requests without needing admin assistance. - D‑Pod supports role‑based view filtering, allowing users to see only the services they’re authorized to access, enabling a self‑service experience for both developers and operations teams. - The tool shows real‑time metrics such as successful vs. error transaction counts and per‑request latency, helping ops detect performance problems like a 10‑second response time that would be unacceptable in production. - By centralizing DevOps diagnostics and performance data, D‑Pod speeds up problem determination and reduces the need for manual log‑ins to individual DataPower GUIs. ## Sections - [00:00:00](https://www.youtube.com/watch?v=_mT8H--LFMI&t=0s) **Introducing the DataPower Operations Dashboard** - The speaker showcases DPOD, a unified console that simplifies monitoring and troubleshooting across all DataPower environments, demonstrated by a developer pinpointing a schema validation error in a failed API request. ## Full Transcript
in this video I want to introduce you to
a new exciting product called data power
operations dashboard or d-pod for short
it will make managing your data power
gateway environment a lot easier for
both developers and operational folks
d-pod provides a centralized console for
troubleshooting DataPower transactions
across your environment and provides
DevOps information to enable quicker
problem determination it works with all
data power form factors such as physical
appliances virtual appliances Linux and
docker and it supports all currently
supported firmware versions I know this
sounds very exciting
so let's see d-pod in action consider a
developer who is writing API services
and starts testing his implementation he
opened up his test tool and sends a
request to a data power service but gets
an internal error there's not much
information about why this request
failed
now you could log in to your data power
GUI but you may not have access now
lucky for me I have data power
Operations dashboard so I will log in
with my developer account and as you can
see once I logged in I get a quick
dashboard about my environment the
number of successful transactions and
the number of errors that have occurred
now I'm more interested about
troubleshooting so I'll go in to the
last request that was received and I'll
click on the transaction ID here and you
can see that in this transaction
analysis the reason why my transaction
failed was due to a schema validation
error so if I scroll down a bit I'll see
perhaps what element could have caused
that error and you can see by this
message that it bounced date was
expecting the next item to be City so if
I go back to my test tool and look at my
request I'll add a city tag here now I
don't put me to put anything in here for
now and so I can just test it out and
you can see that I now have gotten a
proper
and I can go back to the data power
operations dashboard look at the last
time transaction that came in after
refresh and you can see that this time
there was no errors that occur and this
transaction was successfully processed
what is really neat about deep hug was
that I was able to troubleshoot this
issue without any administrative
assistant it was a self-service
experience d-pod in addition d-pod can
also be configured to just show the
services that i should have access to
alright let's try another request this
is a service that will return me a list
of drivers now it's something that I'm
just testing out before I actually
leverage it inside of my mobile
application so I'll send a request and
as you can see that it hasn't completed
yet now I'm going to wait a few more
seconds here hopefully it finally is
able to execute oh there we go so now I
was able to get back a response but you
can see here the time it took was 10
seconds right so clearly this is
unacceptable now this could potentially
be an issue that happened in a
production or staging environment so
your operational folks will need to be
involved to troubleshoot the issue so
I'm going to log out on my developer
account alright and put on my Operations
hat and login with my administrative ID
so you can see here that there's a lot
more options I have available as an
admin so I have dashboards that show me
a lot more information about my
environment investigate explore allows
me to see the configuration of my data
power services reports allows me to
generate reports and then man manage
allows me to manage the d-pod
environment so for now I'm going to go
back to investigate and you'll see that
the transaction I'm interested in is
this sub service proxy and you can see
that the elapsed time is 10 seconds if I
click on this transaction here you'll
notice that there's no error detected
because the transaction did execute but
you can see that the actual time data
power took was very small and that the
majority of the time spent
was in the backend so about 10 seconds
right so this clearly indicates that the
issue is not in DataPower and rather the
issue is in the backend service so no
change needed on data part for this
issue I'm going to call the backend
service owner and tell them that he has
a performance issue I'll go off and grab
a coffee and say thank you d pod