共通¶
エラーページをカスタマイズすると IFRAME リダイレクタの IFRAME 内にエラーページが表示されます。¶
http404.jsp などをカスタマイズすると IFRAME リダイレクタ内でエラーが発生した場合にグローバルナビなどが表示されたままとなります。上記の場合、下記の回避策があります。カスタマイズしたエラーページのDOM要素#im_error_url にエラーページ自体のURLを設定することで回避することが可能です。
アカウントコンテキストの入力用日付フォーマットを変更すると、日付に関する処理が正しく行えない場合があります。¶
何らかの処理の途中で、アカウントコンテキストの入力用日付フォーマットの変更を行ってはいけません。変更した場合、日付に関する処理が正しく行われない可能性があります。
ユーザコンテキストの departmentByCompany と postByCompany が undefined になります。¶
下記の場合、departmentByCompany と postByCompany がコンバートに失敗します。
- companyCdに「-」を使用した場合のUserContextの戻り値
- 会社コードの先頭に[-」をつかって数値になった場合
DEBUG レベルでログ出力すると、アカウントのパスワードが書き込まれる場合があります。¶
DEBUG レベルでログ出力すると、アカウント情報の追加・更新・削除などの変更を行った際に、パスワードを含むアカウント情報がログに出力されることがあります。DEBUG レベルでのログ出力はあくまで開発向けであり、開発時以外の環境ではログレベルをINFO 以上としてください。
検索画面で大文字・小文字を区別して検索を行う画面があります。¶
各画面のキーワード検索機能において、アルファベットの大文字・小文字を区別して検索を行うものがあります。以下の画面が該当します。
- 認可設定画面
例えば “IFRAME” という名称でデータが登録されている場合、 “iframe” で検索してもヒットしません。
Windows 環境で、小文字のURLに大文字でアクセスした場合、不正な動作をする場合があります。¶
Windows環境では、 Web Application Server の設定によってURLを大文字小文字を区別せずアクセス可能とする場合があります。intra-mart Accel Platform のURLのパスは、基本的に小文字で定義されているため、大文字でURL入力した場合、正常に動作しない場合があります。
APIを利用しないで直接データを更新、削除することは強く推奨しません。¶
- APIを利用しないで直接テーブルのデータ更新、削除を行った場合、以後の画面、APIの動作に関して保証しません。
URL リライティングによるセッション管理方式は利用する事ができません。¶
URLリライティングによるセッション管理方式は、第三者にセッションハイジャックされる可能性があります。intra-mart Accel Platform がサポートするブラウザは Cookie の利用が可能です。必ずCookieによるセッション管理方式を利用してください。
アカウントとプロファイルは同期している必要があります。¶
アカウントのみ、プロファイルのみのデータを作成した場合、メンテナンスができなかったり、正常に動作しない機能があります。必ず同期するようにしてください。
データベースログ用の設定を行うと、起動時にエラーレベルのログが出力されます。¶
データベースログ用の設定を行うと、起動時にエラーレベルのログが出力されますが動作上は問題ありません。なお、データベースログは非推奨となりました。ご利用の Database に適したログツール等の利用を強く推奨します。<!-- - Parameter for intra-mart only --> <intra-mart> <database> <log sqlparam="false" isEnabledMode="CALLER_CLASS_NAME" /> </database> . . .コラム
起動時の出力されるログ
[12-10-01 00:00:00.000] {main} !!!! Please check your LOGBACK configuration file !!!!
URLに「%28」(エンコードされた「(」)を利用する事ができません。¶
- URLに「%28」(エンコードされた「(」)を使用した場合、エラーログが出力されます。
スクリプト開発モデルにおける制約があります。¶
- 以下のAPIを利用し、オブジェクトの永続化を行った場合、その内容をJava APIを利用し直接取得することはできません。
- Client#set
- Permanent#set
- Cache#set
- Module#external#set
Archiver4Storage でzipファイルを出力した場合、OSにより区切り文字が異なるため正常に解凍できない場合があります。¶
Windows 環境かつ、Version7.2 以前の環境において Archiver4Storage API を利用し出力した zip ファイルはLinux/Unix 環境上でファイルの解凍を行った場合、正常に解凍が行えません。
Base URL を設定した場合、複数のURLで同じアプリケーションサーバにアクセスできる環境の場合、ログインに失敗する可能性があります。¶
Base URL は、WEB-INF/conf/server-context-config.xml で設定できます。Base URL を設定した場合、画面上のリンクや画面遷移では、Base URL を基準に遷移します。ただし直接画面にアクセスする場合は、入力されたURLで正常に表示され、その後画面遷移した場合に、Base URL を基準としたURLでアクセスされます。直接アクセスした場合のURLと Base URL のドメインが異なる場合、Cookie の基準ドメインが異なるため、セッションが維持できません。そのため予期せぬエラーが発生する場合があります。ローカル環境では、ログイン画面には以下のURLでアクセス可能です。
- http://localhost:8080/imart/login
- http://127.0.0.1:8080/imart/login
- http://<IPアドレス>:8080/imart/login
- その他
Base URL と アクセスしたURLが異なる場合、ログイン画面は正常に表示されますが、ログインを実行するとSecureTokenのチェックが実行されますが、セッション情報が参照できないため、権限エラー(HTTP403)となります。もし、権限エラーでログイン出来ない事象が発生した場合、Base URLを確認して下さい。
スクリプト開発モデルにおいて、夏時間を表す日時を扱う場合に日付オブジェクト(Date)の文字列表現への変換が正確に行われません。¶
JavaScript の Date インスタンスが、以下の条件を全て満たす場合、Dateインスタンスから日付の文字列表現への変換が正確に行われません。(1時間ずれた日時になります。)
1970 年以前の日付である。
Web Application Server が稼動しているJavaVMのデフォルトタイムゾーンにおける夏時間の期間内である。※ この現象は、スクリプト開発モデルエンジン(Rhino)の仕様によるものです。例えば、システムタイムゾーンの日時データを、ユーザのタイムゾーン、および、指定した表示形式(例:「yyyy/MM/dd HH:mm:ss」形式)を使って日時文字列に整形するとします。Web Application Server のタイムゾーンがJST(日本標準時)になっている場合に以下のコードを実行するとvar date = new Date(1948, 7, 1, 0, 0, 0); var dateString = DateTimeFormatter.format('yyyy/MM/dd HH:mm:ss', date); Debug.browse(date.toString(), dateString);実行結果は、以下のようになります。
- date.toString() → Sun Aug 01 1948 00:00:00 GMT+0900 (JST)
- dateString → 1948/08/01 01:00:00
まず、タイムゾーンを意識したアプリケーションを実装する場合は、DateTime API を利用して日時を扱ってください。上記の現象は DateTime API を利用して日付を扱うことで文字列表現への変換を正確に行うことができます。var systemTimeZone = SystemTimeZone.getDefaultTimeZone().data; var dateTimeSystemTZ = new DateTime(1948, 7, 1, 0, 0, 0, systemTimeZone); var dateTimeUserTZ = dateTimeSystemTZ.withTimeZone(Contexts.getAccountContext().timeZone).data; var dateString = DateTimeFormatter.format('yyyy/MM/dd HH:mm:ss', dateTimeUserTZ); Debug.browse(dateString);実行結果は、以下のようになります。
- dateString → 1948/08/01 00:00:00
なお、「スクリプト開発モデル プログラミングガイド」および「SAStruts+S2JDBC プログラミングガイド」に、「国際化プログラミングのサンプル」が提供されております。あわせてご参照ください。次に、タイムゾーンを意識した運用を行わない場合は、以下の設定を行うことで上記の現象を回避できます。
タイムゾーンマスタに Etc/GMT形式 の タイムゾーンID を追加します。WEB-INF/conf/time-zone-config/im-time-zone-config.xml を開き、time-zone-idタグを追加します。タイムゾーンマスタについては設定ファイルリファレンスを参照してください。<time-zone-config> <time-zone-id>Etc/GMT-9</time-zone-id> </time-zone-config> Web Application Server が稼動しているJava-VM のシステムプロパティ「user.timezone」に、Etc/GMT形式 の タイムゾーンID を指定します。Resin の場合、<%RESIN_HOME%/conf/resin.properties>を開き、「jvm_args」プロパティに「-Duser.timezone」を設定します。# Arg passed directly to the JVM jvm_args : -Xmx1024m -XX:MaxPermSize=256m -Duser.timezone=Etc/GMT-9 テナントのタイムゾーンを Etc/GMT形式 の タイムゾーンID に変更します。システムデータベースの im_tenant_info テーブルの time_zone_id の値を Etc/GMT-9 に変更します。または、テナント管理機能のテナントタイムゾーン変更画面で値を変更します。(GMT+09:00を選択します) すべてのユーザのタイムゾーンを Etc/GMT形式 の タイムゾーンID または 未設定 に変更します。ユーザのタイムゾーンは、データベースの値を直接変更することでも設定可能です。具体的には、テナントデータベースの b_m_account_b テーブルの time_zone_id の値を null または Etc/GMT-9 に変更してください。
テーブル名のプレフィックスは intra-mart Accell Platform の予約語になります。¶
- 次のテーブル名はプレフィックスとして利用できません。
- b_m_*
- b_vc_*
- bk_imm_*
- im_*
- imaz_*
- imjob_*
- imm_*
- imw_*
複数テナントを構築する場合、接続先のDatabaseはインスタンス単位で分ける事を推奨します。¶
- 複数テナントを構築する場合、接続先のDatabaseはインスタンス単位で分ける事を推奨します。