Rubyで1Cをプログラミングします

OLE 1Cシッククライアント管理メカニズムは、すべての機能とデータへのフルアクセスを提供します。 これにより、1Cまたはその外部システムとの統合をカスタマイズするときに、組み込みプログラミング言語をまったく使用せず、したがって、構文、機能、およびランタイムに制限されないようにすることができます。



代わりに、Win32 OLEを操作するためのライブラリを備えた最新の言語を使用できます。 たとえば、JavaScript（Win32 OLEはNode.JSをサポート）またはRuby（必要なライブラリは標準言語ライブラリのセットに含まれています）。



RubyでのOLEインターフェイスの実際の経験を以下に説明します。 説明は完全なふりをするのではなく、データレベルでの単純な自動化または統合に必要なもの（ディレクトリおよびドキュメントの読み取りと書き込み、要求の実行）のみを選択して説明します。

なんで？

1Cはロシアの膨大な数の企業を使用しており、ほとんどの企業は1Cで何かを変更したり、何かと統合したりする必要性を感じています。 同時に、多くの場合、高速で安価であることが必要です。



このため、1Cには通常の機能があります。

• コンフィギュレーターを使用して構成を変更することにより、システムのデータ構造を変更します。
• 構成または外部「処理」の一部としてソフトウェアモジュールを介してシステムのロジックを変更する。
• OLEまたはCOMインターフェイスを介したユーザーの職場でのシステムの「シッククライアント」との対話。

しかし、ここでは、いつものように、いくつかの「しかし」がある。



まず、構成を変更したくないのは、サポートから構成を削除する必要があると思われるため、更新が困難になるためです。



第二に、私は1Cプログラミング言語を学習して、1C以外のどこかで無駄になっているため、私的な問題をいくつか解決したくありません。



そして、ここでOLEアクセスが本当に役立ちます。これにより、1Cクライアントで、コンピューターに座っているユーザーができること（さらにはそれ以上）を実質的にすべて実行できるようになります。 win32ole。



Rubyについては、繰り返すことのできない多くの歌を歌いました。 これは、優れたエコシステム、低エントリーしきい値、多数のオープンライブラリ、フレームワーク、製品などを備えた、美しく便利で有望な開発言語です。



そして、それから強力なツールが得られます1）社内で約1秒の自動化、2）企業システムと外部基盤との統合、3）など。 など また、Rubyフレームワークの力を考えれば、Railsでさえ、自動化は小さくないかもしれません。

OLEサーバーと1Cクライアントの起動

開始するには、RubyがインストールされたWindowsコンピューターと1Cシッククライアントが必要です。 Rubyおよび1Cのバージョンは基本的なものではありません。以下のすべては、異なるRubyおよび異なる1C（8.1、8.2、8.3）でテストされています。 もちろん、1Cクライアントは1Cデータベースにアクセスできる必要があり、サーバーアドレス、このサーバー上のデータベースの名前、このデータベース内のユーザーのユーザー名とパスワードを知る必要があります。



これでcmd.exeコンソールを起動し、その中のirb Rubyインタープリターを開き、win32oleライブラリをロードして作業を開始できます。 しかし、ここで最初の微妙な問題が発生します：irbはコンソールのコーディングで機能し（標準のWindowsコンソールの場合は866コーディングです）、OLEはWINDOWS-1251コーディングを望んでおり、ところでエラーが発生します。 したがって、次のコマンドでコンソールのエンコードを切り替える価値があります。

chcp 1251
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初のステップは、OLEサーバーを取得することです（例8.2を使用）。 2つ目の微妙な点があります。 「通常の」サーバーを使用すると、すでに開いているアプリケーションに接続できます。次に例を示します。

 server=WIN32OLE.connect 'Excel.Application'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

1Cでは、何らかの理由でこれは機能しません。少なくとも私にとってはうまくいきませんでした。 したがって、新しいOLEサーバーを作成し、1Cクライアントを手動ではなく、OLEサーバーを介して開きます。

 server=WIN32OLE.new "V82.Application" server.Connect("Srvr=\”myserver\”;Ref=\”mybase\”;Usr=\"me\";Pwd=\"mypassword\"") server.Visible=true
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

