Writing /giga/dw/dng/dokuwiki/data/meta/dev/010how/120websrv/0100smctec.meta failed
dev:010how:120websrv:0100smctec

Service Layer Technical Information

Technical Sequence of one service layer request for executing one transaction

- The request is inserted in table SMC with status 'I' (Inserted).
- These requests with status 'I' are picked up from the manager SMCTSK.
- This manager interpretes the request and creates one pending item for each request. The status of the requests is set to to 'C' (Created) for every request. One pending item ( SPT ) is generated for automatic execution.
- if SMCTSK recognizes that the request is erreouneous, then, no SPT is generated and the status of the request is set to 'E' (Errors). The errormessages are stored in one field of the request. This request has to be corrected and resent to DOKA-NG.
- The generated SPT is picked up by the pending item manager (SPTTSK). This manager calls the requested business transaction with the data contained in the request.
- The called transaction trys to store this transaction.
- When there is no error the status of the request is set to P (Processed).
- When there are warnings ( in interactive mode the warnings on the warning panel ) the transaction is stored and the status of the request is set to W (Warnings).
- When there are errors, the transaction is not stored and the status is set to E (Error).

In every case the pending item is deleted.

Technical Sequence executing one command from background managers

In addition to generate a SPT and executing one transaction, SMCTSK is able to send commands to each background mananger.
The following commands can be executed for each manager:
S = Start manager
D = Down Manager
F = Force down manager
R = Request Status

Status of the SMC ( Service layer request )

- I = Inserted
- C = Pending Item created
- P = business transaction successfully stored.
- E = Errors occurred
- W = There were warnings, when storing this transaction

Structure of the Json representing one Transaction


- 'trnname' contains the transaction name
- 'congrp' is an array, which contains an array of contracts contained in the transaction
- 'attsetnam' contains the name of the attachment set. Attachments are added as incoming messages to the conract.
- <Contract> module x contains the name of a contract type e. g. 'GID'
- The datafields contain the name, belonging to the module. The content x is the content of this datafield x.
- 'CBB' is an array of Balance entries
- 'PTS' is an array of Parties per Contract
- 'SWIADD' is a block, that can contain any field of the SWIADD module. These fields have to be handled in the transaction source text. If there arre new fields needed, SWIADD can be extended with additional fields.

Transaction Name Block

In the <Transaction Name> block each datafield in each module or modulelist can be set.
Datafields can either be adressed by defining a submodule block for every submodule and the datafield. For Example

or directly with \\ notation.

Modulelists are represented as an array in the Json.

Example


Structure of the Json of one command for one background manager


Example


dev/010how/120websrv/0100smctec.txt · Last modified: 2024/04/05 10:10 (external edit)