Exemple de code utilisant les API IBM Aspera pour divers produits et SDK IBM Aspera :
Différents langages de programmation sont proposés.
Documentation de l'API IBM Aspera (sélectionnez 24 éléments par page en bas).
La documentation du SDK Aspera Transfer contient des exemples de code.
Vidéo sur le SDK de transfert
Le site github IBM Aspera Connect SDK contient des exemples d'utilisation du SDK Aspera Connect.
IBM Aspera propose deux types d'API :
API client :
Les SDK incluent des bibliothèques à utiliser dans les applications pour transférer des fichiers
API du serveur :
Les API REST (avec la spécification OpenAPI) interagissent avec les applications Aspera (Faspex, AoC, Node API, COS, etc...)
Selon le cas d'utilisation, on peut utiliser une ou (souvent) plusieurs de ces API.
Ce référentiel est structuré comme ceci :
web
: un exemple qui montre l'utilisation du SDK Web : le SDK Aspera Connect et le SDK Aspera HTTP Gateway
app
: exemples dans différentes langues utilisant le SDK Aspera Transfer et les API REST Aspera Applications
Dans chaque dossier de langue, vous trouverez :
README.md
: un README spécifique au langageMakefile
: un makefile pour exécuter les échantillonssrc
: code sourcesrc/utils
: classes d'assistancesrc/examples
: exemples de programmesLes exemples de programmes utiliseront les adresses de serveur et les informations d'identification d'un fichier de configuration YAML. Une fois le fichier de configuration créé, des exemples de programmes peuvent être exécutés directement.
Systèmes de type Unix : Linux, macOS... un Makefile
est fourni pour exécuter les exemples.
Windows : reportez-vous à Démarrage rapide (Windows) ci-dessous. make
pourrait ne pas être disponible. Utilisez le Makefile
comme référence pour exécuter les commandes manuellement.
Voir Exécution d’exemples de programmes.
A la première exécution de make
: le Transfer SDK sera automatiquement téléchargé.
Pour télécharger le SDK, exécutez : make sdk
.
Reportez-vous au fichier de configuration : copiez le fichier config/config.tmpl
dans private/config.yaml
et remplissez les valeurs.
md private
copy configconfig.tmpl privateconfig.yaml
Définissez le paramètre misc.platform
sur windows-x86_64
Modifiez les paramètres requis dans private/config.yaml
, par exemple les informations de connexion Faspex.
Remarque : Oui, vous pouvez également glisser-déposer, cliquer, copier/coller et modifier le fichier avec le Bloc-notes, etc...
Préparez le dossier SDK
md tmp
Téléchargez le SDK Aspera Transfer (ici) et extrayez son contenu dans le dossier identifié par sdk_dir
dans config/paths.yaml
: <main folder>/tmp/transfer_sdk
Remarque : assurez-vous que les fichiers identifiés dans
config/paths.yaml
se trouvent dans le dossier extrait comme prévu. Par exemple, le fichier suivant doit exister :<main folder>/tmp/transfer_sdk/bin/asperatransferd
Exécutez les exemples : voir Exécution d’exemples de programmes
Créez un fichier de configuration comme spécifié dans Fichier de configuration. Toutes les valeurs ne sont pas obligatoires, seules celles nécessaires aux exemples que vous souhaitez exécuter.
Par exemple, pour exécuter un échantillon individuel, utilisez make .tested/<sample name here>
:
$ cd app/python
$ make list
server aoc faspex faspex5 node shares node_v2
$ make .tested/faspex5
L’exécution d’exemples nécessite le téléchargement du démon Transfer SDK asperatransferd
et de certains outils pour compiler le fichier proto du SDK de transfert, voir Transfer SDK.
Pour plus de détails, reportez-vous à la recette dans le Makefile
de chaque langue.
Un fichier de configuration modèle est fourni : config/config.tmpl
.
Copiez le fichier config/config.tmpl
dans private/config.yaml
et remplissez-le avec vos propres adresses de serveur, informations d'identification et paramètres.
cp config/config.tmpl private/config.yaml
vi private/config.yaml
Remarque : Bien que le format puisse ressembler au fichier de configuration pour
ascli
, un fichier de configuration pourascli
n'est pas compatible avec celui-ci. Vous devez en créer un nouveau.
Définissez le paramètre misc.platform
sur l'architecture utilisée :
osx-arm64
osx-x86_64
windows-x86_64
linux-x86_64
linux-s390
linux-arm64
linux-ppc64le
aix-ppc64
Le paramètre trsdk.url
peut être défini sur grpc://127.0.0.1:55002
(spécifiez le port local que le SDK utilisera).
La section httpgw
est utilisée uniquement par l'exemple web
.
D'autres sections sont utilisées par les différents exemples. Par exemple, si vous souhaitez tester uniquement le transfert COS à l’aide du SDK Transfer, vous pouvez remplir uniquement la section cos
et laisser les autres sections vides.
Exemple (avec des informations d'identification aléatoires) :
misc :
platform : osx-x86_64
level : debug
transfer_regular : true
trsdk :
url : grpc://127.0.0.1:55002
level : trace
ascp_level : trace
web :
port : 9080
httpgw :
url : https://1.2.3.4/aspera/http-gwy
server :
user : aspera
pass : demoaspera
url : ssh://demo.asperasoft.com:33001
file_download : /aspera-test-dir-small/10MB.1
folder_upload : /Upload
node :
url : https://node.example.com:9092
verify : false
user : node_user
pass : _the_password_here_
folder_upload : /Upload
faspex :
url : https://faspex.example.com/aspera/faspex
user : faspex_user
pass : _the_password_here_
cos :
endpoint : https://s3.eu-de.cloud-object-storage.appdomain.cloud
bucket : my_bucket
key : _the_key_here_
crn : ' crn:v1:bluemix:public:cloud-object-storage:global:_the_crn_:: '
auth : https://iam.cloud.ibm.com/identity/token
coscreds :
bucket : mybucket
service_credential_file : ./service_creds.json
region : eu-de
aoc :
org : acme
user_email : [email protected]
private_key : /path/to/my_aoc_key
client_id : aspera.global-cli-client
client_secret : frpmsRsG4mjZ0PlxCgdJlvONqBg4Vlpz_IX7gXmBMAfsgMLy2FO6CXLodKfKAuhqnCqSptLbe_wdmnm9JRuEPO-PpFqpq_Kb
workspace : Default
shared_inbox : TheSharedInbox
Remarque : Les sections avec des URL HTTPS ont un paramètre
verify
. Définissez-le surfalse
pour désactiver la validation des certificats de serveur pour les environnements de développement.
Certains chemins relatifs sont définis dans config/paths.yaml
(conservez ces valeurs intactes).
Les niveaux de journalisation suivants peuvent être définis :
misc.level
: exemple de niveau de journalisation du code : error
warning
info
debug
trsdk.level
: niveau de journalisation asperatransferd : trace
info
debug
error
warning
, panic
fatal
trsdk.ascp_level
: niveau de journalisation ascp : info
de debug
trace
Certains exemples prennent en charge la définition du port sur 0
(zéro) dans trsdk.url
pour utiliser un port aléatoire.
Un exemple d'application génère un fichier asperatransferd.conf
fourni au démon SDK de transfert, les niveaux de journalisation sont extraits du fichier de configuration général yaml.
Le SDK de transfert est un service gRPC qui vous permet de transférer des fichiers dans une application. Il s'agit d'une API client qui peut être utilisée dans différentes langues.
Le fichier transfer.proto
décrit dans l'interface d'appel de procédure distante fournie par le démon asperatransferd
.
+----------------+
+ transfer.proto +
+----------------+
|
[protoc]
|
v
+----------------------+ +------------+
+ generated stub code + + your code +
+----------------------+ +------------+
| [combine] |
+-----+----------------------+
|
v
+------------+ +---------------------+
| client app |-----[connect to]---->| Transfer SDK daemon |
+------------+ +---------------------+
| ^ | [executes]
+-------------[executes]----------------+ v
| +------+
[or other method, systemd, or manual]---[executes]------+ | ascp |
+------+
Les applications client doivent utiliser les fichiers source client générés à partir du fichier transfer.proto
.
Le code (stub) généré est fourni pour plus de commodité dans le SDK de transfert pour plusieurs langues. Il peut être utilisé directement ou le développeur peut choisir de les générer à partir du fichier transfer.proto
. Pour la production et la compatibilité future, il est recommandé de générer le code stub à partir du fichier transfer.proto
. Si vous générez vous-même du code stub, vous pouvez bénéficier de la prise en charge des dernières plates-formes et versions.
La plupart des exemples ici génèrent le code stub à partir du fichier transfer.proto
.
Reportez-vous au site Web GRPC pour obtenir des instructions sur la façon de générer le code.
Les exemples de programmes utilisent des classes d'assistance situées dans le package utils
:
Configuration
lit les paramètres de configuration à partir de config.yaml
afin de faciliter l'exécution des exemples.TransferClient
crée un fichier de configuration et démarre le démon Transfer SDK : asperatransferd
Rest
pour des appels d'API simples sur les API Rest.Le SDK Transfer nécessite les fichiers d'exécution suivants :
asperatransferd
: exécutable qui fournit le service gRPCascp
: exécutable qui transfère réellement les fichiersascp4
: une autre version d'ascpasync
: exécutable pour les opérations asynchroneslibafwsfeed
: une bibliothèque pour ascp
pour les sockets webaspera-license
: le fichier de licence pour ascp
(utilisation gratuite)Fichiers facultatifs :
aspera.conf
: le fichier de configuration pour ascp
product-info.mf
: fichier XML avec des informations sur la version du SDKaspera.conf
Ce fichier est facultatif pour ascp
lorsqu'il est utilisé en mode client.
Le contenu minimum est :
< CONF />
Il est possible de définir certains paramètres client, comme :
<? xml version = ' 1.0 ' encoding = ' UTF-8 ' ?>
< CONF version = " 2 " >
< default >
< file_system >
< storage_rc >< adaptive >true</ adaptive ></ storage_rc >
< resume_suffix >.aspera-ckpt</ resume_suffix >
< partial_file_suffix >.partial</ partial_file_suffix >
< replace_illegal_chars >_</ replace_illegal_chars >
</ file_system >
</ default >
</ CONF >
asperatransferd
est un démon qui doit être démarré avant d'utiliser le SDK de transfert. Il pilote le transfert de fichiers entre deux points de terminaison à l'aide de ascp
intégré. L'application client s'y connectera à l'aide de gRPC sur le port spécifié.
La manière de démarrer le démon n'est pas spécifiée dans le SDK. Les développeurs ont le choix de le démarrer manuellement dans un terminal séparé ou de créer un fichier de configuration statique et de le démarrer en utilisant une autre méthode (par exemple, un service systemd).
Les exemples fournis ici démarrent le démon à l'aide de la classe TransferClient
.
Lorsque asperatransferd
démarre, si aucun fichier de configuration n'est fourni avec l'option --config
, alors il s'attend à trouver ascp
, ascp4
, async
, libafwsfeed
, aspera-license
dans des dossiers spécifiques. Afin de placer tous les fichiers dans le même dossier, le fichier de configuration doit être fourni et les dossiers doivent être définis.
Le Makefile fourni dans les exemples télécharge le SDK et l'extrait dans un seul dossier, puis les exemples génèrent le fichier de configuration en conséquence.
Reportez-vous à la documentation HSTS pour créer un utilisateur et obtenir les informations d'identification.
En règle générale, un utilisateur de l'API de nœud est créé comme ceci :
/opt/aspera/bin/asnodeadmin -a -u my_node_username -p my_node_password -x my_transfer_user
Remarque : Les informations d'identification de la clé d'accès (identifiant et secret) peuvent également être utilisées pour l'utilisateur de l'API du nœud.
Shares fournit les API suivantes :
<shares url>/node_api
.Les mêmes exemples que pour l'API Node peuvent être utilisés pour les partages .
Pour Aspera on Cloud, plusieurs éléments de configuration sont requis :
org
: L'organisation AoC, c'est à dire le nom avant .ibmaspera.com
dans l'URLuser_email
: IBMid de l'utilisateurprivate_key
: Le chemin d'accès au fichier PEM contenant la clé privée de l'utilisateur. L'utilisateur a configuré la clé publique associée dans son profil d'utilisateur AoC.client_id
: (voir ci-dessous) L'identifiant de l'application clientclient_secret
: (voir ci-dessous) Le secret de l'application client client_id
et client_secret
peuvent être :
aspera
:aspera.global-cli-client
frpmsRsG4mjZ0PlxCgdJlvONqBg4Vlpz_IX7gXmBMAfsgMLy2FO6CXLodKfKAuhqnCqSptLbe_wdmnm9JRuEPO-PpFqpq_Kb
Par exemple pour extraire ceux d'Aspera Connect (Drive) : strings asperaconnect|grep -B1 '^aspera.drive$'
Pour tester les transferts vers COS, vous aurez besoin de :
C'est la valeur par défaut dans l'exemple.
Ou il est également possible d'utiliser :
private/service_creds.json
, suivez : obtenez les informations d'identification du service