（サーバーは、1Cクライアントを非表示の状態で開き、最後の行で表示しました。）

グローバルコンテキストで作業する

サーバー変数で、Win32OLEクラスのルートオブジェクトを取得しました。 ドキュメントによると、単一のVisibleプロパティと、 Connect 、 NewObject 、およびStringの 3つのメソッドがあります 。



ただし、これを介してのみ、グローバルコンテキスト1C（1C自体ではオブジェクトなしで直接呼び出されます）のメソッドにアクセスできます。



最初、これらのメソッド（およびすべてのメソッド）の名前はロシア語であるため、（ドットを介して）直接アクセスすることはできませんが、invokeメソッド（パラメーターを使用して呼び出す場合）を使用するか、角かっこ（パラメーターを使用しない場合）を使用する必要があります：

 server.invoke(''[, ...]) #  server['']
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

例は、取引先ディレクトリでの要素検索です。

 element=server[''][''].invoke('','000000001')
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

8.2ではほとんどすべてのメソッドに英語の同義語がありますが、8.1ではわずかです。 英語のシノニムがある場合は、ドットを使用して通常のメソッドとして呼び出します。



もう1つの微妙な点があります。「ラップされた」1Cオブジェクトのメソッドは大文字と小文字を区別しませんが、ドキュメントと1Cコンフィギュレーターで説明されているように、大文字で書くことができます。 もしそうなら、同じ方法でRubyコードで大文字で書くのが便利です。そのため、どのメソッドがRubyのネイティブメソッドであり、実際にどのメソッドがWIN32OLEでラップされているかをすぐに見ることができます



呼び出し['Directories']はDirectoriesManagerオブジェクトを、呼び出し['Counterparties ']はCounterpartiesディレクトリのDirectoryManagerオブジェクトを、 呼び出し呼び出し（ 'Find By Code'）は Directoryオブジェクトを提供します。 これらのオブジェクトはすべてWIN32OLEクラスのオブジェクトにラップされているため、特定の不便が生じます。Rubyオブジェクトを操作する通常の方法は機能しません。たとえば、ラップされたオブジェクトクラス、メソッドのリストなどが表示されません。 たとえば、特定の呼び出しを使用する必要があります。

 server.String(element) #      element.Metadata.Name #   element.Metadata.FullName #  ,     uuid=server.String(element.Ref.UUID) #  UUID  element=server[''][''].GetRef(server.NewObject('UUID',uuid)) #     UUID
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さらに、作業の過程で、主に適用されたオブジェクトのコレクションを習得する必要がありました（それらの操作については、以下で詳しく説明します）。

• server ['Directories']またはserver.Catalogs 、
• server ['Documents']またはserver.Documents 。

より複雑な場合やパフォーマンスを改善するために、1Cクエリ言語でクエリを記述する必要がある場合があります。 query = server.NewObject（ 'Request'）を呼び出すことで作成されます。



上記は、1C関数の統合と拡張の問題を解決するのに十分でした。 要するに、これはいくつかのディレクトリを外部システムにアップロード/同期し、1Cの関連ドキュメントのパッケージを外部システムから自動的に処理し、1Cから外部システムにいくつかの要約データを受信します。



残りの資金1Cはまだ必要ではないため、ここでは考慮しませんが、同様の方法で分解できます。 これに関する主な情報源は、すべてのアプリケーションオブジェクトのデータ構造がペイントされる1Cコンフィギュレータです。また、1Cオブジェクトのプロパティとメソッドを説明するSyntax-Helperヘルプシステムもあります。



アプリケーションオブジェクトの詳細。

ディレクトリ

彼らはどのように配置されていますか？

参照1Cは（必ずしもそうではありませんが）階層的である場合があります。 次に、要素には呼び出しによって受信された親があります。

 parent=element[''] #  parent=element.Parent
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

参照が階層的である場合、要素の階層またはグループと要素の階層という2つのオプションがあります。 さらに、デフォルトではグループと要素はヒープによって発行されます。それらをソートするには、呼び出しを監視する必要があります（trueまたはfalseを返す）。

 element[''] #  element.IsFolder
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

element-groupは、element-elementとは異なり、標準属性（または1Cの観点からは詳細）のみを持ちます。 ディレクトリは依存している場合があります。 参照所有者がいる場合があります。 次に、要素には所有者があります-呼び出しによって取得された所有者ディレクトリの要素：

 owner=element[''] #  owner=element.Owner
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでも、微妙です。 オーナーガイドは多少異なる場合があります。 「所有者」関係は、ある意味で、多態的です。 そのため、所有者を受け取った後、上に示すように、そのタイプを調べることも理にかなっています： owner.Metadata.FullName 。



ディレクトリの各要素には、要素の番号付けである標準属性Code（Code）があります。 通常、要素には自動番号が付けられますが、いつものように微妙な点があります。

• 品目コードは変更可能
• 要素コードの一意性は、親内または所有者内のディレクトリ設定によって制限される場合があります。

そのため、コードをグローバル参照識別子として使用することは常に良い考えとは限りません。 このため、ディレクトリ内で一意であり、変更できないUUIDを使用する方が適切です。

標準属性のリスト：

• これはGroup 、 IsFolderです -グループ要素階層を持つディレクトリに対してのみ意味があり、
• コード 、 コード -常にそこにあり、
• 名前 、 説明 -常にそこにあり、
• Parent 、 Parent-階層ディレクトリに対してのみ意味があります。
• Owner 、 Owner-依存ディレクトリに対してのみ意味があります。
• マークの削除 -常にあり、
• Link - Ref-常に存在し、オブジェクトReference。Linkを返します。 GetObjectメソッドを使用して、リンクから要素を取得できます。 アイテムのタイプはディレクトリオブジェクトです。 それらが分割された理由はあまり明確ではありませんが、それぞれの特定のケースで必要なものを科学的に突くことによっていつでも判断できます。オブジェクトが必要ない場合は、代わりにリンクを試してください。
• 事前定義 、 事前定義 -不要、使用されていません。

ディレクトリにフォームがある場合、ディレクトリの要素はリクエスト要素.GetForm.Openを使用してクライアント1Cで開くことができます。

リスト閲覧

SelectまたはSelect （Counterpartiesディレクトリなど）を呼び出すことにより、ディレクトリアイテムを取得できます。

 selector= server[''][''].Select(parent,owner) #  parent, owner -   while selector.Next do #  -    end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

セレクターで、DirectorySampleオブジェクトを取得します。 true / falseを返すNextメソッドがあります。 trueが返された場合、この要素の属性とメソッドを要求できるという意味で、セレクタに次の選択要素が含まれていることを意味します。

parentが指定されている場合、指定された所有者の所有者であれば、指定された親の選択を取得します。 所有者のみでフィルタリングする場合、親ではなくnilを設定します。



直接の子孫だけでなく、この親の下の階層全体を取得する場合は、 Selectの代わりにSelect HierarchicallyまたはSelectHierarchicallyを記述します。



これらのメソッドにはSelection属性とOrder属性もありますが、私はそれらを理解していませんでした。選択と順序が必要な場合、 Queryクエリを作成しました（以下を参照）。



標準属性に加えて、要素には特定の属性があり、そのリストとタイプはコンフィギュレーターで表示する必要があります。 タイプは基本的なものでも、アプリケーションオブジェクト1Cへの参照でもかまいません。 詳細が不要な場合は、 server.Stringメソッドを使用して任意の型を文字列に変換できます。



属性はポリモーフィック、つまり いくつかのタイプから選択できます。 その場合は、通常どおり、タイプを確認します。

 selector[''].Metadata.FullName
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

属性に加えて、いわゆる表部分が存在する場合があります。 テーブルパーツは属性と同じ方法で名前で取得でき、奇妙なセレクターは返されませんが、ブロック内の「テーブルパーツ行」オブジェクトを表示するeachメソッドを持つほぼ配列です。 （ただし、配列ではありません。たとえば、collectメソッドとeach_with_indexメソッドはありません。）行には、標準のLine NumberまたはLineNumber属性に加えて、コンフィギュレーターで指定された属性があります。

