Oracle Data Integrator SubstitutionAPI：置換手順。 パート1

置換％？$ @

落ち着いた 「％？$ @」はe曲表現ではなく、異なるタイプのBeanShell置換に使用される特殊文字です。 このようにして、すべてを一緒に使用することを決めた開発者が、それらについていくつかの微妙なことを言うことができませんでしたが。 一方、それはスクリプトで実行されるコードの柔軟な生成を提供する非常に強力なツールです。



置換はいつどこで実行されますか？ ソース文字列ごとにターゲットコードで繰り返されますか？ 異なるレベルの置換をネストできますか？ そして同じ？ Java変数を宣言した場合、どこでそれを使用できますか？ Substitution API関数が動作しない場合と動作する場合があるのはなぜですか（どの機能が適用可能な置換レベルで文書化されていないのですか）。 などなど。 これらの不十分に文書化された微妙さについて、一連の記事が取り上げられています。 そして、これが彼らの最初です。



ルックアップに共通するのは、 BeanShellスクリプトがルックアップ内で実行されることです。 置換処理は、JSPまたはPHPの解析を連想させます。 同様に、短縮構文と完全構文の2つの置換構文が区別されます。 省略形では、置換には、実行時にこの置換を置き換える結果を持つ式のみが含まれます。

<%=odiRef.getSysDate("yyyy-MM-DD HH:mm:ss.SSS")%>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

完全な構文には、 out.print（）を使用して何かを「印刷」できる、またはまったく印刷しないが、他の有用な作業を静かに実行できる完全なBeanShellコードが含まれています。 後者の場合、置換を実行した後、トレースを残さずにコードから単純に削除されます。

 <%out.print(odiRef.getSysDate("yyyy-MM-DD HH:mm:ss.SSS"));%>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

参照レベル

％レベル

<％...％>の形式の置換は、セッションを開始したホストで物理置換が実行される前であっても、セッションの開始時に直ちに実行されます。 つまり、デザイナーからODIセッションを開始すると、ワークステーションで％置換が実行され、置換スクリプトが、たとえばファイルシステムにアクセスすることを決定した場合（およびBeanshellには、すべてのJava機能に加えて、独自のネイティブ機能があります） ）、ローカルディスクが表示されます。 すでにアセンブルされたODIスクリプトが起動されるとき-InvokeStartScen操作を呼び出すか、スケジューラから起動する場合、起動を開始するクライアントはODIエージェント自体です：％置換を実行する物理的な場所はODIエージェントサーバーです。



％置換の実行中に例外が発生した場合、フォールは発生しません。 エラーのスタック全体が出力で除外され、置換の結果になります。 この結果はソースコード（既に無効）になり、次のレベルで解釈が試行され、そこでセッションがクラッシュします。



この置換は、変数の設定および変数の評価ステップ内では機能しません。 つまり、そこでは通常のテキストとして認識され、いかなる方法でも処理されません。



このレベルからは、ソース接続またはターゲット接続のいずれにも接続できず、作業リポジトリにのみ接続できます。 すなわち odiRef.getJDBCConnection（「WORKREP」）はすでに使用可能ですが、他の引数を持つこの関数もgetJDBCConnectionFromLSchema（）も機能しません。 接続がまだ存在しないため、セッションの作業はまだ開始されていません。

レベル？

そのため、スクリプトはすでにエージェント内にあり、実行を開始しています。 セッションが作成されました。 最初のステップ（ステップ）では、コードの最終的な形成が行われます。エントリがSNP_STEP_LOGに表示され、このステップのすべてのタスクの最終的なコードが生成されます。 これは、置換<？...？>が実行される場所です。 正常に実行された後（または置換がない場合）、エントリがSNP_SESS_TASK_LOGに作成され、そこに結果が配置されます（最終コード）。 解釈中にエラーが発生した場合、 SNP_SESS_TASK_LOGのエントリは作成されず、エラーメッセージはSNP_STEP_LOGで上で検索する必要があります。 ステップ全体が準備されると、すぐに実行が開始されます。 The？置換インタープリターは、次のステップの前に作業を再開します。



？-変数の設定手順と変数の評価手順でも、同様に置換は無視されます。 この置換では、ソースおよびターゲット接続を使用し、odiRef.getJDBCConnection関数で取得することがすでに可能です。 これは、柔軟なコード生成のために、テーブルのどこかにあるデータを使用できることを意味します。

レベル$

これはタスクが完了する直前に実行される特別なレベルであり、この置換の結果はSNP_SESS_TASK_LOGのレコードを更新するために使用されます。 さらに、$置換が何かを出力し、ODI変数が置換内で使用される場合、ログでは、通常のように名前ではなく変数の値が表示されます。 つまり、この置換を効果的に使用して、オペレータログの変数の値を確認できます。



