<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Tarant</title>
	<atom:link href="http://tarant.hu/?feed=rss2&#038;lang=ja" rel="self" type="application/rss+xml" />
	<link>http://tarant.hu?lang=ja</link>
	<description></description>
	<lastBuildDate>Wed, 09 Nov 2022 13:45:06 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.4</generator>
		<item>
		<title>FLEXCUBEのビジネスプロセスエンジニアモジュール言語の性能</title>
		<link>http://tarant.hu/?p=561&#038;lang=ja</link>
		<comments>http://tarant.hu/?p=561&#038;lang=ja#comments</comments>
		<pubDate>Sun, 29 May 2011 00:28:18 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Best Practices]]></category>

		<guid isPermaLink="false">http://tarant.hu/?p=561</guid>
		<description><![CDATA[ソフトウェアアーキテクチャの世界でアーキテクチャを重視したサービスは真新しく、強い新規参入者です。組織で適切な方法で採用されれば、その便益も明確にされるでしょう。 FLEXCUBE BPELプロセスモジュールは世界でも優れたコアバンキングソリューションであるFLEXCUBEのSOA（サービス思考型アーキテクチャ）の延長です。FLEXCUBE BPEL プロセスモジュールはワークフローによって動かされ、コアバンキング機能のトップのソリューションをベースとしたタスクを兼ね備えます。 大変優秀な44年の実績を誇る台湾の銀行は機能銀行と小売銀行業務を行っています。FLEXCUBE BPELプロセスモジュールをはじめて選んだ銀行で、彼らのソフトエアエコシステムをサービス型アーキテクチャの可能にしています。 基本的な要件は、貿易金融の要件を解決するタスクによって動かされるSOAビジネスプロセスを実行することでした。 大変だったのは、Javaベースの‶n階層”ソリューションのFLEXCUBE BPELプロセスモジュールを使用し、現行のAS400システム（2段階のソリューション）とのキャパをマッチさせることでした。 which is a &#8220;n tier&#8221; Java-based solution. Pパフォーマンスの期待は大きく、FLEXCUBE　BPELのインフラが構築されたOracle SOA suite 10gのBPELコンポーネントがまだ初期段階だった点です。 Oracle BPELコンポーネントはFLEXCUBEのBPEL インフラで使用されるApplication Programming Interface (API) を提供します。 FLEXCUBE BPELモジュールはワークフローとタスクで動かされるソリューションを追加します。 このモジュールのユーザーインターフェースがユーザーに彼または彼女が割り当てられたタスクを見せてくれます。 これらのタスクはユーザーに見せられ、タスクの多様な特性をベースにグループ化してくれます。 これらのグループはキューと呼ばれます。 このキューはその下にあるタスクの計算も表示します。 この銀行にとって、このキューの数は莫大でした（彼らの現行システムの複製も要求したためです。） 計算をフェッチするために、APIは出来るだけ多くのキューのあるデータベースのクエリを実行します。そしてそれらのキューは彼または彼女の要求に基づいてユーザーによって何度でも閲覧できます。 ユーザーの承認とストレステストの間、パフォーマンス問題がAPIの一環として起こりました。これらの問題は一部はAPIの欠如によるもの、それから他の一部は銀行の要求を対処するためのAPIの不適切な使用に基づくものとして起こりました。プロジェクトのこの時点で、インフラの中のAPIのディペンデンシ―を除去するのは不可能でした。機能的にコアAPIにおいて、ディペンデンシーを漏洩することなくボトルネックを使用しAPIエリアを使用することを避け、インフラを修正することで問題を解決しました。例として、ボトルネックだったエリアは時間のかかるAPIを使用したBPELデータベースに対するクエリ実行でした。このAPI欠如はAPIによってクエリが作られた段階に到達することで切り抜けられました。また、APIを使用するより、データベースに対してクエリを直接実行しました。 提供されたソリューションはビジネス要求を満たし、お客様によって要望された通りパフォーマンスベンチマークを達成しました。]]></description>
		<wfw:commentRss>http://tarant.hu/?feed=rss2&#038;p=561</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>我々のコンサルタントの実際の体験</title>
		<link>http://tarant.hu/?p=557&#038;lang=ja</link>
		<comments>http://tarant.hu/?p=557&#038;lang=ja#comments</comments>
		<pubDate>Thu, 26 May 2011 17:55:57 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Best Practices]]></category>

		<guid isPermaLink="false">http://tarant.hu/?p=557</guid>
		<description><![CDATA[この事例は私が東ヨーロッパ銀行に勤務している時に起こりました。 銀行は12月1日に立ちあがりました。私はプロジェクトに参加したばかりでした。 開設して2日目、銀行は金融関係の大きな問題にぶち当たりました。 銀行が開設して初日の、定期預金の移動の問題でした。 移動した定期預金には、以前のシステムからの元金と利息がありましたが、移動の際ひとつのパラメーターが間違えた値だったためです。元金だけが課税され、元のシステムからの利息に課税されませんでした。 この問題を解決するための我々のタスクは実に明確なものでした。以前のシステムからきた元々の利息を明確にすることでした。そして、その利子額から大体の税金を計算し差し引くことでした。 我々は全ての預金額のリストを用意しました。 特に大変だったのは銀行は生きていましたので、最初の二日で 満期になった預金があったことでした。 最初のステップとして、お客様が税金なしの全金額を引き出すアカウント全てからGLに利子を動かしました。 その次に、その預金全ての税金の計算と差引するスクリプトを用意し、残った利子金額を預金アカウントに戻しました。 これが済んで、最初の二日間の影響は元に戻されました。我々は更に大きなタスクを定め、システムの預金全てを把握し、同じことを行いました。 私はチームの新人だったので、スクリプトの準備には携わらず、全てのアカウントを把握することを引き受けました。 2日間を費やし、全てを網羅する預金リストを作成し、銀行に提供しました。 銀行は同じようにリストを準備しましたが、私のリストの方がより包括的で全てを網羅しているということになりました。 それまで、我々は銀行へのスクリプトを用意し私が送った預金アカウントリストを確認しました。我々はスクリプトが問題を解決すると確証するテストを行い、最終的には銀行に特定の日にスクリプトを送りました。 銀行からこの点を承認し、銀行が重大な金融の最悪の事態を招くことから回避した、チームの3日間の全ての取組みを感謝されました。]]></description>
		<wfw:commentRss>http://tarant.hu/?feed=rss2&#038;p=557</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>我々のシニアテクニカルコンサルタントの経験</title>
		<link>http://tarant.hu/?p=556&#038;lang=ja</link>
		<comments>http://tarant.hu/?p=556&#038;lang=ja#comments</comments>
		<pubDate>Thu, 26 May 2011 17:50:53 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[ベストプラクティス]]></category>

		<guid isPermaLink="false">http://tarant.hu/?p=556</guid>
		<description><![CDATA[私が思いだす故障は民間の銀行でシニアテクニカルリーダーとして従事していたCBS プロジェクトです。 1カ月程前に銀行が設立したばかりで、その後もサポートを行っていました。 設立して1日が過ぎた頃、定期預金の移動で問題が浮上しました。 発見後、銀行は問題解決のスクリプトを渡されました。 私どものチームは銀行に正しいスクリプトを特定の日時で実行するように送りました。 しかし1月24日、銀行はなぜかシステムが生きている状態で、スクリプトの実行を逃しました。 これがわかった時この間違いから引き起こるだろう結果を認識し、チームを招集して問題を説明しました。作られたスクリプトは日付が変わったため、次の日に適応するものではなかったからです。 私は二つの方策を提案し、チームに直ちに取りかかるよう指示しました。 可能な方策とは： 1) 結果を特定し、銀行にリストを送る。生きてる環境でマニュアルでアクションをとる方法。 しかし、システムの全域で結果を特定するというのは、時間のかかるプロセスでした。 しかし、その日の取引を進めたままの影響を考えるとより得策でした。 2) 問題解決するための新しいスクリプトを作る そのようなスクリプトを作成するのは大変手の込んだ作業ですが、問題解決が迅速にできます。しかし、日中の取引に影響を与えてしまうリスクがありました。 私は銀行に間違いとその結果から引き起こるだろう結果を伝えました。 緊急事態だと把握していたので、銀行はどの方法で問題解決をするか決定する会議に出席するように言ってきました。 会議が始まるまで、二つ目のアプローチとしてのスクリプトを用意しました。 会議でどちらの方策も提案しました。 銀行は新しいスクリプトを実行するリスクを孕みたくなかったため、時間がかかるが一つ目の方策に決めました。（スクリプトが問題解決をし、迅速だと言いましたが） テスト環境で最初のアプローチがパスされるまですでに19時を回っていました。この遅れのため、銀行のEODサポート代表が次の日に生きている環境で残りの活動を行うよう延期を提案しましたが、更なる問題を起こす可能性があるとして私は同じ日に全て終わらせるよう主張しました。彼らをサポートし、全て終わった時は23時半を回っていました。レポートを作成し、確証要求をし、0時に帰宅しました。大変骨の折れる作業でしたが、安心感がありました。次の日の銀行の預金業務責任者が私のところへ来て次の日まで待たずに解決し、更なるトラブルを回避したという決定をしたことに感謝してくださいました。次のプロジェクトのUATの間にも自分の業務以外でこの問題を解決したことで、同僚からも大変感謝されました。]]></description>
		<wfw:commentRss>http://tarant.hu/?feed=rss2&#038;p=556</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
