🧑🏽 🛄 🛌🏿 Application sur TSD et communication avec 1C: Enterprise 8.3 via HTTP-Service. Partie 1.1 (description détaillée de l'API) 🚜 🦋 🦔

Cette partie est apparue après que j'ai commencé l'implémentation complète. Après l'opération de combat, il fallait changer la structure de l'échange de données. Il s'est avéré très difficile d'introduire TSD dans le travail. La «plate-forme mobile 1C» a été choisie comme logiciel, car Kotlin était très dur. Dans cette partie, je vais parler de la façon dont l'échange a été implémenté initialement, et fournir du code sur l'exemple d'un répertoire à la fois côté serveur et côté client.

1. Description générale de l'algorithme d'échange.

Côté serveur, des plans d'échange avec enregistrement automatique des modifications sont utilisés. La pratique a montré que c'est le moyen le moins cher en termes de programmation. Côté TSD, dans chaque répertoire, un document, un accessoire a été ajouté , dans les registres un accessoire du même nom a été ajouté .

L'échange lui-même est désormais divisé en deux étapes.

Nous recevons de nouvelles données, nous fixons un signe de mise à jour;
Nous envoyons une confirmation que les données ont été reçues. Si la réponse est oui, nous supprimons le signe de la mise à jour;

Un tel schéma est apparu après que le TSD a commencé à quitter la zone de couverture WiFi. Souvent, il s'est avéré que les données étaient venues, mais la réponse n'a pas été envoyée.

Pour faciliter la mise en service du TSD, un répertoire avec des valeurs prédéfinies est apparu, pour chacun ( ).

2. Comme cela a été mis en œuvre auparavant.

La demande a été initiée par le TSD. Toutes les 15 secondes, il y avait une demande de nouvelles données, pour chaque répertoire, document, registre. Les données sont collectées par lots de 100 éléments. Ce qui a imposé ses limites. Si vous terminez l'enregistrement pour le nœud entier, les données sont chargées environ 30 minutes. Parce que dans la mise en œuvre actuelle, il n'existait aucun mécanisme pour informer le TSD de la présence d'un autre pack.

Un morceau de code 1C sur TSD

 () 
	
	.();
	.();

	.();
	.();
			
	.();
	.();
	
	.();
	.();
	
	.();
	.();

Une fois que le nombre de répertoires est passé à plus de cinq, une triste image est apparue: chaque action côté serveur est la même. La demande de données est différente. Mais la fixation des changements pour les répertoires est la même chose. Jetons un coup d’œil à l’exemple d’OKEY. Bref, alors

Nous préparons la connexion, prenons toutes les constantes.
Nous préparons une demande. Chaque répertoire se trouve dans sa propre route. Et puis la commande avec paramètres suit. quelque chose comme ceci:
localhost/ws/okeis/getNew&node=.
Préparer la structure de réponse
Nous obtenons la réponse et remplissons la structure en fonction du code de réponse HTTP.
En cas de succès, déployez JSON dans des structures 1C.
Nous commençons la transaction. Nous corrigeons les changements dans le répertoire. Valider la transaction
Nous appelons la fonction de validation des modifications côté serveur
Et maintenant la fixation est exactement la même côté serveur

Initialement, chaque répertoire avait sa propre procédure de correction, maintenant il ressemble à ceci.

Beaucoup de code 1C

	
 () 
HTTP = .HTTP();
	HTTP = .HTTP("okeis", "getAll?node="+(..()));
	
	 = HTTP.(HTTP);
	
	 =  ;
	.("", .);
	.("", .());

	 . = 200 
		 = .;
		 = .JSON();
		  .("") 
			();
			 = ;
			    .okeis 
				 = .code;
				 = .name;
				 = .fullName;
				 = .internationalReduction;
				
				 = ..();
				
				 () 
					 = .();
				
					 = ..();
				;
				
				. = ;
				. = ;
				. = ;
				. = ;
				. = ;
				
				
					.();
				
					 = ;
					;
				;
				
			;
			
			   
				();
			
				();
			;
		;			
	;

 get()
	
	 .URL.("") = "getAll" 
		
		(0,"  ");
		
		 = ..("node");
		
		 = ();
		 = HTTP(200, );
		
		(0,"  ");
		 ;
	;

	 = HTTP(400,  (",", , " "));
	 ;

 () 
	
	 =  ;
	. = "
	               |	.  
	               |
	               |	.  
	               |
	               |	.";
	
	 = .();
	 = .();
	
	 =  ;
	
	 .() 
		.( ("code", ..));
	;
	
	 =  ;
	.("okeis", );
	
	
	HTTP = .HTTP();
	HTTP = .HTTP("okeis", "dataObtained?node="+(..()));
	
	 = .();
	
	HTTP.();
	
	 = HTTP.(HTTP);
	
	 . = 200 
		();
		 = ;
				
		      
			 = ..(.code).();
			. = ;
			
				.();
			
				 = ;
				;
			;
				
		;
		
		   
			();
		
			();
		;
		
	;

 post()
	
	 = .URL.("");

	  = "dataObtained" 
		
		 = ..("node");
		 = ..("nameStructure");

		 = .();
		 = JSON();
		
		 =  ("", , , );
		
		  
			 = HTTP(200,  ("code", 0));
		
			 = HTTP(400,  ("code", 100));
		;
		
		 ;
	;
	 
	 = HTTP(400,  (",", , " "));
	 ;

 (, , , )
	
	 = ();
	
	();
	 = ;
	    [] 
		
		 = [].(.code);
		
		 () 
			
				.(,);
			
				 = ;
				;
			;	
		;
	;
	
	  
		();
		 ;
	
		();
		 ;
	;

Cet article décrit la mise en œuvre du front. Ne faites pas cela, sauf si vous devez assembler rapidement un prototype et le tester au combat.

Si vous aimez l'article, dans le prochain, je vous dirai comment il est mis en œuvre maintenant.

Application sur TSD et communication avec 1C: Enterprise 8.3 via HTTP-Service. Partie 1.1 (description détaillée de l'API)

1. Description générale de l'algorithme d'échange.

2. Comme cela a été mis en œuvre auparavant.

More articles: