When UI and API testing meets Service Virtualization – A paradigm shift for continuous testing. Video Lecture | Automation Training with Tosca Testsuite - Software Testing

welcome everyone to today's MOOC session
on when UI and API testing meets service
virtualization a paradigm shift for
continuous testing before we begin let
me first introduce you to our hosts for
this session my name is Lydia Wazir and
I am a training consultant at the try
scientist Academy
joining me today is Albert vac know who
is one of our knowledgeable product
managers for API testing and service
virtualization Robert has been with try
centers for over nine years before we
start looking at how UI API and service
virtualization work perfectly together
interesante is Tosca let me first
discuss some general housekeeping rules
for those joining us for the first time
please note that all participants will
be muted during the session as there are
many of you currently attending everyone
talking would be confusing and hard to
follow there is a control panel at the
bottom of your screen with apps you can
toggle on or off key ones being QA
twitter share and the media player even
though you are muted we do encourage you
to ask questions during the session
please use the Q&A box there will be a
Q&A session at the end of the MOOC and
we will hold the most interesting
questions for the question-and-answer
session so that everyone can profit from
the answers we will try to answer as
many questions as possible during this
session but please be aware that only
questions related to the current topics
will be covered please also keep in mind
that given the number of attendees we
might not be able to answer all of your
questions during the session lastly this
session will be recorded and will be
shared on our website later this week as
always if you stay with us till the end
of the session you'll receive vouchers
for two free courses in a separate email
after the session is over I will now
hand over to Robert who will introduce
us to this interesting topic thank you
very much Lydia thanks for an
introduction and yeah I'm Robert I'm
responsible
for API testing and service
virtualization and I want to speak how
these two topics were perfectly together
and especially also when it comes to UI
testing and is this really a paradigm
shift for continuous testing because we
will see that will convey well can reuse
a lot of test artifacts even for
different teams and share it all across
the company but before I do a demo and
hands-on in our product I want to give
you an unsure though with you about what
we understand with test-driven service
virtualization for those of you guys who
are familiar with Tosca you guys know
that Tosca basically executes tests from
a client perspective like in my screen
here on the left side it could be a UI
test case an API test case file batch or
any other technology which does some
input on a system on the test which
means a in this case is our system on a
test and when we ever do some input on
the system on a test it can potentially
send some requests to a back-end system
which is in our case a CRM a rating or
an other service
so with Tosca you can do the UI testing
and I'm pretty sure you have seen this
already somewhere or just check out the
other MOOCs where you can find more
details about UI testing and also for
API testing but we are focusing also in
this course on service virtualization
and we basically can put osv in between
our system and tests they require peckin
systems which means we can record the
traffic and in case these systems are
not there yet we could also create
create this from scratch by for instance
scanning a whistle a rumble or any other
definition depending on the service in
the backend and once we've recorded it
we'll be able to replay it or simulate
these messages with osv which means we
can pick up for instance a request we
analyze it and we'll check always we
will then generate a response in order
to mimic the real system behavior for
instance like the serum service or
another case for instance we can include
functions which are not there yet for
instance we have a rating service and
it's getting be extended with additional
functionality but it's not there in the
real application we can model it in our
service virtualization product we will
see this how this looks like in the demo
afterwards and of course you also can
not only include functions you also can
do more like variants or test data add
them to the backend services in order to
test deeper and you can share all of
these test artifacts all across your
teams because we will see for instance
that if you implement the service
oriented architecture component you will
always have a couple teams involved
which have different goals and different
obstacles so this is what we understand
with test-driven service virtualization
which means post-chorus the input on the
system under test and osv is
virtualizing the backends so when we
speak about collaboration across teams
it's not only that we have a common
repository where we can share test
artifacts it's also that we can for
instance reverse calls like in this case
tasks of performance like a like in the
example before to the system on a test
and this triggers some requests and
responses in the backend but we then can
reverse these messages and not use it
for virtualization but for API testing
which means in the first scenario we
virtualized that we can test our
application on a test system heat a
system aid sorry then we have system B C
and D as well and we can use the
captured messages and reverse them and
fire them against the remaining systems
on the other side which is the backend
alright so let's move into the tool into
Tosca and I've prepared
an example for you which is our
insurance calculator application and
what you see here it's basically set up
it has a user front-end which runs in
the browser and whenever you trigger
something in the browser it will fire
some calls to the backend and we in our
example we have team one and therefore
I've prepared all there already a couple
of UI test cases and these UI test cases
will be executed on the user in front
end but the problem is if the backend
does not behave as we expect that will
run into issues when we try to execute
for instance please put this process
which consists in the first step select
a vehicle or a car select the customer
save a customer and so on and so forth
so our test focus for team one is to
test the front-end and the problem is
their back-end does not always respond
as we expect it and whoever did some
test automation up front on the UI level
if the backend is not doing what the
front and automation requires this is a
potential blocker that our automation
breaks and which means with with a lot
of this potential showstoppers
continuous testing is very hard to
achieve and probably actually impossible
for instance in our example I have the
other engine for instance if it has a
bug it potentially causes a different
behavior when we execute our UI test
case and we will have them Falls errors
for instance and we will have more
investigation efforts even our system
was completely fine or for instance the
rating service has some test data
containing we are not expecting for
instance we persisted a customer we
saved a customer yesterday already then
we cannot save it twice probably and
this will cause a different flow in our
automation or for instance in our CRM
service is currently on the maintenance
and doesn't respond at all then we
cannot get we cannot get for instance or
what this
customer steps all for instance another
example could be if the vehicle services
of third-party service and they charge
us for every time we are sending a call
to the system like hundred bucks then in
many cases the test the testing will be
have to walk around this because testing
will just be too expensive to be
executed like with every check-in so
these are potential blockers and I
created upfront UI test case here and
for those guys who did the MOOCs about
your eye testing this should be familiar
and toska you know you have everything
in steps where certain values are insert
into the user interface and by executing
all these steps we basically complete in
the process I just described in my
screens before alright so before I start
I want to give up on and introduce you
first into our transient this monitor xx
present this monitor is basically just
for our demo application a beckoned
system where it can switch on and switch
off certain services in order to
simulate some in stable behavior systems
for instance it does not live it does
not belong to the try centers product
but we're using it for our demos all
right and we've seen Tasha come on
already
so that's the OS v monitor and in do is
V monitor I will see if I have uploaded
something I also can configure for
instance endpoints and this is what I
did here I created here an environment
and this environment contains the so
called service ports and I've created
service ports for my car service for my
same service for my rating service and
for the order service and these services
are HTTP based the listening on this
port and they will redirect for instance
call to the real application which is
basically it
exactly these end points here so I have
60,000 and five for instance for the
order service and as soon I've
configured a real service it is possible
for always V to forward these messages
to the real service pick up the response
and to record and capture the traffic in
between these applications so let me
just minimize a little bit this
application and let's open the browser
and I will navigate now to my system on
a test which is the the insurance
calculate the service and when I click
on get unquote it brings me to the to
restart the page what we have to come to
the first input for instance the vehicle
make for instance and if I turn down for
instance the car service and I will
choose this option then I can see here I
cannot access these controls here and I
also get like an error that this service
cannot be reached so that's a problem if
you want to do automated testing because
at this stage our automated test case
would expect to have some numbers of
seeds but it doesn't but what we can do
here is we can capture the traffic once
the service is up and running or we can
create it also from scratch but in this
example I will record it and therefore I
simply activate the start recording
button here in osv and when I pick for
instance Volkswagen I can see here on
the backend it receives the call to the
peckin and it also always vs captured
for instance to two messages and when I
stop recording I just double click this
and I can see that a capture for
instance their request from Volkswagen
to the back end and the back end
responded for instance with the make
with seeds and the food types which are
provided for
instance for folks on and so I can
verify this um on UI level so what I
will execute not a food test case and I
will activate the recording here in OS v
and always we will capture the whole
traffic and it will help us later on to
replay the whole testing on the UI
without the need for the backend which
makes us pretty much independent from
broken back and services as I described
initially in the first introduction
all right so let's execute the test case
I will start recording now and I should
see whenever messages are captured in my
back end so it should open the browser
now you go so the test case navigates
through the application
it's peeking folks wagon for instance we
can see the call on the right side in
the monitor we can see a couple of more
calls
okay so the test case has been executed
and we can see we have in our oh is the
monitor we've captured 14 messages so
the test case went through which means
the peckin was there and then we had a
good day but from now on even if the
peckin is not available we can still
continue to test our UI because we have
captured the messages you know sv and in
order to make this work i will now
import these messages into SV therefore
I switch to the ribbon click on record
state full because I need a stateful
scenario because I also have to say for
instance a customer or whenever
something needs a bit needs to be
changed from test data perspective for
instance or a certain flow needs to be
followed we treat this as a stateful
scenario while requesting response bears
are very limited to input and output
behavior for requests and response only
so let me import this it asks me if I
want to clear the recorded messages and
here it is asking me if I would like to
have the business parameter created
automatically and this is a early above
the feature for 11/0
you can activate it in the Tosca options
but by default it's not activated but
what it will does what it will do will I
will show you later and I click yes
so what I get here now is this scenario
these are the same messages I just
imported and recorded from osv and if I
click on a sequence flow it shows me as
well the sequence which has been
generated while executing my UI test
case and we had some funny situations
there a customer's for instance when we
did like a pilot demo for instance where
the customers have realized that the
flow is actually not the same as they
were expecting it so you can use also
this feature
to do like reverse engineering of your
bacon systems you can print this for
instance as PDF and so on and so forth
and can have a closer look on these
message flows but yeah having that said
we can upload these or is this scenario
to osv again why we're even importing
this to Tosca
it is because the whole maintenance is
done inside Tosca so we get all the
models here we get like these so-called
scenarios which are basically contained
in test cases but from there you can
link it to requirements you can link it
to test case design or execution lists
and so on and so forth so that's why
we'll bring it in - Tosca commander we
also have a feature to push directly
into is V but I will not have a look at
this in this MOOC session today all
right so let's deploy this scenario in
[Music]
OS V we can see we have this scenario
available here now and yeah this
scenario which is uploaded is life as
soon it's uploaded and I can rerun my
test case without the need for the
peckin systems anymore so I can now turn
off for instance these your M or rating
service for instance and the whole test
case should run even without the backend
services available okay this test case
again so just look on the right side
maybe I'm clear and clearing the lock up
front so there shouldn't be any lock
entries now for the back end
you
all right
so the test case has been completed we
checked and verified all controls we
wanted to verify even we have no back
and away legal and this is what we call
test case driven service virtualization
which means we have our service
virtualization which follows this flow
and the test case it serves this test
case for instance which exactly creates
a quote and if we want to do this for
delete order for instance of a search
order we just would do the same just
execute the test case enable recording
and then import it to Tosca
upload and replay it but let's have a
look more in more detail on these
scenarios here for instance I have
reshaped the basically the same scenario
just recorded but I put for instance
some folders around it and I give it
better better speaking names for
instance so it looks more nice and
that's not all what I did I also did for
instance I added here also verification
points which means you know SV if you
have a look at the scenario in the very
first step we have action mode which is
called weight on this means whenever a
message comes in to the resource with
car service OS we will detect this it
will buffer a session ID and it will
verify if folks wagon was to make and as
soon this Peckham Metro was true it will
respond exactly with the message as we
design it here maybe we have a look at
the recorded example from before we will
see that we only have the session ID in
here but when I switch to the technical
few I can see that I have a payload in
here so if I right-click jump to module
I can use the pretty print function
so I can read it a little better I can
mark for instance in the payload what I
want to use and I click for instance at
its business parameter so what then is
happening is I for I for instance add
some business parameters and by using
these business parameters I can
parameterize my scenario for different
situations for instance if I go here and
I would not use Volkswagen but for
instance BMW and let me just complete
the values by clicking on values for
instance you could also paste a message
from clipboard which is the same
structure but let me switch for instance
to the technical few so what you see
here then is the make has changed to BMW
this means you record the scenario and
you can add additional fields in as
business parameters and once you have
business parameters available you can
set here any name you like for instance
I will just switch to any when I switch
the technical few I will see I have any
in here so you have only one module and
one test case but you can link it for
instance a test data sourcing can create
a lot of different variations for your
service and for instance if you want to
reduce or you to remove the seat for
instance you can simply remove it and
what happens it also when it's from the
payload so you also can organize your
payload dynamically all right so having
said this about the business parameters
you basically can type in any values you
can do random functions anything or date
functions anything you need anything
your know from Tasker from T box can be
used here as well so you can see here
for get person for instance the session
identifier identifies again the scenario
and it verifies for instance first name
and last name we could potentially also
buffer the value here and insert here as
a buffer value again
and also the whole flow basically can be
changed and remodeled as you need it for
instance you can move and you say you
want to have this erm service should
come off this dis your M rating let's
find - you don't need to program code it
it's all drag-and-drop and copy/paste
but let me upload this to SV again and
let me remove the previous scenario we
see we have now this scenario available
here and I will execute my UI test case
now step by step right here this so let
me just let's go to the product data and
I will run this in my sketchbook and in
the meantime we will in the in the
interval stop and then we will have a
look in the OSD monitor and see what's
going on in the monitor
all right it should stop here now we
will execute the rest later and you know
in the available tab is everything which
is available but it has not been started
which means that's logic which is
available in OS v and you can upload all
kind of scenarios and if you switch to
the pending tab you will see that there
is currently a scenario pending why we
introduced this pending because some of
these scenario flows can last even four
days if you think about banking and in
the financial sector sometimes you have
like settlement dates and sometimes
these scenarios are pending for even
days then osv will keep track of it and
of course also if you have like
scheduled messages then these messages
remain in the scheduled status they will
lie in a database until until the
scheduled date has been reached and then
the message will be sent and the
scenario will be continued but we see on
top here already that we have a Greek as
an aggregated result an error so let me
expand this and we can see the problem
did not happen in step one or two but in
step number three we obviously have a
problem and I can now drill in to this
with by clicking scenario details and
when I jump to step number three I can
see that for instance first name was
expected to be Shara
but their received well he was John Snow
so which means we the virtualization
worked fine but the values were
different to the ones we were inserting
but of course in this example we just
had wrong test data but just consider
this for instance if like upper case
lower case verification for instance is
some has some unexpected offer instant
state formats verification is quite easy
by doing this and you know we don't need
to have a look in step 4 but in step
number 5 we have the same problem the
birthday is fine go to the engine
performance but again the user is wrong
and we can see the problem is consistent
over the whole process even at some
verifications more verification that's
done I find you also can upload for
instance xst schemas and which means if
there is a problem from a validation
perspective it will be also in here
listed as an error and we can see here
the stamina are still pending step 11 to
14 have not been executed yet and we
could now set it manually to some but to
some status and put it in to complete
the tab where we have the previous
scenario which was fine but we have no
verification points in there you can see
that here there were no verification
point but let me just continue the
remaining steps so there's the price
option which means we can simply
continue the test case it should bring
the browser now in the foreground and it
will complete the order
all right so when I click here and
refresh I can see I have this scenario
active in order by the way you can drag
and drop these columns on here and then
you can see you have more or less like a
filter you also came for instance filter
for certain values or you can insert
some verifications you should give it a
try it's at least when you have like a
couple hundreds or thousands of messages
process this is very helpful for your
investigation or for sorting to look for
searching and filtering the right
messages all right so we see that we
have also problem in step now in a very
almost last step in step number thirteen
and I can check but it's again the same
issue you can see also error
investigation is very effortless it
aggregates the result for instance on
top so you would not for instance have
to investigate find process the
successful process messages just real
down why you need to know what a problem
was all right so that's about service
virtualization and as already mentioned
from here the story continues as you're
probably familiar with Tosca link it to
requirements link it to test case design
and so on and so forth and you can see
here as well also T who is V scenarios
are don't look too technical even in the
background for instance let me just have
a look for the order service which is
little more complex than the rest if you
switch to the technical view you simply
will have for instance the in the
technical view the representation of the
XML it could be of course all to text or
JSON and by navigating with the business
parameters you see exactly which values
have been verified or where these
business parameters are pointing to the
idea behind this business parameters is
also
only to expose the functional relevant
parts and business parameters can be
created for any field here you can use
create business parameters for methods
and points resources HTTP headers but
also param which are more relevant of
course for rest services okay so let's
continue with our story so we could now
eliminate these potential continuous
testing breakers by simulating the whole
system with OS v so team one can do
continuous testing from now and they
have printed back in for their test
cases completely in their control they
can adopt it can rich it with different
variations and so on and so forth but
the problem is who is testing teams to
business logic now and these guys need
to test their system as well but for
them the UI probably is the showstopper
but what they can do is and like in my
production I was talking about team
collaboration and reusing artifacts so
what we've just recorded can be reversed
for API test cases so that's pretty
that's that's really a cool that's
really a cool function because remember
we created this for our service
virtualization purpose and we can take
it simply now and convert it into an API
test case you see you have the host the
host scenario I captured during
recording I have now also available for
API testing which means tip team two
which is the beckoned team or also the
EPI gateway team or the Enterprise
Service bus team but whoever who is
responsible for the Gateway or for the
business layer they can use exactly the
same flow the UI team just captured by
executing their UI test case so there's
no need for modeling this manually but
like in this case we know SV
we had to buffer the session ID and I
will change this now to insert and I
will generate a random ID in this case I
could also insert a fixed value but
let's generate a ten digit random number
and in a response I need to simply
buffer this session ID because the
service will return it with a buffer it
and here we will just insert it and
that's that's basically it and there are
a couple more for instance for saving
person I've prepared an example where I
completed this already but from from a
testing perspective and if we have a
look at the modules these are modules
and test cases which should be able to
be executed as they are for instance
yeah let me just run this against the
our application here but of course I
need to turn on the backends because we
want to test now the bacons so let me
run this and why doing API tests for
beckon testing the reason is what simple
you can execute them earlier they are
much faster as you can see here this
were executed with now within a couple
seconds while the you IITs case for
instance runs much longer and of course
it's also usually not that stable as for
instance API test case is hard and as
already mentioned I would for instance
have to create like the ID because the
expected value in there was been has
been generated while I was capturing the
initial question and the actual well is
this one so we probably need to update
our test case in order to have the right
verification here like in this case so
we probably have buffer the ID here and
then
need to save you need to use the order
ID which is buffered so I'm calling it
off here that's how you insert the
buffer and it should be now run through
without any verification issues okay
okay we have also in the last response
we forgot for instance to kayak also
this verification number here so I need
to add this as well yeah
Tosca just tells you what you did wrong
and this is quite easy to find out let
me run it again and now it should be
great here we go so what we did is we
took the captured scenario we convert it
with one click into an API test case and
which means these guys can also test
their back-end system with every check
in regression for instance out of the of
the efforts team a four date for service
virtualization and that's pretty cool
that these artifacts and these test
cases can so easily be reused for also
testing the opposite system and this is
very valuable for testing
service-oriented architectures
especially when you want to do
continuous testing this is also some
kind of an integration up front before
these systems first time with each other
and this helps also to do a lot of
better a lot better results when you go
for instance intake integration or
system integration stage
I have only I have prepared also like a
real world example I've captured
recently in in a in a pilot so this is a
system a micro service based system
behind
a API gateway for instance and this is
only the login procedure and of course
also osv is also capable to do flows
like this all right so that's it from my
perspective now from service
virtualization recording it converted
into an API test case and what I will do
now is you may wonder how this works for
instance 15 - does not have a recording
in place or a service in place which
cannot be recorded at all and therefore
where if the so called API scan the epi
scan is required to do some initial
checks on certain systems for instance
let me remove let me move this so what I
will do now is I can scan for instance
this erm service you can scan for
instance here a we stole a rambo file
and so on and you what you can do here
is you can simply do some trial and
error on a quite light based API scan
the guys have seen the API testing Moop
should be already familiar with this but
I want to show this to you guys because
it also it is also quite interesting to
use this for service virtualization for
instance if you have like a CRM service
and you have some test data to generate
I will simply import this as an API test
case into Tosca I can simply create my
business parameters if you have seen
before already I will set a verification
point as well here
customer result so like we remove this
and I also have here now empty how of a
test case which I could feeling so there
is no XML code here involved so you can
hang this over also to people which are
not so familiar with XML JSON or all the
rest stuff or even no data for instance
and you can link this to a test data
sheet well let me just copy this into my
folder here for instance I have some CRM
test data in here and I want to link
this to my template and therefore I
simply convert it into a template to
test case into a template and drag and
drop this on my template I can see here
I get all the external references which
reference into my sheet and of course I
want to verify if the creation was true
or successful and I want to give you a
hint because your test case instances
will look much nicer if you use like
this feature there is a property called
instance name and if you insert for
instance the external reference it will
have the same value for instance as the
value had in from the otega sheet so
call this last name which means if I
instance see it is now I get like test
cases for all the guys I had in my test
sheet ok and by putting these external
reference they Excel references in my
properties I also get much better
speaking names about my test cases and I
should be able now to run this against
my CRM service for test a CRM service
for instance or for generating test data
and this is the reason why you should do
you do it with dpi engine because it's
much faster compared to using UI but a
good thing here is it's not post any
possible to do API tests now you can
convert this again in two hours via
scenario and if you do the instantiation
here of this always via scenario we see
that we get like service virtualization
stubs for all the employees so this
means when I upload this now to osv I
have a ritual CRM service available let
me give a try let's cheat let's check it
out in in quiz V we can see that we have
also all these scenarios have just
generated they are available and let me
just drill down to Mac's most money you
can see here in the request we have all
weapons which means it will check in the
inbound messages for these and then it
will return for instance true and I'm
quite lazy
so I'll just picking this request from
the preview and I will paste it simply
in to my API skin I was just want to
check and I will send it against this
input which is 10,003 just for you guys
what to make clear where I'm sending
this that's the CRM service and it is
listening on 10,003 that's why I
switched it we have a couple of
possibilities to do this you'll probably
you can check up the knowledgebase you
can redirect as I did here now the
endpoint or you use like an HTTP proxy
but of course this is limited for HTTP
only but for a JMS you would need again
at Jim is proxy cubed or you can
redirect for instance certain calls on
system level but ask your technical
stuff or just
Google how to redirect calls from a
local machine to another endpoint that
something you can configure on the
system level but when I sent this now to
osv I can see already message generated
Patos coquetry the service
virtualization so I can fire this a
couple times and I will see here in my
completed scenario tab that I using it I
have I can see these calls are just
triggered also here in my completed time
so this is how you can create messages
from step for instance import it as an
API test case or a service
virtualization link it to a test data
sheet convert it as you like it and
that's pretty much it from my demo and I
have two slides at the end where I just
will recap this in a in a couple of
sentences then that's it from a milk
today what we're trying to achieve with
this is the HR shift left approach means
when you're in a very early stage and
you have like a system a this could be a
browser and this could be a mobile app
intra centers we support all kind of
technologies virtualized the surrounding
systems we remove the obstacles you're
facing which hinder you to do continuous
testing run this with every chicken
because it's hundred-percent simulated
you can perform it every check-in and no
data is persisted and you have the
system completely under your control
always v is yours so you're not relying
our systems anymore and if you move into
a next stage you can be pretty sure that
your system has been tested very well
and you do some crucial integrations for
instance with system B but you do this
like every sprint if you have like in
your application new functionality which
is mandatory introduced in system a and
system B of course you will have to
check it against
real system B but if system B for
instance is testing the same way you are
testing this you will have much much
better results and as already mentioned
sistemi for instance can share the
messages captured for instance wasting
be in order to do API testing so the
success rate will be very high and this
is also what we see with our customers
which means when you move into a later
stage for instance entering testing or
user acceptance testing you will
experience a much best better system
behavior a much better stability of your
systems because you have liked component
tested your systems in a very detailed
way and you should do in this late
stages of your testing process
exploratory testing and this kind of
stuff you can do still virtualized
third-party systems but ideally you
don't have service virtualization in
place here anymore because in an ideal
world there would newbies would be no
service virtualization as well and if
you could probably you would test in
production but since this is not always
possible I think that's the pressed
approach you can choose and I just when
you go into production you should face
less issues of course and I want to give
you a real world example at the end of
my MOOC when I used to be when I used to
be a tool maker and the technical
draftsman we were visiting the P mu W
factories somewhere in around here and
in Upper Austria and what I've seen
there this was already in the 90s they
were producing engines for p MW and they
had like robots picking up teeth freshly
assembled engines and these robots were
driving through through the whole
manufacturing plant and testing these
engines autonomously and they were
plugging in these engines into testing
stations and you can consider this the
same way what we do with those V we
surround the system on a test which is
in this case the engine but in your case
the application you're developing
and your simulate input behavior and
your measure output behavior and your
tested in a very detailed and very
complex way even if it's stateful even
if it's consuming this data this can be
all simulated and as soon your
application has no verification or
problems anymore you move to the next
stage which in this case probably would
be this engine would be shipped into the
next manufacturing plant where they
assemble the full vehicle and then they
do a test drive I'm pretty sure they do
not put untested or broken engines into
vehicle bodies and so you guys should
not do this either okay so that's it
from my perspective so I'll hand over to
Lydia
thank you Robert this was amazing it's
really fascinating to hear how you have
packed years of experience into one hour
thanks for that I hope I did not
overwhelm you but you can always send us
questions and so on that's force exactly
so we're now at the point where we can
answer some of your questions and as I
mentioned earlier we did keep a few
questions from the session to answer at
the end of the presentation so that
everyone can profit from the answers so
let's go to the first question number
one
do you support OData protocol and si P
oh yeah Oh data is very heavily used for
ACP systems especially the Hana platform
and yeah we support for instance
definition scanning of audit files but
the communication basically is based on
HTTP but yeah we support it we call also
simulate for STP gateways which means
you know if you have like an business
logic in SCP we also can simulate this
with Louis V or test it with our API
excellent this brings us to our second
question how is OS v licensed oh yeah
that's a good question we have many
different approaches in the past but now
we switch to a completely concurrent
user approach which means if you open
and you have the OS V Adam installed it
consumes one concurrent user license
which means if you close the application
the another user can use for instance
the license and the same is for the
monitor which means we have the designer
licenses where you model and maintain
for instance these scenarios but if you
open the monitor you have execution
license and with the execution license
it's also concurrent user base but you
only can check out for instance what is
going on on who is V check results
trigger messages and so on and so forth
but it's all concurrent user based great
thanks for that and this brings us to
our third question from the viewers
do you support API gateways and if yes
which one we don't really officially
support a peek API key twist but
remember the example I showed you this
was actually I think it was a PT I'm not
sure or some rules of gateway so it
doesn't really matter for us
what kind of gateway it is as long it is
for instance a micro service or a
restful gateway we support it because we
support HTTP we support all these
protocols like param Squier e europe
Aram's
json xml so Swift and so on and so forth
so we don't really support specific API
gateways but in general we can say yeah
we support API key twist we can simulate
them full actually that's it great thank
you so I guess that brings us to the
last question we had apologies if we
didn't get around to answer your
questions but let me give you some more
information for our upcoming loops and
where you can submit your questions
let's see the next MOOC on licensing
into our scientist Tosca where and how
to get and activate your try scientists
Oskar licenses will be our first mooc of
the
New Year on January 10th 2018 as always
we will have two sessions to cover the
different time zones and you can already
register for this MOOC on our website
also please complete the feedback at the
end of this session we always like to
hear what you thought of us what else is
there to do let me guide you to where
you can seek further assistance if your
questions were an answer today in our
MOOC let's have a look to see where you
may be able to find answers to those
questions you can link with us on
Facebook LinkedIn Twitter YouTube and
watch our Tosca in a heartbeat videos
you can check our knowledgebase at our
support portal you can contact the
training office at academy at troy
santa's calm and that's it for today
thank you so much for joining us and
goodbye