単一のアイテムを取得する

いくつかの方法があります：コード、名前、または属性による検索。 最初のことで十分でした-コードによる検索。



呼び出し-Find By CodeまたはFindByCode（code、isfullcode、parent、owner） 。 主な引数が最初で、残りはオプションであり、コードの一意性が親または所有者によって制限されている場合に必要です。 2番目の引数がtrueの場合、コードには、要素のすべての親のコードを/文字で区切って含める必要があります。



1つのアイテムが返されます。

作成、書き込み、削除

新しい要素は、 CreateItem （またはCreateItem ）およびCreateGroup （またはCreateFolder ）メソッドを使用して作成されます。どちらのメソッドにも引数はありません。 例：

 new_element= server[''][''].CreateItem
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

空の未保存アイテムを返します。 コードを空白のままにすると、保存時に自動入力されます。

属性値は、 要素['Attribute Name'] = < attribute value>を呼び出すことによって割り当てられます。 リンク属性には、参照オブジェクトを値として割り当てる必要があります。次に例を示します。

 new_element['']=element.Ref
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

日付属性の記述には微妙な点があります。日付は文字列'yyyymmddhhmmss'の形式で割り当てる必要があります。



列挙リンクの属性を書くことには微妙な点があります。 これは単なる文字列のように見えますが、文字列を受け入れないため、列挙オブジェクトオブジェクトを完全に参照する必要があります。次に例を示します。

 element['']=server['']['']['']
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

引数なしでWriteまたはWriteを呼び出すと、要素が書き込まれます。 たとえば、コードの一意性規則に違反した場合、エラーが返される場合があります。 エラーは通常どおりインターセプトおよび処理できます。または、クライアントの目を通して見るだけで、そこに表示されます。

要素の削除は、SetDeletionMarkまたはSetDeletionMark（deletion_mark、mark_descendants）を呼び出すことによって行われることになっています。 両方の引数はブール値で、最初の引数は削除フラグの実際の値です。 したがって、同じメソッドを使用して、偽の引数を使用して削除のチェックを外す必要があります。 2番目の（オプションの）引数がtrueの場合、呼び出された要素が親または所有者である要素もマークされます。

DeleteまたはDeleteを呼び出すことにより、アイテムを完全に削除できます。 この場合、参照整合性はチェックされないため、データベースを損なうリスクがあります。

ドキュメント

彼らはどのように配置されていますか？

ドキュメントは、番号と日付によって特徴付けられます。 番号の一意性は、採番期間内にチェックされます（1年、1日、またはこのタイプのドキュメントのベース内で、期間なしで一意にすることができます）。



UUIDを使用して、ディレクトリエントリと同じ方法でドキュメントを識別できます。 数字と日付は変更できません。さらに悪いのは、いくつかのドキュメント属性を編集した後に突然変更される可能性があるためです。



ディレクトリ要素に似たドキュメントには、標準および特定の属性があり、表形式の部分を持つことができます。 それらを使用した作業はまったく同じです。



標準文書属性：

• 番号 、 番号 -常にそこにあり、
• 日付 、 日付 -常にそこにあり、日付時刻型、I
• マークの削除 、 DeletionMark-常にあり、
• Link 、 Ref-は常に存在し、その意味はディレクトリアイテムへのリンクに完全に類似しています。
• 投稿済み 、 投稿済み -常にあります。

ディレクトリ要素と同様に、クライアントでドキュメントフォームを開くことができます： document.GetForm.Open 。

ドキュメントは投稿および配布できます。これは、それぞれ次の呼び出しによってドキュメントが保存されるときに行われます。

 document.Write(server.DocumentWriteMode.Posting) document.Write(server.DocumentWriteMode.UndoPosting)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

リスト閲覧