さらに、$置換は、 odiRef.setTaskName（）関数をコールできる唯一の場所です。この関数は何も出力しませんが、ログ内のタスクの名前を変更します。 実際、これらは$置換が有用なアプリケーションの2つの領域のみです。



また、この置換は、変数の設定および変数の評価ステップでも機能しません。

レベル@

最終的なタスクコードは、最終的なものではありません。 最終コードの解釈と実行は、テクノロジーに対応する言語で実行されますが、任意のテクノロジーのコードにJava BeanShellコードの@置換を含めることができます。 当然、置換が最初に実行されます。 彼女が何かを印刷する場合、実行前にタスクの「最終」コードをさらに変更します。



@置換は、変数の設定ステップで適用できます。 したがって、Java式の結果をODI変数に簡単に割り当てることができます。 変数の評価では、まだ何もできません。 置換中に例外が発生した場合、セッションは現在のステップに分類されます。

ソースまたはターゲット、最初は誰ですか？

ODIのセッションはすべてステップで構成され、各ステップには1つ以上のタスクがあり、各タスクには常に2つの肩（ソースとターゲット）があります。 たとえば、リフレッシュまたはODI変数のセットは、空の本体ソースを使用する場合と同じタスクです。 代替は両方の肩にある可能性があるので、どちらがより早く実行されるかを知ることは興味深く、時には重要です。 なぜなら、最初にjava変数を宣言して割り当ててから使用することが重要だからです。



驚いたことに、％置換、？ および$は、最初にターゲットレバレッジに対して実行され、次にソースに対して実行されます。 しかし、@置換は逆です。



このプロパティを知っていれば、変数、関数、スクリプトオブジェクト、および通常のBeanShellクラスを正しく初期化してから、それらを正しく使用できます。

@置換の繰り返し

他のレベルでは、すべてが簡単です。 最初にターゲットが解釈され、次にソースが解釈されます。 レベル@では、すべてが異なり、多くの要因に依存します。



prepareStatementをサポートするソースおよびターゲットの肩でOracleテクノロジーを選択したとしましょう。 また、両方の肩に@置換があります。 この状況では、制限が適用されます。ソースで使用できるのはselectのみです。 例えば、あちこちでpl / sql-blockを実行することは不可能です。



ソースショルダーに空でないコードがある場合は、最初に実行されます。 したがって、ソースコードを実行する前に、ソースコードで置換を1回実行します。



ソースは、ODIがキャッチする必要があるResultSetを提供し、フェッチごとにターゲットレバレッジの実行を試みます。 ソースフィールドにアクセスするには多くの方法があります。 エントリFIELD_NAMEまたは＃FIELD_NAMEを使用できます。 ターゲットテクノロジドライバーがprepareStatement操作をサポートし（これはすべてのJDBCドライバーで一般的です）、フィールドにFIELD_NAME表記のみが使用される場合、ODIは@置換とprepareStatementを1回実行します。 そして、フェッチごとに変数バインディングとステートメント実行のみを実行します。



少なくとも1回、＃を介した呼び出しがフィールドに使用される（単純なテキスト置換を意味する）場合、またはドライバーがprepareStatementをサポートしない場合、ターゲット演算子の形成は各反復で特別な（個々の）ため、@置換が何度も実行されます。



例を考えてみましょう：



ソース：

 <@long i=0L;@> select f1, f2 from table /*    10  */
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ターゲット（オプション1）：

 begin stored_Procedure(<@=++i@>, :f1, :f2); /*     = 1,      1   prepareStatement */ end;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ターゲット（オプション2）：

 begin stored_Procedure(<@=++i@>, #f1, #f2); /*    = 1, 2, 3.....   ,       ,       i   10, ..   */ end;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初のバリアントでは、prepareStatementの発生時に@置換が1回実行されます。 そして2番目に、各フェッチは新しい演算子テキストの形成と@置換の新しい実行を引き起こします。



ターゲットテクノロジーがprepareStatementを実行する機能を提供しない場合（たとえば、OdiTools）、コロンを介してソースフィールドにアクセスすることは不可能か、＃と変わりません。



将来の記事では、Substitution APIの置換と使用に関連する他の問題について検討します。 特に、 次回は同じレベルと異なるレベルの順列の再帰的な解釈を含むネストについて説明します。 多くの予期しない発見があなたを待っており、あなたは何度も叫ぶでしょう：「ああ、これがそのように働く理由です！」