Gitiles
Code Review Sign In
gerrit.nordix.org / onap / appc / b7d8b97e10c62ef446b28fc071bb7536a248a304 / . / docs / APPC User Guide / APPC User Guide.rst
blob: e949515810ba9f721aba5bc6a48b363c36c09ce0 [file] [log] [blame]
Scott Seaboltd9fbc642017-10-24 09:12:13 -0400[diff] [blame]1.. ============LICENSE_START==========================================
2.. ===================================================================
3.. Copyright © 2017 AT&T Intellectual Property. All rights reserved.
4.. ===================================================================
5.. Licensed under the Creative Commons License, Attribution 4.0 Intl. (the "License");
6.. you may not use this documentation except in compliance with the License.
7.. You may obtain a copy of the License at
8..
9.. https://creativecommons.org/licenses/by/4.0/
10..
11.. Unless required by applicable law or agreed to in writing, software
12.. distributed under the License is distributed on an "AS IS" BASIS,
13.. WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
14.. See the License for the specific language governing permissions and
15.. limitations under the License.
16.. ============LICENSE_END============================================
17.. ECOMP is a trademark and service mark of AT&T Intellectual Property.
18
19========================================
20Application Controller (APPC) User Guide
21========================================
22
23APPC Overview and Architecture
24==============================
25The Application Controller (APPC) is one of the components of the ONAP
26platform. It is responsible for handling the Life Cycle Management (LCM)
27of Virtual Network Functions (VNFs).
28
29This document provides an overview of the APPC components that enable
30the LCM operations.
31
32Implementation
33--------------
34The APPC infrastructure is implemented on virtual machines in an
35OpenStack cloud in the Amsterdam release. APPC is created on top of the OpenDaylight (ODL)
36platform
37
38The following diagram represents a non-redundant APP-C deployment.
39
40|image0|
41
42Features
43--------
44The APPC HTTP API supports Life Cycle Management (LCM) commands,
45allowing users to manage virtual applications and their components via
46other ONAP components. Refer to Architecture section for further
47details.
48
49Interface
50---------
51The Application Controller Dashboard interacts with the controller
52using REST APIs and performs actions on VNF/VNFC/VMs, such as snapshot,
53lock, sync, and health-check.
54
55Dashboard
56~~~~~~~~~
57
58To open the Application Controller dashboard, go to:
59
60|image1|
61
62Navigate to the available LCM commands by clicking on
63 **appc-provider-lcm**:
64
65|image2|
66
67Click on the URI of the desired action to open a frame with information
68about the action and an option to try it out. For example, to send the
69action, add the request body as the input parameter value, and click
70**Try it out!**
71
72The following figure shows an example body of a LCM restart request:
73
74|image3|
75
76If the request is accepted, you should see the following response:
77
78|image4|
79
80APPC Architecture
81-----------------
82
83This section discusses the APPC internal components in detail.
84
85**APPC High Level Architecture**
86
87|image5|
88
89Northbound REST Layer
90~~~~~~~~~~~~~~~~~~~~~
91
92This layer is responsible for interfacing with APPC clients, such as SO
93or SDC and others, exposing YANG-based API via REST HTTP and/or DMaaP
94messaging (see the Interfaces Summary section for details). In addition,
95it exposes APPC OAM (Operation Administration Management) APIs, enabling
96ONAP Operations Manager (OOM) or TechOps portal to perform APPC
97lifecycle operations
98
99APPC Provider
100~~~~~~~~~~~~~
101
102The APPC Provider module exposes the endpoints for each action
103supported by APPC. This module uses the YANG model to define the
104YANG Remote Processing Call (RPC) and data model, in other words,
105the input and output parameters for each action. The Provider module
106is responsible for validating the RPC input and for rejecting any
107malformed input. After successful validation, the APPC Provider
108calls the Dispatcher to continue the request processing.
109
110LCM API
111~~~~~~~
112
113The APPC exposes an HTTP API to support the Life Cycle Management
114(LCM) commands sent from ONAP components such as SO, SDC, and the
115Portal. These commands enable the components to request APPC to
116perform actions such as to control, modify, start, or stop virtual
117applications and/or their components. 
118
119A virtual application is composed of the following layers. A Life
120Cycle Management command may affect any number of these layers.
121
122- Virtual Network Function (VNF)
123
124- Virtual Network Function Component (VNFC)
125
126- Virtual Machine (VM)
127
128APP-C supports two types of LCM requests, as described below.
129
130**Note:** For further information about LCM API, including details of
131all the commands currently supported in APP-C and examples of the
132request and response format see the ONAP Application Controller (APPC) API Guide. 
133
134LCM over REST
135^^^^^^^^^^^^^^
136
137LCM command requests over REST are sent to the APPC using an HTTP
138POST request. APPC returns one or more responses for each LCM
139request. 
140
141The APP-C LCM API provides a POST HTTP API endpoint per command. 
142
143An **asynchronous** command, containing an authorized and valid
144request, results in at least two discrete response events:
145
146- an ACCEPT (a synchronous HTTP response) to indicate that the request
147 is accepted and will be processed, and
148
149- a final asynchronous response for the command containing an execution
150 status is sent via DMaaP
151
152An unauthorized or invalid request would result in a single
153ERROR response. 
154
155For commands such as Restart, Start, and Stop, the asynchronous response
156is sent over DMaaP.
157
158A **synchronous** command, for example Lock or Unlock, results in a
159single response, which is either SUCCESS or ERROR. For this type of
160request, the first response is a synchronous HTTP response..
161
162For this release, APPC supports the HTTPS protocol, whereas the plain
163HTTP requests are blocked..
164
165Endpoint format: 
166
167``<http-protocol>://<appc-ip>:<appc-api-port>/restconf/operations/appc-provider-lcm:<command-name>``
168
169LCM over Message Bus (DMaaP)
170^^^^^^^^^^^^^^^^^^^^^^^^^^^^
171
172APPC is capable of receiving LCM command requests as messages on the
173DMaaP bus. In this case, APPC returns one or more responses for each LCM
174request, similar to LCM over REST, while both are communicated over
175DMaaP.
176
177Configure the Read/Write topics for the DMaaP as described in APPC
178Deployment, APPC Available Properties.
179
180APPC client library, embedded into APPC client’s (for example, SO) code,
181intends to simplify communication over DMaaP by eliminating topic
182provisioning at the client site. Refer to
183http://onap.readthedocs.io/en/latest/ for more details on the APPC
184Client Library.
185
186For further information about the request and response format, see
187the APPC API Guide at http://onap.readthedocs.io/en/latest/
188
189Dispatcher
190~~~~~~~~~~
191
192The APPC Dispatcher component processes requests received by the Request
193Handler from other ECOMP components. The Dispatcher checks the
194conditions are sufficient for performing the request and selects the
195correct Direct Graph (DG) workflow for execution or rejects the request.
196When the DG execution is complete, the Dispatching function is
197responsible for notifying the initiator of the operation with the
198request execution result (Success/Error) and updates the VNF
199Orchestration state in Active and Available Inventory (A&AI).
200
201The detailed responsibilities of the Dispatcher are as follows:
202
203- Upon receiving the operation request, the Dispatcher performs the
204 synchronous part of the execution:
205
206 - Starts the operation's time-to-live countdown
207
208 - Queries A&AI to get the VNF type and its current orchestration
209 state
210
211 - Checks VNF\_type-specific rules in the LCM State machine for
212 whether to allow or reject the requested command execution
213
214 - Allocates and initiates an appropriate DG workflow by invoking the
215 Service Logic Interpreter (SLI) framework to start the
216 asynchronous part of the execution
217
218 - Returns a response to the initiator: OK or reject (for example, if
219 the State Machine blocks the operation, no DG or time-to-live, or
220 bad parameters)
221
222 - If the operation is rejected, the Dispatcher generates an
223 appropriate Audit log for the Event and Error Logging Framework
224 (EELF) and the Local Event Journal
225
226- Upon workflow completion, the Dispatcher:
227
228 - Receives the execution results from the DG from the SLI framework
229
230 - Publishes the execution result over DMaaP (success or error)
231
232 - Updates VNF status in A&AI
233
234 - Generates an Audit log for EELF and Local Event Journal
235
236Request Handler
237^^^^^^^^^^^^^^^
238
239The Request Handler manages incoming requests and locks APPC for new
240requests, as needed for operations with a specific command execution
241sequences.
242
243Lifecycle Management
244^^^^^^^^^^^^^^^^^^^^
245
246The Lifecycle Management VNF State Machine enables the Dispatching
247function to determine the validity of the requested operation (desired
248state) as a function of the current VNF state, acquired from the A&AI.
249The State Machine maintains its data (states and valid operations)
250in-memory. At the point of APPC initialization, the State Machine
251constructs a matrix based on the metadata of the current operation and
252the valid desired state. 
253
254Command Executor
255^^^^^^^^^^^^^^^^
256
257Manages command execution queue.
258
259State Machine
260~~~~~~~~~~~~~
261
262The VNF State machine enables the Dispatching function to determine
263the validity of the requested operation (desired state) as a
264function of the current VNF state, acquired from the A&AI. The State
265machine maintains its data (states and valid operations) in-memory.
266At the point of APP-C initialization, the State Machine constructs a
267matrix based on the metadata of the current operation and the valid
268desired state. 
269
270The Service Logic Interpreter (SLI) Framework
271~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
272
273The SLI framework is responsible for executing Directed Graphs (DGs).
274The Dispatcher invokes the SLI framework to execute a specific DG, based
275on the input action. The SLI executes the DG and the sub-DG and returns
276a success or failure response to the caller along with the context
277variables used to exchange data with the calling body (for example, the
278Dispatcher). The caller can use the SLI context to specify data required
279for DG execution. The DG returns the same context when execution
280completes.
281
282Currently, there is a combination of input action specific and/or VNF
283type specific DG’s as well as a DGOrchestrator DG which is action and
284VNF type agnostic. The DGOrchestrator approach consists of the
285following:
286
287- DGOrchestrator DG which:
288
289 - Accepts request from the Dispatcher and converts it into DG
290 context format
291
292 - Calls A&AI to retrieve the inventory for the VNF instance
293
294 - Calls a Sequence Generator for start/stop actions which generates
295 a workflow sequence containing a set of start or stop VM requests
296
297 - Auto-generates a workflow for other requests with a single step
298
299 - Executes each step in the workflow by invoking DG’s to interact
300 with the VNF, OpenStack, or Ansible/Chef servers. These DG’s which
301 are specific to the protocol and possibly action. Some DG’s may
302 update A&AI (such as for Configure) or retrieve the VNF running
303 configuration.
304
305 - Returns success/failure status to the Dispatcher.
306
307In the future, all action/VNF type specific DG’s will be migrated to the
308DGOrchestrator approach.
309
310The following diagram shows the Amsterdam Release DGOrchestrator
311architecture
312
313 |image6|
314
315Westbound Layer
316~~~~~~~~~~~~~~~
317
318A&AI
319^^^^
320
321 A&AI is an ONAP component, which maintains information about VNF
322 instances. APPC uses A&AI as a source of the true VNF status,
323 topology and operational data. In addition, at the end of each
324 operation, APPC updates the VNF changes that result from the
325 operation: for example, VNFC record(s) are added after
326 configuration. The VNF orchestration status is not updated for
327 read-only operations such as Sync or Audit. In the case of the VNF
328 Terminate operation, APPC removes the terminated VNF from A&AI by
329 deleting its Virtual Machines (VMs). 
330
331 The Dispatching function and operation-specific DGs manage access to
332 the A&AI using the A&AI Adapter.  
333
334Southbound Layer
335~~~~~~~~~~~~~~~~
336
337Southbound VNF Adapters
338^^^^^^^^^^^^^^^^^^^^^^^
339
340 APPC uses several adapters to communicate with VNFs. The Interface
341 as a Service (IAAS) adapter is part of the OpenDayLight (ODL)
342 platform, while other adapters have been added by the ONAP
343 development.
344
345Restconf Adapter
346^^^^^^^^^^^^^^^^^
347
348 The Adapter is responsible for configuration tasks, using JSON
349 format, for VNFs supporting Restconf API.
350
351Netconf Adapter
352^^^^^^^^^^^^^^^
353
354 The Adapter is responsible for configuration tasks, using XML
355 format, for VNFs supporting Netconf API.
356
357IAAS Adapter 
358^^^^^^^^^^^^^
359
360 The IAAS Adapter connects APPC with the OpenStack controllers to
361 perform various operations on VMs and VNFs such as Restart, Migrate,
362 and Rebuild. The IAAS Adapter integrates as a DG plugin, while the
363 DGs call the services exposed by the adapter.
364
365SSH (XML/CLI) Adapter
366^^^^^^^^^^^^^^^^^^^^^
367
368 A custom adapter that enables connection to a VNF using an SSH
369 session. It is designed to support CLI and XML protocols, including
370 Netconf. It is used to load configurations and retrieve the running
371 configuration.
372
373Chef Adaptor
374^^^^^^^^^^^^
375
376 This adaptor incorporates a client for an external Chef server,
377 which connects to VNF NB APIs. The adaptor enables APPC to operate
378 cookbooks (Chef recipes) to perform various LCM operations over
379 VNFs, connected to the Chef server.
380
381Ansible Adapter
382^^^^^^^^^^^^^^^
383
384 This adaptor incorporates a client for an external Ansible server,
385 which connects to VNF NB APIs. The adaptor enables APPC to operate
386 playbooks to perform various LCM operations over VNFs connected to
387 the Ansible server.
388
389Cross Cutting Components
390~~~~~~~~~~~~~~~~~~~~~~~~
391
392The Cross Cutting Component services operate across all APPC modules.
393
394Configuration
395^^^^^^^^^^^^^
396
397Used to configure operational parameters of APPC modules based on
398function-specific configuration files, for example:
399
400- ``log4j.properties`` for the logging service
401
402- ``appc.properties`` for core APPC-related configuration
403
404- ``dblib.properties`` for managing APPC database-related configuration
405
406- ``aaiclient.properties`` for managing A&AI-related configuration
407
408KPI Service
409^^^^^^^^^^^
410
411This Cross Cutting component manages KPI measurement, storage and
412reporting.
413
414Enable matrix logs to log the number of hits of the configured method of
415APPC, by configuring the following properties in ``appc.properties:``::
416
417 metric.enabled=<true>
418 schedule.policy.metric.start.time=<time value in hhmmss>
419 schedule.policy.metric.period = 60(interval in seconds)
420
421Security Service
422^^^^^^^^^^^^^^^^
423
424This component implements AAF (Authentication and Authorization
425Framework) for APPC API security. The user provides a user name and
426password in the request that will be validated against centralize AAF.
427[Note: For Amsterdam Releasse, AAF is not used]
428
429Logging Service
430^^^^^^^^^^^^^^^
431
432Implements EELF (Event and Error Logging Framework) to manage and
433generate logs (refer to Logging section).
434
435Data Access Service
436^^^^^^^^^^^^^^^^^^^
437
438Provides access to the internal data store.
439
440Transactions store
441~~~~~~~~~~~~~~~~~~
442
443For each operation request procedure that completes or terminates,
444APPC generates and stores an accurate transaction record in its
445internal database, including:
446
447- Timestamp
448
449- Request ID
450
451- Start time
452
453- End time
454
455- VF\_ID
456
457- VF\_type
458
459- Sub-component (optional) e.g. VFC\_ID/VM UUID
460
461- Operation: for example Start, Configure, etc.
462
463- Result: Success/Error code and description, as published to the
464 initiator
465
466Interfaces Summary
467~~~~~~~~~~~~~~~~~~
468
469+-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
470| **Source** | **Flow** | **Destination** | **Service** | **Port** | **Purpose / Comments** |
471+===================+============+=========================+===================+=============+============================================================================================================================================================================+
472| APPC | -> | A&AI | REST | 8443 | APPC retrieves and updates the VNF data in AAI. |
473+-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
474| APPC | -> | SLI | Java (internal) | N/A | APPC sends the LCM API request to SLI for DG execution |
475+-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
476| APPC | -> | South-bound Adapters | Java (internal) | N/A | APPC interacts  with southbound adapters for VNF Lifecycle Management Actions |
477+-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
478| APPC | -> | NETCONF | NETCONF | 830 or 22 | NETCONF Adapter communicates on port 830 (default) or port 22 (SSH – if set up) |
479+-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
480| APPC | -> | Chef Server | HTTP/HTTPS | 80/443 | Chef adapter communicate on port 80 (HTTP) or port 443 (HTTPS) |
481+-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
482| APPC | -> | Ansible Server | HTTP | 8000 | Port 8000 is used for communication between the APPC Ansible Adaptor and the Ansible Server. |
483+-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
484| APPC | -> | MySQL | Java (internal) | 3306 | |
485+-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
486| APPC | -> | DG Builder | Java (internal) | 3000 | |
487+-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
488| APPC | -> | MD-SAL, Apidoc, Karaf | Java (internal) | 8282 | |
489+-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
490| APPC | -> | DMaaP | JMS | 3904 | APPC sends the Asynchronous responses and Failure events to DMaaP Message Bus |
491+-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
492| Portal,SO, DCAE | -> | APPC | REST/DMaaP | 3904 | APPC receives LCM commands from and makes updates to ONAP components such as the Portal, MSO, and DCAE |
493+-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
494| SDC | -> | APPC | DMaaP | 3904 | APPC requests and receives notifications from SDC for VNF License Artifacts and TOSCA dependency models. |
495+-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
496| APPC | -> | DCAE | DMaaP | 3904 | APPC sends intermediate messages to DCAE. Long-running operations such as Start, Restart, Stop, and Terminate generate intermediate success/failure messages per VNFC. |
497+-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
498| OOM | -> | APPC | DMaaP | 3904 | APPC receives operational commands: Start, Graceful Stop. |
499| | | | | | APPC reports: status, KPIs. |
500+-------------------+------------+-------------------------+-------------------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
501
502APPC Deployment
503================
504
505Refer to the APPC Deployment documentation at
506http://onap.readthedocs.io/en/latest/submodules/appc/deployment.git/docs/index.html
507
508Application Controller VNF Onboarding
509=====================================
510
511LCM Command Execution Overview
512------------------------------
513
514The Application Controller assumes that the A&AI instance it is
515configured with contains all the information it needs about
516VNF/VNFC/VMs, otherwise any request by the user to perform an action
517on a VNF will fail. The Application Controller uses a variety of SQL
518tables in order to perform actions on a VNF, all of which are
519described in Creation of DGs
520
521DGs are created using the Direct Graph Builder - Node Red graphical
522utility for DGs creation. DGs are then stored as XML files and loaded to
523APPC MySQL database. The DGs invoke the execution of Java code from
524different nodes.
525
526DGs are resolved according to LCM Action, API version, VNF Type, and VNF
527Version.
528
529The SLI framework is responsible for executing the DGs.
530
531Data Setup.
532~~~~~~~~~~~~
533
534Initially, Application Controller should have a set of DGs designed
535for the specific VNF type. These DGs are stored in the SVC\_LOGIC
536table.
537
538After a user sends an action request to the controller, the
539Application Controller uses the VNF\_DG\_MAPPING table to map the
540requested action to a specific DG. If the mapping was successful,
541the input body is validated and the user receives a synchronous
542response containing an Accept or a Reject message to indicate
543whether the request was rejected or whether it was accepted and the
544controller initiated the DG flow.
545
546During the execution of a DG, the controller may use one or more SQL
547tables to fetch or store data. For example, in order to perform a
548ConfigModify action, the controller needs to fetch a username and
549password to connect to the VNF and change its configuration.
550
551ALL tables used during DG execution are described below.
552
553Request execution
554-----------------
555
556Following initial request validation, APPC queries the A&AI inventory to
557acquire all the required information regarding topology of VNF/VNFC/VMs,
558operational status and operational data of the requested VNF instance. A
559missing target VF instance or any missing mandatory parameter in A&AI
560generate a rejection.
561
562After acquiring the VNF type from A&AI, APPC uses the VNF\_DG\_MAPPING
563table to map the requested action to a specific DG. No such DG located
564in the table generates a Reject response to the user.
565
566The Dispatcher state machine applies operation policies. A policy
567allowing execution generates an Accept response to the user. Not
568allowing execution generates a Reject response.
569
570If the first two steps were successful, the controller initiates the
571appropriate DG.
572
573During the execution of a DG, the controller may use one or more SQL
574tables to fetch or store data. For example, to perform a ConfigModify
575action, the controller needs to fetch a username and password to connect
576to the VNF and change its configuration.
577
578`Data Setup <#_Data_Setup>`__ describes the tables used during DG
579execution.
580
581If APPC is forced stopped while it is executing an LCM request, it might
582take some time to terminate all the threads that are being executed. In
583addition, the old threads might start to execute again once the APPC is
584restarted. The time when these treads start to execute again even after
585an APPC restart is dependent on the LCM request executed by the threads
586in the LCM queue and the ThreadPool size. To avoid this, it is
587recommended that:
588
589- Start APPC only after a while to ensure that the interrupted threads
590 are not executed again.
591
592- Do not execute the OAM-Forceful Stop command if the system is
593 executing an LCM request. Let the system operate in Maintenance mode.
594
595 1. .. rubric:: Creation of DGs
596 :name: creation-of-dgs
597
598DGs are created using the Direct Graph Builder - Node Red graphical
599utility for DGs creation. DGs are then stored as XML files and loaded to
600APPC MySQL database. The DGs invoke the execution of Java code from
601different nodes.
602
603At runtime, DGs are resolved according to LCM Action, API version, VNF
604Type, and VNF Version.
605
606The SLI framework is responsible for executing the DGs.
607
608Data Setup
609----------
610
611APPC uses MySQL database as a persistent store. This section describes
612the tables in general and the tables that require data to be set up
613before sending a request.
614
615SVC\_LOGIC Table
616~~~~~~~~~~~~~~~~
617
618SVC\_LOGIC table stores all NodeRed DGs invoked by actions executed by
619APPC. The SLI framework uses this table for running the DG. If the DG
620does not exist in this table, the SLI framework returns a 'DG not found'
621error.
622
623SVC\_LOGIC Parameters
624^^^^^^^^^^^^^^^^^^^^^
625
626+----------------------+----------------------+
627| **Parameter Name** | **Example Values** |
628+======================+======================+
629| **module** | APPC |
630+----------------------+----------------------+
631| **rpc** | Generic\_Audit |
632+----------------------+----------------------+
633| **version** | 2.0.0 |
634+----------------------+----------------------+
635| **mode** | sync |
636+----------------------+----------------------+
637| **active** | N |
638+----------------------+----------------------+
639| **graph** | <BLOB> |
640+----------------------+----------------------+
641
642**module, rpc, version**
643
644The ``module``, ``rpc``, and ``version`` parameters uniquely identify a Directed
645Graph (DG). The SLI framework uses these three parameters to invoke a DG
646or sub-DG. By convention, for the main DG, rpc is a combination of 'VNF
647type' (the generic type applied to all VNFs) followed by '\_' and
648'action'. This is the default convention; resolution of the DG for
649specific actions is handled individually in the relevant forthcoming
650sections.
651
652**mode**
653
654The DG execution node. This value is set to ‘sync’ for all APPC DGs.
655
656**active**
657
658This flag is the value of either 'Y' or 'N'. This flag is only used if
659specific version of DG is not mentioned while calling DG. If version of
660DG is not mentioned SLI framework will look for DG with active Flag set
661to 'Y' and execute it if found.
662
663**graph**
664
665This is actual graph invoked by SLI framework. The data type is SQL
666BLOB.
667
668VNF\_DG\_MAPPING
669~~~~~~~~~~~~~~~~
670
671The VNF\_DG\_MAPPING table stores the VNF and its corresponding DG. This
672is used by the DG resolver logic of the Dispatcher to map the DG to the
673requested action. Only the mapping is stored; the actual DG is stored in
674the SVC\_LOGIC table.
675
676The DG resolver logic uses a combination of action, api\_version and
677vnf\_type to retrieve the DG details: dg\_name (rpc column of SVC\_LOGIC
678table), dg\_version and dg\_module.
679
680The module, rpc and version uniquely identify the DG.
681
682The following assigned priority resolves the VNF DG:
683
6841. ``action``
685
6862. ``api_version``
687
6883. ``vnf_type``
689
6904. ``vnf_version``
691
692Blank, null or ‘\*’ values in ``api_version``, ``vnf_type`` and ``vnf_version``
693are matched with any values by the DG resolver. For example, a generic
694DG which can be invoked on any type of VNF ``vnf_type`` can be blank /
695null or \*. The DG resolver logic first tries to match a specific DG,
696and if this is not found, then look for a generic match using ‘\*’. For
697example as illustrated in the Example values in below table, an entry
698for the Test action and vnf\_type VSBG is specific, so it is only used
699for VNFs of type VSBG, whereas for the Sync action the same DG is used
700for any type of VNF and any version.
701
702VNF\_DG\_MAPPING Parameters
703^^^^^^^^^^^^^^^^^^^^^^^^^^^
704
705+----------------------+----------------------+-----------------+
706| **Parameter Name** | **Example Values** |
707+======================+======================+=================+
708| **action** | Test | Sync |
709+----------------------+----------------------+-----------------+
710| **api\_verson** | 2 | |
711+----------------------+----------------------+-----------------+
712| **vnf\_type** | vSBG | |
713+----------------------+----------------------+-----------------+
714| **vnf\_version** | | |
715+----------------------+----------------------+-----------------+
716| **dg\_name** | vSBG\_Test | Generic\_Sync |
717+----------------------+----------------------+-----------------+
718| **dg\_version** | 2.0.0.1 | 2.0.0 |
719+----------------------+----------------------+-----------------+
720| **dg\_module** | APPC | APPC |
721+----------------------+----------------------+-----------------+
722
723VNFC\_DG\_MAPPING
724~~~~~~~~~~~~~~~~~
725
726VNFC\_DG\_MAPPING stores the VNFC and its corresponding DG. The DG
727resolver logic of the Dispatcher uses this to map the DG to the
728requested action. Only the mapping is stored; the actual DG is stored in
729the SVC\_LOGIC table.
730
731The DG resolver logic uses a combination of ``action``, ``api_version``,
732``vnf_type``, and ``vnfc_type`` to retrieve the DG details: ``dg_name`` (rpc
733column of SVC\_LOGIC table), ``dg_version``, and ``dg_module``.
734
735The module, rpc and version uniquely identify the DG.
736
737The following assigned priority resolves the VNF DG:
738
7391. ``action``
740
7412. ``api_version``
742
7433. ``vnf_type``
744
7454. ``vnfc_type``
746
747The DG resolver matches blank, null or ‘\*’ values in ``api_version`` ,
748``vnf_type`` and ``vnfc_type`` with any values. For example, a generic DG
749which can be invoked on any type of VNFC 'vnfc\_type' can be blank /
750null or \*. The DG resolver logic first tries to match a specific DG. If
751this is not found, the DG resolver looks for a generic match using ‘\*’.
752
753VNFC\_DG\_MAPPING parameters
754^^^^^^^^^^^^^^^^^^^^^^^^^^^^
755
756+----------------------+---------------------+
757| **Parameter Name** | **Example Value** |
758+======================+=====================+
759| **action** | |
760+----------------------+---------------------+
761| **api\_version** | |
762+----------------------+---------------------+
763| **vnf\_type** | |
764+----------------------+---------------------+
765| **vnfc\_type** | |
766+----------------------+---------------------+
767| **dg\_name** | |
768+----------------------+---------------------+
769| **dg\_version** | |
770+----------------------+---------------------+
771| **dg\_module** | |
772+----------------------+---------------------+
773
774DEVICE\_AUTHENTICATION
775~~~~~~~~~~~~~~~~~~~~~~
776
777The DEVICE\_AUTHENTICATION table stores device authentication
778details. It is used by actions such as Audit and Sync which connect
779with VNFs. This table stores a record that corresponds to each VNF
780type, so ``vnf_type`` is unique.
781
782Username, password and port\_number are fields corresponding to
783``vnf_type``.
784
785DEVICE\_AUTHENTICATION Parameters
786^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
787
788+----------------------------------+---------------------+
789| **Parameter Name** | **Example Value** |
790+==================================+=====================+
791| **device\_authentication\_id** | 41 |
792+----------------------------------+---------------------+
793| **vnf\_type** | vDBE-V |
794+----------------------------------+---------------------+
795| **user\_name** | root |
796+----------------------------------+---------------------+
797| **password** | <password> |
798+----------------------------------+---------------------+
799| **port\_number** | 22 |
800+----------------------------------+---------------------+
801
802VNF\_LOCK\_MANAGEMENT
803~~~~~~~~~~~~~~~~~~~~~
804
805The VNF\_LOCK\_MANAGEMENT table is used to persist data for vnf
806locking. APPC locks the vnf id when actions start executing on that
807vnf id. This table stores vnf\_id i.e. resource\_id  along with
808owner , expiration\_time or timeout. Before execution of request,
809the dispatcher checks if VNF\_ID is already locked by another action
810in execution. If VNF\_ID is not locked, the dispatcher will locks it
811or else returns a VNF locked error to caller.
812
813VNF\_LOCK\_MANAGEMENT Parameters
814^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
815
816+----------------------+---------------------+
817| **Parameter Name** | **Example Value** |
818+======================+=====================+
819| **resource\_id** | AUDIT\_1652 |
820+----------------------+---------------------+
821| **owner\_id** | vDBE-V |
822+----------------------+---------------------+
823| **updated** | 1474457140000 |
824+----------------------+---------------------+
825| **timeout** | 0 |
826+----------------------+---------------------+
827| **ver** | 22 |
828+----------------------+---------------------+
829
830This table do not require any initial setup.
831
832VNF\_STATE\_MANAGEMENT
833~~~~~~~~~~~~~~~~~~~~~~
834
835The VNF\_STATE\_MANAGEMENT table is used to store the operational state
836of VNF\_ID, whether it is stable or unstable. It stores state, owner and
837updated time (in milliseconds). This table does not require any initial
838setup.
839
840VNF\_STATE\_MANAGEMENT Parameters
841^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
842
843+----------------------+-------------------------------------+
844| **Parameter Name** | **Example Value** |
845+======================+=====================================+
846| **vnf\_if** | ASHISH\_VSBG\_VNFS\_1787 |
847+----------------------+-------------------------------------+
848| **state** | STABLE |
849+----------------------+-------------------------------------+
850| **owner\_id** | ORIG\_1787@REQ\_1787@SUBREQ\_1787 |
851+----------------------+-------------------------------------+
852| **updated** | 1474457140000 |
853+----------------------+-------------------------------------+
854| **timeout** | 0 |
855+----------------------+-------------------------------------+
856| **ver** | 22 |
857+----------------------+-------------------------------------+
858
859UPLOAD\_CONFIG
860~~~~~~~~~~~~~~
861
862The UPLOAD\_CONFIG table is used by configuration management actions
863such as Audit, Sync, ConfigModify, Terminate, and similar. It stores
864device configuration: one row or record corresponds to one VNFC, so
865therefore a VNF that has multiple VNFCs has multiple rows in the
866table.
867
868The UPLOAD\_CONFIG table stores configuration as the following
869types:
870
871- ``Current``
872
873- ``Running``
874
875- ``Historic``
876
877The ``config_indicator`` column denotes the type of configuration,
878where a null value denotes ``Historic`` configuration. For a single VNFC
879there should only be one ``Current`` and one ``Running`` configuration , but
880there can be multiple Historic configurations. This table does not
881require any initial setup.
882
883UPLOAD\_CONFIG Parameters
884^^^^^^^^^^^^^^^^^^^^^^^^^
885
886+----------------------------+-------------------------+-------------------------+
887| **Parameter Name** | **Example Values** |
888+============================+=========================+=========================+
889| **upload\_config\_id** | 63 | 67 |
890+----------------------------+-------------------------+-------------------------+
891| **request\_id** | 3 | REQ\_1690 |
892+----------------------------+-------------------------+-------------------------+
893| **originator\_id** | 12345 | ORIG\_1690 |
894+----------------------------+-------------------------+-------------------------+
895| **service\_description** | abcde | abcde |
896+----------------------------+-------------------------+-------------------------+
897| **action** | ConfigModify | Sync |
898+----------------------------+-------------------------+-------------------------+
899| **upload\_date** | 2016-08-01 14:30:40 | 2016-09-22 12:30:40 |
900+----------------------------+-------------------------+-------------------------+
901| **vnf\_id** | AUDIT\_1767 | AUDIT\_1690 |
902+----------------------------+-------------------------+-------------------------+
903| **vnf\_name** | GET\_RUN\_CONFIG\_VNF | GET\_RUN\_CONFIG\_VNF |
904+----------------------------+-------------------------+-------------------------+
905| **vm\_name** | GET\_RUN\_CONFIG\_VNF | GET\_RUN\_CONFIG\_VNF |
906+----------------------------+-------------------------+-------------------------+
907| **vnf\_type** | vDBE-V | vDBE-V |
908+----------------------------+-------------------------+-------------------------+
909| **vnfc\_type** | vDBE-V2 | vDBE-V1 |
910+----------------------------+-------------------------+-------------------------+
911| **host\_ip\_address** | 135.25.69.37 | |
912+----------------------------+-------------------------+-------------------------+
913| **config\_indicator** | Current | Running |
914+----------------------------+-------------------------+-------------------------+
915| **pending\_delete** | | |
916+----------------------------+-------------------------+-------------------------+
917| **content** | Dummy\_current | <Configuration> |
918+----------------------------+-------------------------+-------------------------+
919
920DEVICE\_INTERFACE\_PROTOCOL
921~~~~~~~~~~~~~~~~~~~~~~~~~~~
922
923The DEVICE\_INTERFACE\_PROTOCOL table stores the VNF type and
924corresponding sub-DG used to get the running configuration of a device.
925The 'getRunningConfig' DG, which is a sub-DG called by Audit and Sync
926DG, uses this table. It stores the VNF type and corresponding sub-DG,
927which are used to get the running configuration of a device. The ``module``
928and ``DG_RPC`` are used to identify the DG from the SVC\_LOGIC table. The
929``protocol`` is used to store the protocol defined for retrieving
930configuration. If a mapping between the VNF type and the DG does not
931exist in this table, then actions such as Audit and Sync fail with the
932error message 'Device Interfacing DG not available'.
933
934DEVICE\_INTERFACE\_PROTOCOL Parameters
935^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
936
937+---------------------------------------+--------------------------+
938| **Parameter Name** | **Example Value** |
939+=======================================+==========================+
940| **device\_interface\_protocol\_id** | 4 |
941+---------------------------------------+--------------------------+
942| **vnf\_type** | vDBE-V |
943+---------------------------------------+--------------------------+
944| **protocol** | NETCONF-XML |
945+---------------------------------------+--------------------------+
946| **module** | APPC |
947+---------------------------------------+--------------------------+
948| **dg\_rpc** | getDeviceRunningConfig |
949+---------------------------------------+--------------------------+
950
951CONFIG FILES
952~~~~~~~~~~~~
953
954The CONFIG\_FILES table is used by the several configuration DGs, using
955a legacy configuration API, to store artifacts from SDC, configuration
956data from requests, and configurations to be downloaded to VNFs.
957
958CONFIG\_FILES Parameters
959^^^^^^^^^^^^^^^^^^^^^^^^
960
961+-----------------------------+----------------------------+
962| **Parameter Name** | **Example Value** |
963+=============================+============================+
964| **config\_file\_id** | 24 |
965+-----------------------------+----------------------------+
966| **external\_version** | |
967+-----------------------------+----------------------------+
968| **data\_source** | Configurator |
969+-----------------------------+----------------------------+
970| **creation\_date** | 6/9/2016 11:16:57 AM |
971+-----------------------------+----------------------------+
972| **service\_instance\_id** | ibcx0001vm001 |
973+-----------------------------+----------------------------+
974| **vnf\_type** | ISBC |
975+-----------------------------+----------------------------+
976| **vnfc\_type** | vISBC - mmc |
977+-----------------------------+----------------------------+
978| **file\_category** | device\_configuration |
979+-----------------------------+----------------------------+
980| **file\_name** | orch\_config.json |
981+-----------------------------+----------------------------+
982| **file\_content** | (contains configuration) |
983+-----------------------------+----------------------------+
984
985GET\_CONFIG\_TEMPLATE
986~~~~~~~~~~~~~~~~~~~~~
987
988The GET\_CONFIG\_TEMPLATE table is used by the 'getDeviceRunningConfig'
989DG, which is used as a sub-DG for the Audit and Sync actions. It stores
990template data corresponding to the VNF type. Template data is only used
991when the protocol in DEVICE\_INTERFACING\_PROTOCOL table is set to
992'CLI'. Other protocols do not use this table. If Data does not exist in
993this table and protocol is set to 'CLI' then DG results in 'Error
994getting Template Data'.
995
996GET\_CONFIG\_TEMPLATE Parameters
997^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
998
999+---------------------------------------+-----------------------------------------+
1000| **Parameter Name** | **Example Value** |
1001+=======================================+=========================================+
1002| **get\_config\_template\_id** | 1 |
1003+---------------------------------------+-----------------------------------------+
1004| **vnf\_type** | Generic |
1005+---------------------------------------+-----------------------------------------+
1006| **device\_interface\_protocol\_id** | 3 |
1007+---------------------------------------+-----------------------------------------+
1008| **xml\_processing** | |
1009+---------------------------------------+-----------------------------------------+
1010| **xml\_protocol** | |
1011+---------------------------------------+-----------------------------------------+
1012| **template** | Login\_Prompt: Matches "Login as:"... |
1013+---------------------------------------+-----------------------------------------+
1014
1015ASDC\_ARTIFACTS
1016~~~~~~~~~~~~~~~
1017
1018The ASDC\_ARTIFACTS table contains the model received from the SDC in
1019YAML format. APP-C reads this model and identifies the order of the
1020VNFCs and their resilience types.
1021
1022ASDC\_ARTIFACTS parameters
1023^^^^^^^^^^^^^^^^^^^^^^^^^^
1024
1025+--------------------------------+------------------------+
1026| **Parameter Name** | **Example Value** |
1027+================================+========================+
1028| **asdc\_artifacts\_id** | 1 |
1029+--------------------------------+------------------------+
1030| **service\_uuid** | Service-uuid |
1031+--------------------------------+------------------------+
1032| **distribution\_id** | Distribution-ID |
1033+--------------------------------+------------------------+
1034| **service\_name** | Test |
1035+--------------------------------+------------------------+
1036| **service\_description** | Test |
1037+--------------------------------+------------------------+
1038| **resource\_uuid** | Resource-uuid |
1039+--------------------------------+------------------------+
1040| **resource\_instance\_name** | vSCP |
1041+--------------------------------+------------------------+
1042| **resource\_name** | vSCP |
1043+--------------------------------+------------------------+
1044| **resource\_version** | 1.0 |
1045+--------------------------------+------------------------+
1046| **resource\_type** | VF |
1047+--------------------------------+------------------------+
1048| **artifact\_uuid** | Artifact-uuid |
1049+--------------------------------+------------------------+
1050| **artifact\_type** | TOPOLOGY |
1051+--------------------------------+------------------------+
1052| **artifact\_version** | 1 |
1053+--------------------------------+------------------------+
1054| **artifact\_description** | VNF Dependency Model |
1055+--------------------------------+------------------------+
1056| **internal\_version** | 0 |
1057+--------------------------------+------------------------+
1058| **creation\_date** | 2016-11-17 10:10:18 |
1059+--------------------------------+------------------------+
1060| **artifact\_name** | Scp-template.yml |
1061+--------------------------------+------------------------+
1062| **artifact\_content** | <Content> |
1063+--------------------------------+------------------------+
1064
1065Sequence Generator API
1066======================
1067
1068The Sequence Generator API generates the steps of execution for LCM
1069operations at minute-level. This API is exposed using the following
1070two endpoints:
1071
1072- DG plug-in
1073
1074- REST API
1075
1076The Sequence Generator API takes an input file in JSON format and,
1077based on the parameters defined in the input file, generates an
1078output file.
1079
1080This chapter comprises the following topics:
1081
1082- Sample input file
1083
1084- Sample output file
1085
1086- Supported actions
1087
1088 The input file comprises:
1089
1090- Request information
1091
1092- Inventory information
1093
1094All these sections of the input file and the parameters used are
1095explained in the subsequent sections.
1096
1097Sample Input File
1098-----------------
1099
1100::
1101
1102 {
1103 "request-info": {
1104 "action": "Stop",
1105 "action-level": "vm",
1106 "action-identifier": {
1107 "vnf-id": "abc"
1108 },
1109 "payload": " {\"vnf-host-ip-address\": \"10.147.124.163\" }"
1110 },
1111 "inventory-info": {
1112 "vnf-info": {
1113 "vnf-id" : "abc",
1114 "vnf-name": "vSCP",
1115 "vnf-type": "vSCP",
1116 "vnf-version" : "1.0",
1117 "vm": [
1118 {
1119 "vserver-id" : "be_vserverid1",
1120 "vnfc":
1121 {
1122 "vnfc-type": "BE",
1123 "vnfc-name": "BE - Name"
1124 }
1125 },
1126 {
1127 "vserver-id" : "fe_vserverid1",
1128 "vnfc":
1129 {
1130 "vnfc-type": "FE",
1131 "vnfc-name": "FE - Name"
1132 }
1133 },
1134 {
1135 "vserver-id" : "smp_vserverid1",
1136 "vnfc":
1137 {
1138 "vnfc-type": "SMP",
1139 "vnfc-name": "SMP - Name"
1140 }
1141 }
1142 ]
1143 }
1144 }
1145 }
1146
1147
1148Parameters
1149~~~~~~~~~~
1150
1151This section explains the parameters used in the Sequence Generator
1152API input file.
1153
1154+-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+
1155| **Parameter name** | **Description** | **Possible values** | **Required?** |
1156+=============================+===============================================================================================================================================================================+=======================================+=================+
1157| **Request Information** |
1158+-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+
1159| action | The action to be executed by Sequence Generator API. | Start,Stop | Y |
1160+-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+
1161| action-level | Represents the level for the action such as, vm, vnfc. | Vnf,vnfc,vm,vf-module | Y |
1162+-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+
1163| action-identifier | A block containing the action arguments. These are used to specify the object upon which Sequence Generator API operates. At least one action-identifier must be specified. | Vnf-id | N |
1164+-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+
1165| vnf-id | Identifies the VNF instance to which this action is to be applied. vnf-id uniquely identifies the service-instance. | String | N |
1166+-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+
1167| payload | An action-specific open-format field. The payload can be any valid JSON string value. | AICIdentity and vnf-host-ip-address | N |
1168+-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+
1169| **Inventory Information** |
1170+-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+
1171| vnfInfo | Represents the VNF information to which this action is to be applied. | String | Y |
1172+-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+
1173| vnf-id | Identifies the VNF instance to which this action is to be applied. vnf-id uniquely identifies the service-instance. | String | N |
1174+-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+
1175| vnf-name | Identifies the VNF instance to which this action is to be applied. | vSCP | N |
1176+-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+
1177| vnf-type | Represents the type of the VNF instance. | vSCP | N |
1178+-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+
1179| vnf-version | Represents the version of the VNF instance. | Alphanumeric | N |
1180+-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+
1181| vm | Represents the VM information to which this action is to be applied. | List of VMs | Y |
1182+-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+
1183| vserver-id | Identifies a specific VM instance to which this action is to be applied. | Alpha-numeric unique ID | Y |
1184+-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+
1185| vnfc | Represents the VNFC information to which this action is to be applied. | vnfc-type, vnfc-name | N |
1186+-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+
1187| vnfc-type | Represents the type of the VNFC instance. | FE,BE,SMP | N |
1188+-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+
1189| vnfc-name | Identifies the VNFC instance to which this action is to be applied. | FE-Name, BE-Name, SMP-Name | N |
1190+-----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+-----------------+
1191
1192Sample Output file
1193------------------
1194
1195::
1196
1197 [{
1198 "transactionId": 1,
1199 "action": "Stop",
1200 "action-level": "vm",
1201 "action-identifier": {
1202 "vserver-id": "be_vserverid1"
1203 },
1204 "payload": " {\"vnf-host-ip-address\": \"10.147.124.163\" }",
1205 "responses": [{
1206 "response-message": "failure",
1207 "response-action": {
1208 "ignore": "true"
1209 }
1210 }]
1211 },
1212 {
1213 "transactionId": 2,
1214 "action": "Stop",
1215 "action-level": "vm",
1216 "action-identifier": {
1217 "vserver-id": "fe_vserverid1"
1218 },
1219 "payload": " {\"vnf-host-ip-address\": \"10.147.124.163\" }",
1220 "responses": [{
1221 "response-message": "failure",
1222 "response-action": {
1223 "ignore": "true"
1224 }
1225 }]
1226 },
1227 {
1228 "transactionId": 3,
1229 "action": "Stop",
1230 "action-level": "vm",
1231 "action-identifier": {
1232 "vserver-id": "smp_vserverid1"
1233 },
1234 "payload": " {\"vnf-host-ip-address\": \"10.147.124.163\" }",
1235 "responses": [{
1236 "response-message": "failure",
1237 "response-action": {
1238 "ignore": "true"
1239 }
1240 }]
1241 }
1242 ]
1243
1244
1245Supported Actions
1246-----------------
1247
1248The following actions are supported for the Sequence Generator API
1249for this release:
1250
1251- Generate Runtime Sequence Flow for Start Action with no dependency
1252 model
1253
1254- Generate Runtime Sequence Flow for Stop Action with no dependency
1255 model
1256
1257.. |image0| image:: media/AppCDeployment.png
1258 :width: 6.50000in
1259 :height: 2.55903in
1260.. |image1| image:: media/AppCApidoxExplorer.png
1261 :width: 6.50000in
1262 :height: 4.83611in
1263.. |image2| image:: media/AppCApidoxExplorer2.png
1264 :width: 6.50000in
1265 :height: 5.50139in
1266.. |image3| image:: media/AppCApidoxExplorer3.png
1267 :width: 6.50000in
1268 :height: 5.65347in
1269.. |image4| image:: media/AppCApidoxExplorer4.png
1270 :width: 6.50000in
1271 :height: 6.62292in
1272.. |image5| image:: media/AppCArchitectureDiagram.png
1273 :width: 6.50000in
1274 :height: 3.40347in
1275.. |image6| image:: media/AppCDGOrchestratorArchitecture.png
1276 :width: 6.36597in
1277 :height: 3.72903in