このタイプのドキュメントの受信は、 SelectまたはSelectを呼び出すことによるディレクトリ要素の受信に類似しています（たとえば、バイヤー注文のドキュメント）。

 doc_selector= server[''][''].Select(from, to) while doc_selector.Next do #  -    end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ディレクトリと同様に、Nextを呼び出すたびに、doc_selectorオブジェクトで次の要素が使用可能になります。 オプションのfromおよびto引数を使用して、文字列形式「yyyymmddhhmmss」でドキュメントの日付範囲を指定できます。

単一のドキュメントを取得する

番号または詳細で検索できます。 最初のものは私にとって十分でした-番号で検索します。 呼び出し-FindByNumberまたはFindByNumber（number、interval_date） 。



オプションの引数interval_date（形式は文字列 'yyyymmddhhmmss'）は、番号の一意性の間隔を設定するために必要です。目的の間隔に該当する日付が書き込まれます。

作成、書き込み、削除

すべてが参考書に非常に似ています。



ドキュメントはCreateDocumentまたはCreateDocumentを呼び出すことによって作成され、データベースに保存されていない新しい空のドキュメントを取得します。 保存時に自動番号付けと自動日付割り当てが行われます。



要素は、2つのオプション引数を使用してWriteまたはWriteを呼び出すことにより書き込まれます。 1つ目は記録モードです（伝導の有無にかかわらず、上記を参照）、可能な値は次のとおりです。

 server.DocumentWriteMode.Posting # (/ ) server.DocumentWriteMode.UndoPosting # (/ )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2番目はドキュメントモードで、可能な値は次のとおりです。

 server.DocumentPostingMode.Regular # () server.DocumentPostingMode.RealTime # ()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ドキュメントの削除は、ディレクトリアイテムの削除に似ています。



削除マーク-削除マークまたはSetDeletionMark（deletion_mark）を設定します。 ブール引数は、削除フラグの値です。 文書の完全な削除-DeleteまたはDeleteを呼び出します（参照整合性はチェックされません）。

お問い合わせ

1Cデータベースへのクエリは、SQLに似たクエリ言語で記述され、さまざまな1Cオブジェクトがエンティティおよび属性として表示されます。

一方、クエリ1Cを使用すると、必要なデータをより正確に選択して集約できると同時に、新しい（まだマスタリングされていない）タイプのオブジェクトを使用してrubyからの複雑な作業を解くことを回避できるという意味で便利です。 しかも-ドキュメントまたはインターネットからのリクエストの例は、リクエストの本文が単なる文字列であるため、1対1で使用できます。 また、コード例をRubyに変換する必要がありますが、これは必ずしも些細なことではありません。



たとえば、Accumulation Registers。Warehouses in Goodsにある倉庫の残高が必要な場合、新しいタイプのオブジェクトを解析するよりもサンプルリクエストを見つける方がはるかに簡単であることがわかりました。



一方、構文ヘルパーにはクエリ言語の説明はなく、1Cのドキュメントを手元に用意する必要があります。



そのため、次の呼び出しによって新しいリクエストが作成されます。

 query=server.NewObject('Query')
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、クエリテキストを入力します。次に例を示します。

 query.Text= ' .  .    .=&  .=&'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、 ＆Nomenclatureと＆CHはリクエストパラメータであり、値を割り当てる必要があります。最初はディレクトリ要素、2番目は行です：

 nom=server[''][''].FindByCode('0001234567') query.SetParameter('',nom) query.SetParameter('','12345678')
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、 実行要求と、 アンロード要求の結果が必要です。

 result=query.Execute.Unload
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

結果には、 NumberまたはCountメソッド-見つかった行の数が含まれます。 行番号（0から始まる）でGetまたはGetメソッドによって結果から個々のレコードを取得し、別のレコード属性を取得します-再度0または0から始まるリクエストの属性番号でGetまたはGetメソッドによって取得します

 sers=(0..result.Count).collect do |i| record=result.Get(i) record.Get(0) end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

重要：SELECTセクションでオブジェクトをリクエストした場合、対応する属性でオブジェクト全体を受け取ります。 この例では、Directory Referenceタイプの命名法シリーズのDirectoryの要素の配列があります。 そして、CHOICE。NameでSeriesを指定した場合、オブジェクトの代わりに対応する行を取得します。



ご清聴ありがとうございました。