おおまかな流れ

パッケージのインストール
コードの確認
AzureFunctionsにpublish、そして確認
余談、パッケージのバージョン指定

パッケージのインストール

今回、Functionsの中でAzureSQLに接続する中で、最初はODBCを使うという選択をしていました。

私が参考にしたコードの中でpyodbcが使われていたんですね。

しかし、これはあんまり上手くない方法だと分かりました。

理由は、ODBCを使うにはシステムにODBCを使うためのインストール作業を行わなければならなかったからです。

aptにMicrosoftのリポジトリを追加して、システムにODBCをインストールし、そのインタフェースとしてPythonインタプリター側にpyodbcパッケージをインストールし、コード内で使っていく、という流れになります。

しかしこうなると、このODBC自体はFunctionsの環境に入っているのか？という疑問が当然起こります。

requirements.txtにパッケージ情報を書くことで、Pythonインタプリターにインターフェースとしてのパッケージをインストールすることはできますが、そのインタフェースの先にODBCコアがなければコードは正常に動きません。

それで調べてみたんですが、どうやらFunctionsの中にはODBC環境はないようでした。

ということで、ODBCを使わずにAzureSQLに接続する方法を探したところ、sqlalchemyと
pymssqlを使えばイケるということが分かりました。

ついては、これらをインストールしていきます。

pip install sqlalchemy
pip install pymssql

ついでにパスワード等、DB接続情報の安全運用を行うため

pip install python-dotenv

もやっておきます。

続いて、コードベースで説明していきます。

コードの確認

こちらがFunctionsのコードの全文となります。

__init__.py

import os
import logging
import json
from datetime import datetime
from sqlalchemy import create_engine, text

from azure.functions import EventHubEvent
from typing import List
from dotenv import load_dotenv

load_dotenv()


def main(events: List[EventHubEvent]):
    server = os.getenv('DB_SERVER')
    database = os.getenv('DB_NAME')
    username = os.getenv('DB_USER')
    password = os.getenv('DB_PASSWORD')

    # SQLAlchemy 接続文字列の作成
    connection_string = f"mssql+pymssql://{username}:{password}@{server}/{database}"
    # SQLAlchemy エンジンの作成
    engine = create_engine(connection_string)

    for event in events:
        # イベントデータの解析
        event_data = json.loads(event.get_body().decode('utf-8'))
        logging.info(
            f"Python EventHub trigger processed an event: {event_data}")

        temperature = event_data['temperature']
        humidity = event_data['humidity']
        create_time = datetime.now()

        try:
            # データベースへのデータ挿入
            with engine.connect() as connection:
                insert_statement = text(
                    "INSERT INTO test_table (create_time, temperature, humidity) VALUES (:create_time, :temperature, :humidity)"
                )
                # パラメータを辞書形式に変換
                params = {'create_time': create_time,
                          'temperature': temperature, 'humidity': humidity}
                connection.execute(insert_statement, params)
                connection.commit()
                logging.info("データベースにデータを挿入しました。")

        except Exception as e:
            logging.error(f"データベースへのデータ挿入中にエラーが発生しました: {e}")

データベースの接続文字列の作り方

冒頭でSQLAlchemy向けのデータベース接続文字列を作っています。

    server = os.getenv('DB_SERVER')
    database = os.getenv('DB')
    username = os.getenv('DB_USER')
    password = os.getenv('DB_PASSWORD')

    # SQLAlchemy 接続文字列の作成
    connection_string = f"mssql+pymssql://{username}:{password}@{server}/{database}"

この内容についてはデータベースの接続文字列の画面から取得することができます。

Server=tcp:<DB_SERVER>,1433;Initial Catalog=<DB_NAME>;Persist Security Info=False;User ID=<DB_USER>;Password=<DB_PASSWORD>;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;

というようなフォーマットでDB接続に必要な各情報が収められていますので、ここから取得して環境変数として保持します。

python-dotenvについて

環境変数に格納するにあたって、.envに書いておき、python-dotenvを使ってロードするとコードの中に重要情報を書き込むことなく、デバッグにもAzureにアップロードした後にも使えていい感じでした。

os.getenv()はローカルデバッグ時にはプロジェクト直下.envに書かれた情報を参照してくれます。

また、Azure環境上にアップロードされた後には、Functionsの「構成」で設定した環境変数を参照してくれます。

したがって、本番コードもデバッグコードも同じコードを使用することができます。

IoT Hubへの接続文字列の追加

構成には、忘れずIoT Hubへの接続文字列も追加しておきましょう。

これは前回の記事で紹介した function.js の "connection": "IoTHubConnectionString"に当たる文字列のことです。ローカルデバッグのときにはlocal.settings.jsonのIoTHubConnectionStringの値を読みに行って接続していましたが、local.settings.jsonはFunction上にアップロードされないため、IoTHubConnectionStringの値はFunctionsの構成に設定しておく必要があります。

AzureFunctionsにpublish、そして確認

ローカルデバッグで動作を確認したら、Functionsにデプロイします。

func azure functionapp publish <function-app-name> --python

下記の表示が出たら成功です。

アップロードできたら、その動作を確認します。

Functionsリソースの概要から、先ほどアップした<function-app-name>の書かれている「名前」欄の項目をクリックします。

更に左側のペインからモニターの画面に行き、ログのタブをクリックしてしばらくするとApplication Insights に接続しています...というメッセージが表示され接続されました。となります。

この状況でIoT Hubに対してメッセージを送信すると、リアルタイムでログが表示されます。

データベースでクエリを発行すると、無事データはDBの中に収められていました。

ただ、create_timeに関してはAzureの中ではUTCが採用されるようなので、このあたり+9時間で入力するかどうかは考えものですね。
デバッグ時にはシステムの時間（日本時間）がcreate_timeに入ってくるので、常に日本時間を入力しようとすると、本番とデバッグ時でコードを変更する必要があり、これは中々面倒な問題です。

余談、パッケージのバージョン指定

最後に余談ですが、AzureFunctions上のランタイムにインストールされるリストとして、requirements.txtを用意する必要がありますが、こちらの内容について、私の場合はバージョンを指定しました。

greenlet==3.0.3
pymssql==2.2.11
python-dotenv==1.0.1
sqlalchemy==2.0.28
typing-extensions==4.10.0

バージョンを指定しない場合、常に最新のバージョンがインストールされることになると思います。
そうなると、バージョン互換性の問題が発生する可能性があります。

バージョンを指定していても、そのバージョンがパッケージリポジトリから削除されたりした場合、逆に問題の原因になりますが、まあバージョンは指定しておいたほうがいいのではないかなと思います。

これらバージョンについてはpoetryを使って抽出することができます。パッケージが依存しているパッケージのバージョンも固めることができ、より運用安全性が増すと思われます。

poetry export --without-hashes -f requirements.txt > requirements.txt