►
Description
As Telkom Indonesia transforms into a digital telecom company, new strategies have been implemented to create a digital touchpoint to allow Telkom's divisions, subsidiaries, and partners to easily expose and consume their APIs. This initiative required building a standalone billing service. In this Kong Summit 2019 session, Telkom Indonesia Software Engineer, I Putu Ariyasa, talks about the integration between Kong and the billing service by leveraging the Kong Plugins to solve rating limitations and achieve greater capabilities in their platform to support monetization.
#KongSummit19
A
Thank
you
for
having
me
here
such
an
honor.
My
name
is
Patwari
essa
spell
like
that
and
I'm
from
Indonesia,
thanks
for
calling
finally
good
to
get
out
from
Asia
thanks
for
coming
so
currently
I
work,
Indonesia
and
today
I
would
like
to
say
our
experience
in
using
Kong
as
our
IP
I
get
when,
especially
the
monetization
feature
that
we
added
to
Kong
as
our
API
get
ready
so
welcome.
A
Indonesia
is
the
largest
telecommunication
provider
Indonesia,
and
also
the
largest
one
of
the
largest
state-owned
enterprise
in
there
it
it
has
been
around
since
the
colonial
age,
with
only
telegraph
and
post
as
its
main
service,
and
now
it
has
become
multi
national
telecommunication
conglomerate
with
over
around
80
subsidiaries
in
the
region.
So
one
of
the
key
to
its
recipients
is
transformation
and,
of
course,
in
this
digital
age,
where
disruption
can
come
from
anywhere,
transformation
is
needed
them
than
before.
A
More
than
before,
so
tocome
tried
to
become
digital
telco
company
and
have
formed
several
strategies
and
one
of
the
that
strategies
involve
transforming
their
API.
So
why?
Why
transform
the
API?
There
are
mainly
two
problem.
First
is
the
centralized
smart
manner
in
the
API
management,
so
there's
a
lot
of
API
in
Telecom,
spread
among
its
subsidiaries,
its
division,
its
even
its
partner
and
each
have
their
own
way
to
manage
and
serve
the
API.
A
So
this
result
in
redundant
capability
is
created
by
the
API
owners,
even
there's
an
owner
that
need
to
build
the
same
capabilities
over
and
over
again
for
all
for
each
of
their
API.
Then
it
result
in
on
under
the
manner
it
to
in
a
building
and
serve
the
API
some
years.
So
some
years
rests
with
different
level
of
maturity,
some
document
that
appear
and
some
even
doesn't
document
their
api's.
A
This,
of
course,
takes
time
and
in
also
increased
barrier,
for
example,
small
teams
or
a
new
start-up
date
has
yet
to
acquire
a
legal
ability,
so
so
Telkom
decided
to
create
to
centralize
and
digitalize
the
API
management
and
hope
that
any
part
of
telecom
via
the
division,
the
subsidiaries
or
even
it
partner-
can
easily
expose
their
api's
and,
at
the
same
time
provide
easy
cell
surface
access
for
any
interested
party
that
want
to
consume
the
API.
So
how
do
we
solve
this
problem
at
first?
A
We
don't
even
know
that
API
management
is
thing
is
a
thing.
We
thought
that
capabilities
like
authentication
authorization,
is
something
that
you
built
inside
the
API
itself.
So
mostly
at
the
time
we
googles
a
lot
and
after
several
research
we
find
some
things
to
be
prepared.
The
first,
of
course,
the
API
gateway
to
be
the
central
access
to
the
API.
This
Google
results
are
some
product
that
we
can
here
is
here.
So
it's
a
check
like
that
and
then
web
portals.
A
So
we
guess
we
need
to
provide
it
ourselves
and
then
for
further
breakdown
of
this
feature
that
we
had
to
build.
First,
we
need
a
payment
gateway.
This
was
to
enable
user
consumer
of
the
API
to
instantly
pay
the
API,
and
hopefully,
luckily,
our
one
of
our
subsidiaries
have
a
surface
in
this.
So
we
can
use
that.
So
it's
a
check
and
then
the
last
one
is
billing.
We
need
to
provide
a
control
over
the
lower
API
consumption
after
the
access
has
been
granted
to
API
consumer.
A
You
know
we
need
to
make
sure
that
the
value
that
API
consumer
get
from
the
API
invocation
is
equal
as
the
amount
that
they
paid
or
the
amount
that
they
will
pay.
First,
we
thought
that
we
could
just
count
the
number
of
API
invocation
or
use
some
built-in
limiting
scanner
that
mostly
available
in
any
API
a
gateway,
but
within
us,
or
so
it's
API
invocation
alone
enough
to
represent
the
value
that
the
API
consumer
can
get.
For
example,
if
the
invocation
result
in
a
faulty
response,
does
it
count
as
a
valid.
A
But
the
API
invocation,
or
limiting
all
already
increased,
decrease
the
amount
that
API
information
that
can
be
used
by
the
consumer
for
next
time,
but
it
will
likely
have
no
value,
and
then
we
have
an
example
for
for
an
API
that
can
send
an
SMS.
There
is
two:
there
are
two
operation,
the
first
one
is
to
send
SMS
and
the
second
one
is
to
get
the
status
of
that
send
SMS
and
then
the
kirin
API
owner
only
charts
the
consumer
for
how
much
there
is
a
message
sent.
A
Then
if
they
request
a
status
it
was,
it
was
free
free.
So
if
we
were
to
expose
this
API
into
our
API
gateway,
we
need
to
do
the
same.
We
need
to
only
charge
when
the
SMS
is
being
sent
and
not
charge
when
the
status
endpoint
is
involved.
We
also
need
to
consider
a
different
amount,
a
different
value
that
API
represent.
You
know,
for
example,
an
API
can
be,
but
can
be
given
to
a
consumer
consumer
with
different
kind
of
deals.
You
know
consumer
get
price
and
and
consumer
B
get
price.
A
B
is
something
like
that
and,
of
course,
a
different
API.
Will
have
a
different
value
in
sending
an
SMS
will
be
cheaper
than
sending
a
voice.
Miss
aids
like
that,
so
that
what
was
uncertain
back
then
so
replace
how
do?
How
do
we
rate
and,
if
necessarily
limit
the
API
call
based
on
their
monetary
value.
This
is
a
requirement
back
then,
and
this
was
uncertain,
but
despite
the
uncertainty,
we
decided
to
just
get
right
to
the
experience
to
better
learn
from
the
experience
we
pick
one
of
the
open
source,
API
gateway,
not
count
like
that.
A
We
haven't
met
count.
The
reason
why
we
picked
this
is
because
it
has
many
features,
include
some
portals
and
also
a
swagger
definition.
So
at
the
same
time,
we
have
a
way
to
standardize
how
we
define
and
document
the
API.
Then
we
create
our
own
billing
service
and
we
decided
to
use
the
swagger
the
matching
swagger
operation,
to
give
a
rate
to
the
API.
A
For
example,
the
invocation
that
match
get
SMS
will
be
0,
but
the
invocation
that
match
post,
less
SMS
will
be
300
like
that,
and
then
we
associate
nepia
multiple
plan,
so
the
consumer
can
have
a
choice
to
what
land
they
subscribe.
Then
we
add
some
kind
of
wallet
to
the
subscriber
for
the
rate
limiting
scenario.
A
Every
time
Valley
was
given
to
the
consumer.
The
wallet
will
be
decreased
like
that.
So
how
do
these
two
service
play
together?
So
we
added
a
handler
to
the
API
get
raised
so
that
every
time
a
request
come
we
send
a
charge
request
to
the
billing.
The
charts
contain.
Several
data
is
just
publisher,
his
name
API
name.
It
version
the
subscriber
username,
the
API
ID
and
the
matching
swagger
operation.
Then
our
billing
will
look
up.
The
matching
rate
then
apply
some
rate
limit.
A
If
it's
configured
like
that,
then,
if
the
charge
is
success,
the
API
get
we
can
forward
the
request
to
the
API,
but
if
the
charge
is
was
failed
because
limit
is
Richard,
something
like
that,
the
API
gateway
will
send
will
terminate
the
request
and
Aaron
responds.
If
the
API
invocation
is
regarded
as
faulty
one,
it
will
send
a
refund
request
to
recover
the
amount
that
was
charged
before
so
does
it
work
yeah
it
kind
of
does,
and
the
surface
are
still
running
currently
what
we're
going
to
face
that
out.
A
But
we
found
some
cert
Cummings,
the
first,
the
API
good.
We
don't
have
many
features
for
us
back,
then
it
was
monolithic
one.
It
is
hardly
extend
the
API
to
extend
the
business
process
beyond
what
define
it
in
that
a
big
API
gateway.
For
example,
we
we
are
stuck
with
o2
authentication,
we
even
it's
hard
to
not
use
authentication
at
all.
That
is
very
pretty
hard
like
this,
because
it's
monolithic
and
then
that
rating
mechanism
that
we
defined
earlier
was
insufficient.
A
Of
course,
the
the
swagger
operation
is
enough
for
something
so
simple,
but
for
something
order
that
complex
it's,
unfortunately,
not.
For
example,
the
API
is
the
API
that
send
SMS
earlier.
We
later
realize
that
the
number
of
SMS
that
can
be
sent
is
more
than
one.
So
if
the
SMS
that
was
saying
is
2
or
3,
we
need
to
charge
twice
or
Trice
the
the
amount
and
then
and
luckily
that,
how
much
multiplication
that
we
we
can
do
to
increase.
A
The
mounted
chart
is
should
be
to
the
number
of
SMS
that
can
be
delivered
to
recipient
Gina
and
that
amount
can
only
be
found
after
the
operation
is
complete,
so
so
to
be
able
to
support
this,
we
need
to
inspect
the
respond,
at
least
assuming
that
the
API
rest
and
some
info
or
hint
about
how
much
the
operation,
how
much
the
SMS
percent.
So
the
church
scanner
is
based
on
the
respond
data
and
last
we
have
an
API
to
send
a
voice
message,
but
the
API
is
only
scheduling
the
job.
A
This
the
voice
will
be
sent
some
time
later,
even
after
the
respondents
sent
back
to
the
consumer.
So
that
is
so.
The
the
last
scanner
is
based
on
an
asynchronous
operation
initiated
by
the
API.
So,
based
on
this,
we
decided
we
can
do
no
further
with
the
current
set
up
and
try
looking
for
new
way
to
do
things
and
that's
when
we
find
calm,
we
love
the
plug-in
system
with
how
easy
the
configure
call
back.
A
Then
it
was
0.11
version,
the
version
of
0
11,
and
then
we
love
how
active
the
community
and
awesome
the
community
is
and
that's
when
we
decide
to
move
the
API
gateway
to
come.
Of
course,
if
we
move
the
API
gateway
to
come,
we
need
to
rebuild
everything
here,
reveal
the
Poulter
rebuild
any
supporting
components,
but
at
the
same
time
we
have
the
opportunity
to
leverage
other
technology,
others
supporting
technology,
especially
the
open-source
one
given
fat
fancying
this
time
and
apply
some
best
practice
such
as
microservices
container
and
CI
CD
for
better
development
process.
A
And
of
course
the
main
point
is
we
are
able
to
enhance
the
billing
and
integrate.
It
fee
account
plugins,
and
this
will
be
the
main
point.
So
first
we
enhance
the
billing.
The
first
thing
we
do
is
to
hand
saying
the
and
send
something
internal
like
rewriting
the
code,
choosing
a
better
story.
It's
for
right,
look
up
and
limiting.
We
use
Redis
cluster
in
this
case,
then
storing
time
series
data
even
API
invocation.
Even
that
is
record
that
was
recorded.
We
call
it
a
transaction
and
make
sure
that
the
surface
is
horizontally.
A
Scalable
then
the
second
one
we
did
is
we
refactor
the
charts
API
so
that
the
amount
charge
of
the
rate
that
is
apply
it
can
be
modified
by
by
the
consumer
of
the
charts
API.
This
is
mainly
by
passing
some
arithmetic
operator
and
modification
values
as
replaced
by
zero
replaced
by
one
or
at
200
to
the
curative
rate
or
multiply
to,
and
this
was
supposed
to
be
counted
by
the
dependent
surface.
A
In
this
case,
our
API
gateway
come
and
then
it
is
also
possible
to
require
this
external
rate
so
that
if
the
information
is
not
available,
dependent
service
can
defer
the
chart
until
the
information
is
felled
and
then
we
add
a
date
detachable
flag
to
the
rate
to
signal
the
the
dependent
surface
that
the
charge
can
be
done
even
after
the
respond.
It's
coming
for
a
synchronous
operation,
some
kind
of
flag
like
that,
then
we
add
plan,
light
panel
access
control.
A
It
was
not
added
to
the
building
inside
because
we
have
another
surface
for
access
control,
but
this
were
pointing
because
even
if
we
try
to
transform
everything
into
digital
there's,
still
business
process
that
needs
a
manual
metal
back
manual
job
to
do
before
allowing
API
consumption.
So
that's
what
we
do
to
our
billing
enhancement.
Then,
of
course
he
made
some
plug
in
the
first
vlog
and
we
decree
it
is
just
to
play
nicely
with
the
previous
business
process
that
were
defined
in
the
previous
API
gateway,
yeah,
publisher,
name,
API
name
API
version
to
convert.
A
Then
we
add
subscriber
user
name
and
ID
the
consumer.
Then
we
store
that
data
into
some
certain
dictionary
under
annex
the
chat
X
for
later
use
by
other
plugin.
Then
we
added
a
plug-in
to
match.
What
is
what
the
queuing
operation
based
on
the
swagger
data,
so
API
is
what
we
call
API
is
equal
Kong
root
with
a
static
path.
You
know
slash
the
API
names
less,
the
API
version
and
then,
after
that
the
plugin
will
process.
A
Then
the
rest
of
the
request
URL
using
radix,
ready
3
to
avoid
match
to
avoid
racket
to
match
the
swagger
operation
that
B
is
being
involved
at
first,
we
were
registering
multiple
swagger,
so
multiple
paths,
the
root
to
call,
but
if
we
will
define
an
API
can
maybe
I
will
have
many
operation.
We
don't
think
that
is
scalable
to
do
reject
match
for
every
API
invocation.
Then,
of
course
we
store
the
match
in
ngx
that
gtx
for
a
lighter
years,
then
we
added
a
plugin
to
dynamically
process
the
request
and
respond
data.
A
A
We
we
choose
this
plugin
because
which
is
this
language
because
is
easy
enough
to
port
its
its
provide
a
flexible
operation,
but
it
is
restricted
because
the
API,
the
API
popping
operation,
will
be
done
by
each
of
the
API
owner.
So
we
don't
want
to
say:
let
them
include
some
endless
loop
or
something
like
that.
The
the.
A
Requests
will
be
like
that,
so
in
this
way
we
can
inspect
respond.
We
can
expect
the
request
and
we
we
can
store
something
and
you
NGH
to
take
so
that
it
will
be
available
for
the
next
plugin
and
the
last
plugin
is
the
billing
plugin.
This
was
to
operate
to
integrate
with
our
billing
service,
the
the
billing
will
honor
us.
A
The
building
will
extract
the
previous
data
that
was
sent
set
by
the
previous
plugin,
the
metadata,
the
regular
operation
and
external
data,
external
rate,
data
that
might
be
set
by
justin
logic
or
maybe
another
plugin,
and
then
it
will
send
a
charge
request.
Then,
based
on
the
response,
especially
when
external
rate
is
required
or
the
rate
is
detachable,
it
will
add
additional
data
to
the
upstream
surface
so
that
the
api
can
know
what
is
the
current
status
of
this
billing
invocation?
A
What
is
the
rate
ends
so
that
it
can
manage
how
much
it
should
be
charged
and
then,
when
the
response
come,
it
will
either
do
a
refund.
It
will
if
it
was
fail
or
charged,
because
if
the
charge
the
previous
chart
was
different,
because
there's
no
external
rate,
something
like
that,
so
when
external
rate
is
available,
the
building
the
plug-in
will
charge
the
billing
as
much
as
the
data
that
is
given
by
the
API.
A
This
was
to
overcome
the
rate
that
is
to
be
computed
by
request
or
respond
data,
and
then
the
last
one
when
some
operation
is
completed,
some
background
operations
completed
in
the
API
system.
The
API
concern
charge
requests
to
come
with
GWT,
that
is,
that
was
sent
previously
by
when
the
request
gap.
So
as
long
as
the
GWT
is
valid,
the
charts
can
be
done.
This
was
to
enable
a
synchronous,
charts,
a
synchronous,
operation,
charts
so
yeah.
A
That's
it
that's
the
plugin
that
we
did
Bill
and
it
played
nicely
and
the
current
look
of
the
product
that
we
built.
This
is
the
developer
portal.
They
can
see,
explore
the
API
and
then
they
can
see
what
is
the
plan
of
the
APRs
they
can
subscribe,
play,
payne,
stanley
or,
and
then
after
they
paid
they
can
try
using
swagger.
You
I,
then
this
and
also,
if
the
plan,
if
the
subscriber
has
no
permission
to
subscribe,
it
will
say
something
like
contact
as
first
to
subscribe,
so
that
any
manual
business
process
can
be
done.
A
And
then
this
was
the
publisher
portal.
Every
publisher
will
have
their
own
API
their
own
back
and
on
certificate
their
own
domain,
so
that
they
can
so
that
we
can
support
multiple
publisher
but
its
own
data,
and
also
this
will
feature
some
statistics
and
subscribes
and
information.
So
how
many?
How
many
time
the
API
is
in
folk?
How
many?
How
many
do,
how
many
pay,
how
many
repaid
API
and
such
like
that?
A
So
that's
it
I
think
and
the
conclusion
is
we
found
that
for
some
scenarios
to
rate
the
API,
even
by
invocation,
that
is
based
on
a
swagger
operation
based
on
a
request
data
based
on
the
response
that
time,
based
on
a
synchronous
operation
that
can
be
done
later
or
sometimes
and
become
plugins.
The
for
rating
scanner
are
now
supported
in
our
flow
thanks
for
BA
and
thank
you.
A
A
A
B
A
A
C
Since
this
is
a
great
example
of
like
a
critical
function,
custom
plugin
deployed
to
production
I
was
just
kind
of
looking
into
thinking
about.
How
do
you
guys
submit,
deploy
and
manage
this?
You
know
plug-in
code
and
are
you
guys
running
on
docker
and
kubernetes
or
so
on
and
so
forth,
just
sort
of
like
what
is
the
life
cycle
like
for
how
this
a
change
to
this
goes
to
production,
yeah.
A
So
we
are
still
using
the
previous
infrastructure
that
we
use
in
previous
API
gateway,
and
that
is
a
virtualized
machine,
but
it's
service
is
deployed
in
a
container
container
system
and
when
we
deploy
a
comp
locking,
we
create
a
repository
to
install
all
that
complicated
and
package
in
one
docker
and
then
to
deploy
that.
Of
course,
there
is
a
CI
CD
system.
A
We
use
open
source,
one
drone
and
then
after
the
docker
image
is
produced,
we
just
run
a
tariff
or
to
deploy
that
to
fertile
machine,
so
that
still
manual,
of
course,
manual
but
still
enough
reading,
because
there's
so
many
the
surface
our
surface
that
is
set
for
in
database.
We
have
five
database
there,
so
we
can't
really
I,
don't
know
how
to
do
it
in
automated
platforms
that
s
Cobra
natus,
so
we
still
use
VM,
but
we
use
docker
and
we
use
infrastructure
code
to
deploy.