master
Érina 3 3 years ago
parent cdf069afb0
commit 892ee6fd5d

@ -206,12 +206,12 @@
Un \textit{Channel} corespond à un instrument d'une station sur une periode de temps. De ce fait, deux \textit{channels} différents peuvent avoir le même code (exemple: 'HHZ') mais cela veux dire qu'il y a eu une interuption humaine dans l'envoi de données. La fermeture puis réouverture d'un \textit{channel} ne doit pas être confondu avec un \textit{gap}, qui est une interuption de l'envoi de données à un moment où on s'attend à en recevoir.
\subsubsection{Le traitement de la donnée}
\begin{figure}[H]
\caption{Parcours de la donnée depuis l'aquisition jusqu'à la distribution}
\includegraphics[width=\textwidth]{organigrameNoeudANoeudB}
\label{fig:parcourDonnée}
\caption{Parcours de la donnée depuis l'aquisition jusqu'à la distribution}
\label{fig:parcourDonnee}
\end{figure}
\paragraph{}
Comme on peut le voir sur la Figure~\ref{fig:parcourDonnée}, la donnée récoltée par les stations RÉSIF est diréctement envoyée au \textit{noeud A} qui s'occupe de la valider. Une fois ce travail terminé, Cette donnée est transmise au \textit{noeud B} qui à pour mission de la distribuer aux utilisateur\textperiodcentered ice\textperiodcentered s, notament le Commissariat à lÉnergie Atomique (CEA) qui peux lancer des alerte au population en cas de données montrant un séisme dangereux. Pour palier à cette mission, le noeud B met a dispositions plusieus \textit{web services} à la disposition de tout\textperiodcentered se\textperiodcentered s.
Comme on peut le voir sur la Figure~\ref{fig:parcourDonnee}, la donnée récoltée par les stations RÉSIF est diréctement envoyée au \textit{noeud A} qui s'occupe de la valider. Une fois ce travail terminé, Cette donnée est transmise au \textit{noeud B} qui à pour mission de la distribuer aux utilisateur\textperiodcentered ice\textperiodcentered s, notament le Commissariat à lÉnergie Atomique (CEA) qui peux lancer des alerte au population en cas de données montrant un séisme dangereux. Pour palier à cette mission, le noeud B met a dispositions plusieus \textit{web services} à la disposition de tout\textperiodcentered se\textperiodcentered s.
\subsection{Les differents web services}
\subsubsection{Comment utiliser un web service}
@ -335,6 +335,56 @@
\label{fig:implementationScenario}
\end{figure}
Pour chaque \textit{step}, \textit{behave} ira chercher et executer la bonne fonction grâce au préfix \textit{@given}, \textit{@when} et \textit{@then}. Ainsi, le nom de la fonction n'est pas imprtant pour \textit{behave}. Les variables peuvent être transmises de fonction en fonction grâce à la notion de \textit{context}. Concrétement, c'est un objet qui est passé en paramètre de chaque fonction est qui est capable de stocker des variables sous la forme de propriété.
\subsubsection{Détail d'un step}
\paragraph{}
La complexité d'un step peux varier en fonction de sa nature. En effet, les steps \textit{given} son assez simples à implémenter (cf. Figure.~\ref{fig:given}). Les autres \textit{steps} sont en général plus complexe.
\paragraph{}
Par exemple, le \textit{step} "\textit{When the web service is 'GET|POST' requested}" (cf. Figure~\ref{fig:when}) a su poser problème lors de son implémentation.
\begin{figure}[H]
\caption{Implementation d'un \textit{step} when}
\begin{verbatim}
@when('the webservice is "{methods}" requested')
def requestWebService(context, methods):
"""
Make and submit queries parametered by given steps
"""
methods = methods.split('|') #= ['GET'] or ['POST'] or ['GET', 'POST']
# Merge args form commons args and args that are specifics to the first query
args = [ context.commonArgs | spe for spe in context.specificArgs.values()] if len(context.specificArgs) > 0 else [context.commonArgs]
context.queries = [[] for i in range(len(args)*len(methods))]
qg = QueryGenerator()
raiseError = None
i=0
#Number of args lines match with number of request
for request in args:
args = context.commonArgs | context.specificArgs
for method in methods:
context.queries[i] = qg.generateQuery(context.ws, request, context.headerOnly, refreshCache=context.refreshCache, login=context.queryAuthLoggin, password=context.queryAuthPassword)
try:
if method.upper() == 'GET':
context.queries[i].get()
elif method.upper() == 'POST':
context.queries[i].post()
else:
raise ValueError(f"{method} is not a suported method")
# custome the Traceback
except ConnectionError:
raiseError = ValueError(f"Can not connect to {context.ws}")
except InvalidSchema:
raiseError = ValueError(f"The URL is not valide: {context.ws}")
if raiseError: # and raise if raiseError != None
raise raiseError
i+=1
\end{verbatim}
\label{fig:when}
\end{figure}
\paragraph{}
Je vais maintenant décrir son fonctionement. Dans un premier lieu, je séléctionne les methodes d'intérogation du \textit{web service} définit dans le scénario. Il est possible de faire un requete POST, une requete GET ou les 2. En suite, j'initie des variables pour les utiliser plus tard. Cependant, a ca moment là, la variable \textit{args} sert juste à initaliser la variable \textit{context.queries}.\textbf{PARLER DE LA BOUCLE FOR !!!}
\subsection{Environement}
\subsubsection{Environement behave}
\textit{Behave} est capable de généré un environement entre chaqu'un des \textit{items} composant les tests (\textit{feature}, \textit{scénario}, \textit{tag}, \dots). Pour ça, il faut définir des fonctions avec des noms prédéfinit par \textit{behave} dans un fichier nomé \textit{environment.py}.

Loading…
Cancel
Save